1969 05_#34 05 #34
1969-05_#34 1969-05_%2334
User Manual: 1969-05_#34
Open the PDF directly: View PDF 
.
Page Count: 887
| Download | |
| Open PDF In Browser | View PDF |
AFIPS
CONFERENCE
PROCEEDINGS
VOLUME 34
1969
COMPUTER
CONFERENCE
May 14 -16, 1969
Boston, Massachusetts
The ideas and Opl1l10nS express herein are solely those of the authors and are
not necessarily representative of or endorsed by the 1969 Spring Joint Computer
Conference CommiHee or the American Federation of Information ProCeSSii1.g
Societies.
Library of Congress Catalog Card Number 55-44701
AFIPS Press
210 Summit Avenue
Montvale, New Jersey 07645
© 1969 by the American Federation of Information Processing Societies,
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
AMERICAN FEDERATION OF INFORMATION
PROCESSING SOCIETIES (AFIPS)
OFFICERS and BOARD of DIRECTORS of AFIPS
President
Secretary
PAUL ARMER
Computation Center
Stanford University
Stanford, California, 94305
ARTHUR I. RUBIN
Martin Marietta Corporation
P.O. Box 5837
Orlando, Florida, 32805
Vice President
Treasurer
RICHARD I. TANAKA
California Computer Products, Inc.
305 North Muller Street
Anaheim, California, 92803
WALTER HOFFMAN
Computing Center
Wayne State University
Detroit, Michigan, 48202
ACM Directors
R. G. CANNING
Canning Publications, Inc.
134 Escondido Avenue
Vista, California, 92083
B. A. GALLER
University of Michigan
1056 Ferdon Road
Ann Arbor, Michigan, 48104
J. D. MADDEN
ACM HeadquarterS
211 East 43rd Street
New York, New York, 10017
IEEE Directors
SAMUEL LEVINE
Bunker-Ramo Corporation
445 Fairfield Avenue
Stamford, Connecticut, 06902
L. C. HOBBS
Hobbs Associates, Inc.
P.O. Box 686
Corona del Mar, California, 92625
KEITH W. UNCAPHER
The RAND Corporation
1700 Main Street
Santa Monica, California, 90406
Society for Information
Display Director
American Society For Information
Science Director
WILLIAM BETHKE
RAOC (EME, W. Bethke)
Griffiss AFB NY 13440
HERBERT KOLLER
Leasco Systems & Research Corp.
4833 Rugby Avenue
Bethesda, Maryland, 200 14
Special Libraries Association Director
Association for Computational
Linguistics Director
DONALD E. WALKER
Language & Text Processing
The Mitre Corporation
Bedford, Massachusetts, 01730
BURTIN E. LAMKIN
Library & Information Retrieval Staff
Federal Aviation Agency
800 Independence Avenue, S.E.
Washington, D. C. 20003
Executive Secretary
Executive Director
H. G. ASMUS
AFIPS Headquarters
210 Summit Avenue
Montvale, New Jersey, 07645
BRUCE GILCHRIST
AFIPS Headquarters
210 Summit Avenue
Montvale, New Jersey, 07645
American Institute of Certified Public
Accountants Director
Simulation Councils Director
NOEL ZAKIN
Computer Technical Services
AICPA
666 Fifth Avenue
New York, New York, 10019
JOHN E. SHERMAN
Lockheed Missiles & Space Corp.
D59-10; B-151
P.O. Box 504
Sunnyvale, California, 94088
AFIPS Committee Chairmen
Abstracting
Constitution & Bylaws
VINCENT E. GUILIANO
School of Information & Library Studies
Hayes C, Room 5
State University of New York
3435 !-v1ain Street
Buffalo, New York, 14214
ARTHUR I. RUBIN, MP 170
Martin Marietta Corporation
P.O. Box 5837
Orlando, Florida, 32805
Education
Admissions
ROBERT W. RECTOR
Informatics, Inc.
5430 Van Nuys Boulevard
Sherman Oaks, California, 91401
MELVIN A. SHADER
CSC-Infonet
150 N. Sepulveda Blvd.
El Segundo, California, 90245
Awards
Finance
ARNOLD A. COHEN
UNIVAC
2276 Highcrest Drive
Roseville, Minnesota, 55113
WALTER L. ANDERSON
General Kinetics, Inc.
11425 Isaac Newton Square South
Reston, Virginia, 22070
1969 SPRING JOINT COMPUTER CONFERENCE COMMITTEE
Chairman
Harrison W. Fuller
Sanders Associates, Inc.
Vice Chairman
Treasurer
Brandt R. Allen
Harvard Business School
W. Burgess (Assistant)
Lybrand, Ross Bros., & Montgomery
John E. Ward
Massachusetts Institute of Technology
Secretary
Technical Program
Theodore H. Bonn, Chairman
Honeywell, Inc.
Richard F. Clippinger, Vice Chairman
Honeywell, Inc.
Albin A. Hastbacka
RCA
Local Arrangements
James H. Burrows
Mitre Corporation
Charles Gardiner, Chairman
Itek
Mark E. Connelly
Massachusetts Institute of Technology
Morton· Elmer, Vice Chairman
Sanders Associates, Inc.
John J. Donovan
Massachusetts Institute of Technology
Charles R. Burgess
QEI Computer and Information Systems
Kent R. Groote
Raytheon Company
Ralph B. Levy
Itek
Robert Hengen
Telefile Computer Corporation
Richard
DASA
Henry S. McDonald
Bell Telephone Laboratories
Edward Minnich
Sanders Associates, Inc.
Fred H. Scife
Control Data Corporation
John A. O'Brien
Itek
Norman H. Taylor
Arthur D. Little, Inc.
Harvey Rubenstein
Sylvania
Special Events
Allen Kluchman, Chairman
Data General Corporation
L.
Libby
David Thorndike
CH Sprague Leasing Company
Oliver Wolcott
Honeywell, Inc.
Jack Porter, Vice Chairman
Mitre Corporation
Mrs. Jack Porter, Ladies Program
Public Relations
Jack Nolan
M. I. T. Lincoln Laboratory
Norman M. Bryden, Chairman
Honeywell, .Inc.
Cornelius Peterson
Computer Usage
D. Sweeney, Vice Chairman
Honeywell, Inc.
Joseph Knight
M. I. T. Lincoln Laboratory
Aaron Levine, Consultant
Gilbert-Levine & Co., Inc.
Printing and Mailing
Education Program
A. Dean Barrett, Chairman
Sanders Associates, Inc.
W. Feurzeig, Chairman
Bolt, Beranek & Newman, Inc.
William Pizzo, Vice Chairman
Sanders Associates, Inc.
Jordan Baruch
Educom
Kenneth Rabasca
Sanders Associates, Inc.
Donald Marchand
Sanders Associates, Inc.
David Tiedeman
Harvard
Robert Haven
Project Local
Walter Koetke
Lexington School System
Registration
Bruce M. Campbell, Chairman
IBM Corporation
Richard K. Goran, Vice Chairman
IBM Corporation
Exhibit Coordination
David Sudkin, Chairman
Viatron Computer Systems Corporation
R. G. Gould, Vice Chairman
Digital Equipment Corporation
Advisers
Marjorie Bloom
Bolt; Bera.nek & Newman, Inc.
Cynthia Soloman
Bolt, Beranek & Newman, Inc.
Liason
Jack L. Mitchell, IEEE
M. I. T. Lincoln Laboratory
Adrian Ruyle, ACM
M. I. T. Lincoln Laboratory
Maurice I. Stein, SCI
Adage, Inc.
Morton M. Astrahan,
AFIPS Conference Committee
IBM Corporation
Frank E. Heart
Bolt, Beranek & Newman, Inc.
Albert S. Hoagland,
AFIPS Conference Committee
IBM Corporation
Hawley K. Rising
Bolt, Beranek & Newman, Inc.
H. G. Asmus, AFIPS Headquarters
Donald Cruzen, AFIPS Headquarters
ICC Conference
IFIP Congress 71
MORTON M. ASTRAHAN
IBM Corporation-ASDD
P.O. Box 66
Los Gatos, California, 95030
HERBERT FREEMAN
New York University
School of Engineering and Science
University Heights
New York, New York, 10453
International Relations
Public Relations
EDWIN L. HARDER
Westinghouse Electric Corp.
1204 Milton Avenue
Pittsburgh, Pennsylvania, 15218
CARL E. DIESEN
Computer Center Division
U. S.Geological Survey
Washington, D. C., 20242
Publications
HARLAN E. ANDERSON
Time, Inc.
Time & Life Building
New York, New York, 10020
Social Implication of Information
Processing Technology
STANLEY ROTHMAN
TRW Systems, R3/2086
1 Space Park
Redondo Beach, California, 90278
ICC Technical Program
DAVID R. BROWN
Stanford Research Institute
333 Ravenswood Avenue
Menlo Park, California, 94025
Information Dissemination
GERALD L. HOLLANDER
Hollander Associates
P.O. Box 2276
Fullerton, California, 92633·
Conference
R. GEORGE GLASER
McKinsey and Co.
100 California St.
San Francisco, California, 94111
JCC General Chairman
U.S. Committee for IFIP ADP Group
ROBERT C. CHEEK
Westinghouse Electric Corp.
3 Gateway Center
Pittsburgh, Pennsylvania, 15230
1969 FICC
1970 SICC
JERRY KooRY
Programmatics
12011 San Vicente
Los Angeles, California, 90049
HARRY L. COOKE
RCA Laboratories
Princeton, New Jersey, 08540
CONTENTS
OPERATING SYSTEMS
A modular approach to file system design ........ ,........... ,........... ,.. .
RTOS ' - Extending OCj360 for real time spaceflight control
A PANEL SESSION - ON-LINE BUSINESS APPLICATIONS
On-line business applications
On-line business applications
On-line business applications
On-line business applications
1 S. E. Madnick
J. Alsop, II
15 J. L. Johnstone
29 J. T. Gilmore, Jr.
30 C. T. Casale
32 M. Greenberger
32 W. M. Zani
A PANEL SESSION - COMPUTERS AND THE
UNDERPRIVILEGED
Computers and the underprivileged ........................ ,........... , ..... ,.... .
A program for the underprivileged and overprivileged in the
Boston community ............................................ :.......................... .
What the JOBS program is all about ............................................. .
Computers and the underprivileged ............................................... .
Experimental and demonstration manpower projects .............. ,.... .
36
37
37
38
A PANEL SESSION - COMPUTERS IN SERVICE TO
LIBRARIES OF THE FUTURE
Computers in service to libraries of the future:
Library Requirements ....................... " ........................................ .
Using computer technology - Frustrations abound ..................... .
Computers in service to libraries of the future ........................... .
41 W. N. Locke
42 H. D. Avram
44 H. W. Dillon
SOFTWARE
Batch, conversational, and incremental compilers ........ ,................ .
TRANQUIL: A language for an array processing computer ........ ..
35 M. Bauman
J. J. Donovan
W. B. Lewis
A. L. Morton, Jr.
J. Seiler
47 H. Katzan, Jr.
57 N. E. Abel
P. P. Budnick
D. j. Kuck
SNAP -
An experiment in natural language programminng ......... .
The compiled macro assembler
Y.
R.
R.
75 M.
W.
89 W.
Muraoka
S.:Northcote
B. Wilhelmson
P. Barnett
M. Ruhsam
D. Maurer
MODELS OF INTELLIGENCE
Some logical and numerical aspects of pattern recognition
and artificial intelligence ............................................................... .
A model of visual organization for the game of GO ................. .
Assembly of computers to command and control a robot ........... .
Diagnosis and utilization of faulty universal tree circuits .......... ,." ..
95
103
113
139
TECHNIQUES FOR DISPLAYS AND PICTURE PROCESSING
Solid state keyboard ........................ ,,........ , ., .................................. ,.
149 E. A. Vorthmann
W. C. Naylor
A. L. Zobrist
L. L. Sutro
G. Cioffi
E. Fiorillo
j.
T. Maupin
Computer generated graphic segments in a raster display ................. .
Errors in frequency-domain processing of images ............. " .......... .
Scan-display system of the Illiac III computer ............................. .
161 R. A. Metzger
173 G. B. Anderson
T. S. Huang
187 L. A. Dunn
L. N. Goyal
B. H. McCormick
V. G. Tareski
COMPUTER AIDED DESIGN
Interactive toierance analysIs with graphic QISplay ....................... .
A method of automatic fault-detection test generation for
four-phase MOS LSI circuits .................................................... .
A method of diagnostic test generation ....................................... .
Programmed test patterns for multi-terminal devices ..................... .
20'7 L. A. O'Neill
215 Y. T. Yen
221 A. B. Carroll
M. Kato
Y. Koga
K. Naemura
229 F. J. McIntosh
W. W. Happ
TIME-SHARING SYSTEMS
OS-3:
The Oregon State open shop operating system
Virtual memory management in a paging environment ................. .
An operational analysis of a remote console system ..................... .
A model for core space allocation in a time-sharing system
241 J. W. Meeker
N. R. Crandell
F. A. Dayton
G. Rose
249 N. Weizer
G. Oppenheimer
257 H. D. Schwetman
J. R. DeLine
265 M. V. Wilkes
GRAPHIC APPLICATIONS
Picture-driven animation .................... ,.............................................. .
Computer graphics displays of simulated automobile dynamics
Fast drawing of curves for computer display .... , .......................... .
A class of surfaces for computer display ................................... .
POGO: Programmer-Oriented Graphics Operation ....................... .
273 R. Baecker
289 C. M. Theiss
297 D. Cohen
T. M.· P. Lee
309 T. M. P~ Lee
32] B. W. Boehm
V. R. Lamb
R. L. Mobley
J. E. Rieber
TOPICS OF CURRENT INTEREST
Computer-aided processing of the news .................................. , .... .
An on-line information system for management ........................... .
Computers and Congress ............ ,.................................................... .
Automatic checkout of small computers ....................... " .............. .
Cryptographic techniques for computers ....................................... .
Montessori techniques applied to programmer training in a
workshop environment ......................................... :....................... .
3a 1 J. F. Reintjes
R. S. Marcus
339 G. F. Duffy
F. P. Gartner
35] E. S. Mesko
;{59 M. S. Horovitz
367 D. Van Tassel
373 E. R. Alexander
PAPERS RELATING TO MEMORY
. Variable topology random access memory organizations
381. M. Fischler
A. Reiter
Fault location in memory systems by program ............................. .
Characteristics of faults in MOS arrays ............................. '" ....
"'J
MANAGING LARGE-SCALE SOFfWARE PROJECTS
A systematic approach to the development of system programs
Management of computer programmers ......................................... .
The management and organization of large scale software
development projects ................................................................... .
INFORMATION RETRIEVAL AND LIBRARIES
Interactive search and retrieval methods using automatic
information displays .. , ..................... ,.......... " ................................ .
The LEADER retrieval system ..................................................... .
A PROGRESS REPORT ON PROJECT INTREX
System characteristics of intrex ..................................................... .
An experimental computer-stored, augmented catalog of
professional literature ................................................................... .
393 C. V. Ravi
403 H. R. Lambert
411 F. M. Trapnell
419 M. M. Gotterer
425 R. H. Kay
435 M.
G.
447 D.
A.
E. Lesk
Salton
J. Hillman
J. Kasarda
457 J. F. Reintjes
461 R. S. Marcus
P. Kugel
R. L. Kusik
Remote text-access in a computerized 1ibrary informationretrieval system ............................................................................. .
475 D. R. Knudson
S. N. Teicher
A combined display for computer-generated data and scanned
photographic images ................................... " ................................ .
483 D. R. Haring
J. K. Roberge
COMPUTERS AND COMMUNICATIONS
A study of multiaccess computer communications
A communications environment emulator ........... " .......................... .
APPLICATIONS OF COMUTERS IN THE URBAN ENVIRONMENT
Development of New York City's real property data base ............... .
Requirements for the development of computer-based urban
information systems ..................................................................... .
Automatic traffic signal control systems - the Metropolitan
Toronto experience ......................................... " ............................ .
491 P. E. Jackson
C.
505 J.
R.
R.
D. Stubbs
M. Pearlman
Snyder
Caplan
513 R. Amsterdam
523 S. B. Lipner
529 J. D. Hodges, Jr.
D. W. Whitehead
A PANEL SESSION - EDUCATION OF COMPUTER
PROFESSIONAL
Inter-relating hardware alld software in computer science education
Let's not discriminate against good work in design
or experimentation ....................... '" ................. ,........................... .
537 J. B. Dennis
538 G. E. Forsythe
Applied computer science ............................................ " ................ , .
Identifying and developing curricula in software engineering
TOOLS FOR SYSTEM PROGRAMMING
SAL: Systems Assembly Language .......... ,...................... ,............ ..
BCPL: A tool for compiler writing and system programming
EXDAMS: Extendable Debugging and Monitoring Systems
CENTRAL PROCESSOR SYSTEM DESIGN
Maximum-rate pipeline systems ............................... ,.................. ,.... .
Systematic design for modular realization of control functions
Optimizing floating point arithmetic via post addition
shift probabilities .............. ,...................... " ............... ,.................. .
A PANEL SESSION - SOFTWARE TRANSFERABILITY
Program transferability ........................ ," .......................... ,........... ,.. .
Program transferability .................. ,........... ,....................... ,.............. .
Software compatibility ...... ,.................................................... " ... ,.... ,
Standardization of high-level languages ................. '" .................... ,.
The transferability of computer programs and the data on
which they operate ..... ................................................................. .
Transferability of data and programs 'between computer systems
539 L. Zadeh
540 A. J. Perlis
543 C. A. Lang
557 M. Richards
567 R. M. Balzer
581 L. W. Cotten
587 S. M. Altman
A. W. Lo
597 J. A. Field
605 J. A. Ward
606 R. W. Berner
607 J. A. Gosden
608 G. M. Hopper
609 E. Morenoff
611 J. D. Sable
A PANEL SESSION - COMPUTER-ASSISTED INSTRUCTION:
CURRENT STATUS - FUTURE PROBLEMS
CAl problems and prospects ................. " .... " ......................... ,' ..... .
CAl: Research requirements for instructional strategies ............... .
Instructional uses of computers to grow gracefully and effectively
DYNAMIC GRAPHIC -
613 W. Feurzeig
614 D. N. Hansen
614 E. C. Koenig
TODAY AND TOMMORROW
A picture is worth a thousand words - and costs ...................... ..
Computer animation for the academic community ............. ,' ... ,.... .
Graphics in time-sharing: A summary of the TX-2 experience ..... .
Teaching heart function - One application of medical
computer animation ................................... " .......................... ,..... .
617 J. C. R. Licklid~r
623 W. H. Huggins
D. R. Entwisle
629 W. R. Sutherland
J. W. Forgie
M. V. Morello
637 A.
A.
B.
G.
H. Gott
F. Bowyer
R. Kubert
W. Nevatt
THE DARTMOUTH SYSTEM AND ITS APPLICATIONS
The many roles of computing on the campus ............................ ..
Design considerations for an educational time-sharing system
A flexible user validation language for time-sharing systems ....... .
Project IMPRESS: Time-sharing in the social sciences ...... " ....... .
Secondary school use of the time-shared computer at
Dartmouth College ............................. " ................................. ,...... .
649 T. E. Kurtz
657 R. F. Hargraves, Jr.
A. Stephenson
665 J. S. McGeachie
673 E. D. Meyers, Jr.
681 J. H. Danver
J. M. Nevison
COMPUTER SYSTEMS VS. HEALTH SYSTEMS:
WINNING?
WHO IS
Health information and planning systems: The need
for consolidation ........................ ,...................... " .......................... .
Computer assisted instruction in the diagnosis of cardiac arrhythmias
Hospital automation: Something more than a computer ............... .
A Position paper - Computers in medicine: Automation vs.
improvement of status quo ................. ' ............................. '" ....... .
691 P. F. Gross
703 E. J. Battersby
709 W. L. Bennett
C. F. StrQOOeI
B. C. Glueck, Jr.
715 A. R. Feinstein
MEAStJREMENT AND MODELING OF DIGITAL H.'<\RDW~lill/
SOFTWARE SYSTEMS
An analytic model of multiprogrammed computing ..................... .
717 R. R. Fenichel
Measurement based automatic analysis of FORTRAN programs
723 E. C. Russell
A. J. Grossman
G. Estrin
Software measurements and their influence upon machine
language design ................................... " ... ' ....................... , ............ .
733 L. Presser
M. A. Melkanoff
More on simulation languages and design methodology for
computer systems ......................................................................... .
739 D. L. Parnas
SCIENTIFIC APPLICATIONS
Calculating and plotting equipotential lines for objects with
cylindrical geometry .. ;.................................................................. .
A modular system for reactor calculations .................................. ..
Performance testing of function subroutines ................................ ..
Towards. ~ abstract mathematical theory of :iloating-"point arithmetic
745 W. W. Shrader
751 L. Just
A. Kennedy
P. Walker
A. Rago
G. Leaf
759 W. J. Cody, Jr.
765 D. W. Matula
A PANEL SESSION - SMALL COMPUTERS FOR DATA
TERMINAL NETWORK CONTROL
Small computers in data networks .................................................. ..
The use of a small computer as a terminal controller for a
large computing system ........... " ... " .................................. ,.......... .
773 C. B. Newport
775 H. B. Burner
R. Million
O. W. Richard
J. S. Sobolewski
COMPUTATION AND PROGRAM SPECIFICATION
A system for designing fast programming language translators ....... .
Generating parsers for BNF grammars ......................................... .
An extended BNF for specifying the syntax of declarations
A hierarchical graph model of the semantics of programs ............. .
777
79:3
801
813
V.
F.
G.
T.
Schneider
L. DeRemer
E. Whitney
W. Pratt
HYBRID COMPUTER SYSTEMS AND LANGUAGES
A flexible standard programming system for hybrid computation
A real-time programming language and its processor for digital
control of industrial processes ..................................................... .
A new graphic display/plotter for small digital computers ............. .
Stability controls for the analysis of analogi digital hybrid loops
827 W. Giloi
D. Beckert
H. C. Liebig
843 L.Liang
849 G. A. Kom
S. Simons
R. Steinbach
C. Wiatrowski
859 R. Vichnevetsky
A modular approach to file
system design *
by STUART E. }IADNICK
M a8sachusetts Institute of Technology
Cambridge. Massachusetts
and
JOSEPH W. ALSOP, II
International Computation Incorporated
Cambridge, Massachusetts
IXTRODUCTIOK
A generalized model or "blue-print" for the design of
sophisticated file systems is presented in this paper.
The model exploits the concepts of "hierarchical
modularity" and "virtual memory."
Any general file system design model must, of course,
be modified and refined to satisfy the requirements of a
specific environment. The details of the file system
model are presented in three steps: (1) the basic
concepts and overview are discussed, (2) an example
environment consisting of a multi-computer network
with the added complexities of coordination, structured
file directories, and removable volumes is described ,
and (3) each of the hierarchical levels of the file system
is elaborated in terms of the assumed environment.
Basic concepts used in file system design
Two concepts are basic to the general file system
model to be introduced. These concepts have been
described by the terms "hierarchical modularity" and
"virtual memory." They will be discussed briefly
below.
Hierarchical modularity
The term "modularity" means many different things
to different people. In the context of this paper we
* Work reported herein was suppOlted (in part) by Project
MAC, an M.LT. research project sponsored bv the Advanced
Research Projects Agency, Department of "DefeI.se. under
Office of Xaval Research Contract Xonr-4102(Ol).
will be concerned with an organization similar to that
proposed by Dijkstra6 ,7, and Randell. 14 The important
aspect of this organization is that all activities are
divided into sequential processes. A hierarchical
structure of these sequential processes results in a level
or ring organization wherein each level only communicates with its immediately superior and inferior levels.
The notions of "levels of abstraction" or "hierarchical modularity" can best be presented briefly by
an examp Ie. Consider an aeronautical engineer using a
matrix inversion package to solve space flight prob lems .
At his level of abstraction, the computer is viewed as a
matrix inverter that accepts the matrix and control
information as input and provides the inverted matrix
as output. The application programmer who wrote the
matrix inversion package need not have had any
knowledge of its intended usage (superior levels of
abstraction). He might view the computer as a "FORTRAN" machine", for example, at his level of abstraction. He need not have any specific knowledge of
the internal operation of the FORTRAN system
(inferior level of abstraction), but only of the way in
which he can interact with it. Finally, the FORTRAK
compiler implementer operates at a different (lower)
level of abstraction. In the above example the interaction between the 3 levels of abstraction is static
since after the matrix inversion program is completed,
the engineer need not interact, even indirectly, with the
applications programmer or compiler implementer. In
the form of hierarchical modularity used in the file
system design model, the multi-level interaction IS
continual and basic to the file system operation.
2
Spring Joint Computer Conference, 1969
Figure I-Hierarchical levels
There are several advantages to such a modular
organization. Possibly the most important is the
logical completeness of each level. It is easier for the
system designers and implementers to understand the
functions and interactions of each level and thus the
entire system. This is often a very difficult problem in
very complex file systems with tens or hundreds of
thousands of instructions and hundreds of interdependent routines.
Another by-product of this structure is "debugging"
assistance. For example, when an error occurs it can
usually be localized at a level and identified easily.
The complete verification (reliability checkout) of a
file system is usually an impossible task since it would
require tests using all possible data input and system
requests. In order to construct a finite set of relevant
tests, it is necessary to consider the internal structure
of the mechanism to be tested. Therefore, an important
goal is to design the internal structure so that at each
level, the number of test cases is sufficiently small that
they can all be tried without overlooking a situation.
In practice, level would be checked out and verified,
then levell, level 2, etc., each level being more powerful, but because of the abstractions introduced, the
number of "special cases" remains within bounds.
°
Virtual memory
There are four very important and difficult file system
objectives: (1) a flexible and versatile format, (2) as
much of the mechanism as possible should be invisible,
(3) a degree of machine and device independence, and
(4) dynamic and automatic allocation of secondary
storage. There have been several techniques developed
to satisfy these objectives in an organized manner;
the concept exploited in this generalized file system has
been called "segmentation"5 or "named virtual memorv" . 3 Under this system each file is treated as an
~rdered sequence of addressable elements, where each
element is normally the same size unit as the main
storage, a byte or word. Therefore, each individual
file has the form of a "virtual" core memory, from
whence the name of the technique came. The size of
each file is allowed to be arbitrary and can dynamically
grow and shrink. There is no explicit data format
associated with the file; the basic operations of the file
system move a specified number of elements between
designated addresses in "real" memory and the "virtual" memory of the file system.
There are several reasons for choosing such a file
concept. In some systems the similarity between files
and main storage is used to establish a single mechanism
that serves as both a file system for static data and
program storage and a paging system 3 ,5,8 for dynamic
storage management. "Virtual memory" provides a
very flexible and versatile format. When specific
formatting is desired, it can be accomplished by the
outermost file system level or by the user program.
For example, if a file is to be treated as a collection of
card-image records, it is merely necessary to establish a
routine to access 80 characters at a time starting at
byte locations 0,80, 160, .... Almost all other possible
formats can be realized by similar procedures.
Except for the formatting modules, the entire file
system mechanism, including allocations, buffering,
and physical location, is completely hidden and invisible to the user. This relates closely to the objective
of device independence. In many file systems the user
must specify which device should be used, its record
size' (if it is a hardware formatable device), blocking
and buffering factors, and sometimes even the physical
addresses. Although the parameters and algorithms
chosen might, in some sense, be optimal, many changes
might be necessary if the program is required to run
with a different configuration or environment.
There are very serious questions of efficiency raised
by this file system strategy. lHost of these fears can be
eased by the following considerations. First, if a file is
to be used very seldom as in program development,
efficiency is not of paramount importance; if, on the
other hand, it is for long-ternl use as in a commercial
production program, the device-independence and
flexibility for change and upkeep will be very important.
Second, by relieving the programmer of the complexities of the formats, devices, and allocations, he is
able to utilize his energy more constructively and
creatively to develop clever algorithms relating to the
:Modular Approach to File System Design
r------l
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
/~
/
READ
FROM
FILE "9"
~
I
I
I
I
I
I
I
I
I
I
I
I
I
I
L ____ : _ ;
FILE 9
MAIN STORAGE
Figure 2-"Real" memory and "virtual" file memory
logical structuring of his problem rather than clever
"tricks" to overcome the shortcomings or peculiarities
of the file system. Third, in view of· the complexity of
current direct-access devices, it is quite possible that
the file system will be better able to coordinate the
files than the average user attempting to specify
critical parameters.
Overview of file system design model
The file system design model to be presented in this
paper can be viewed as a hierarchy of six levels. _In a
specific implementation certain levels may be further
sub-divided or combined as required. A ,recent study of
several modern file systems, which will be published in
a separate report, attempts to analyze the systems in
the framework of this basic model. In general all of
the systems studied fit into the model, although certain
leveh; in the model are occasionally reduced to trivial
fonn or are incorporated into other parts of the operating systenl.
The six hierarchical levels are:
1.
2.
:3.
4.
5.
6.
Input/Output Control System (IOCS)
Device Strategy )Iodules (DS)I)
File Organization Strategy }Iodules (FOS)!)
Basic File System (BPS)
Logical File System (LFS)
Access :\Iethods and User Interface
The hierarchical organization can be described from
the "top" dO\vn or from the "bottom" up. The file
system would ordinarily be implemented by starting
at the lowest level, the Input/Output Control System,
and working up. It appears more meaningful, however,
3
to present the file system organization starting at the
most abstract level, the access routines, and removing
the abstractions as the levels are "peeled away';.
In the following presentation the terms "file name",
"file identifier", and "file descriptor" will be introduced.
Detailed explanations cannot be provided until later
sections, the following analogy may be used for the
reader's assistance. A person's name (file name),
due to the somewhat haphazard process of assignment,
is not necessarily unique or manageable for computer
processing. A unique identifier (file identifier) is
usually aSf-'ligned to each person, such as a Social Security number. This identifier can then be used to
locate efficiently the information (file descriptor)
known about that person.
Access Methods (AM)
This level consists of the set of routines that superimpose a format on the file. In general there will
probably be routines to simulate sequential fixed-
Level 6:
Access Methods (AM)
User Interfaces
Level 5:
Logical File System
(LFS)
Level 4:
Basic File System
(BFS)
Level 3:
File Organization
Strategy Modules (FOSM)
Level 2:
Device Strategy
Modules (DSM)
Level I:
Input/Output
Control System (IOCS)
Devices
Figure :3-Hiel'al'chical file systems
Spring Joint Computer Conference, 1969
4
length record files, sequential variable-length record
files, and direct-access fixed-length record files, for
example. lVlany more elaborate and specialized fonnat
routLTleS, also called access methods or d9Jta management, can be supplied as part of the file system. Obviously, a user may write his own access methods to
augment this level.
~-------11-}.
Table I-Example procedure to perform logical file system search
-;. VOLUrlE
)0
•
J~
-
1 TC
CdAidIC'l'E.!
(&1,
l?A'fi;_LE~';TrI;
J = ,}
rlY
;i
".:,li"'
{FIL,":_-,->:,":;L>:r.F;A"H .,: P,\"':I(Il);
Basic File System (BFS)
The Basic File System must convert the file identifier
into a file descriptor. In an abstract sense, the file
descriptor provides all infonnation needed to physically locate the file, such as the "length" and "location"
of the file. The file descriptor is also used to verify
access rights (read-only, write-only, etc.), check read!
write interlocks, and set up system -wide data bases.
The Basic File System perfonns ~any of the functions
ordinarily associated with "opening" or "closing" a file.
Finally, based upon the file descriptor, the appropriate FOSlVI for the file is selected.
File Organization Strategy Modules (FOSM)
Direct-access devices physically do not resemble a
virtual memory. A file must be split into many separate
'
} -- D
Logical File System (LFS)
Routines above this level of abstraction associate
a symbolic name with a file. It is the function of the
Logical File System to use the symbolic file name to
find the corresponding unique "file identifier". Below
this level the symbolic file name abstraction is eliminated.
n
c __
1} ·
n n _
File Virtual
Memory
Record 4
' . DRecord7
Record 14
·D
Record 2
PhysiCO! Records
Figure 4---l\1:apping v"irtual memory' into ph:ysical records
physical records. Each record has a unique address
associated with it. The File Organization Strategy
Module maps a logical virtual memory address into
the corresponding physical record address and offset
within the record.
To read or write a portion of a file, it is necessary for
the FOSM to translate the logically contiguous virtual
memory area into the correct collection of physical
records or portion thereof. The list of records to be
processed is passed on to the appropriate DSM.
To minimize redundant or unnecessary I/O, the
FOSM allocates "hidden" file buffers as needed. If
the requested portion of virtual memory is contained
in a currently buffered record, the data can be transferred to the designated user main storage area without
intervening I/O. Conversely output to the file may be
buffered. If a sufficiently large number of buffer areas
are allocated to a file, it is possible that all read and
write re.quests can be perfonned by merely moving
data in and out of the buffers. When a file is "closed",
the buffers are emptied by updating the physical
records on the secondary storage device and releasing
them for use by other files. Buffers are only allocated to
files that are actively in use (Le., "open").
Device Strategy Modules (DSM)
When a large portion of a file is to be read or written,
many records must be processed. The Device Strategy
Module considers the device characteristics such as
latency and access time to produce an optimal I/O
sequence from the FOSM requests.
The DSM also keeps track of the available records
on the device. It is responsible for allocating records
for a file that is being created or expanded, and deallocating records for a file that is being erased or
Modular Approach to File System Design
truncated. The FOS}! requests that a record be
allocated when needed, the DS::\! selects the record.
Input/Output Control System (IOCS)
The Input/Output Control System coordinates all
physical I/O on the computer. Status of all outstanding
I/O in process is maintained, new I/O requests are
issued directly if the device and channel are available;
otherwise the request is que"!led and automatically
issued as soon as possible. Automatic error recovery is
attempted when possible. Interrupts from devices and
unrecoverable error conditions are directed to the
appropriate routine. Almost all modern operating
systems have an laCS.
File systems versus data management systems
In the literature there is often confusion between
systems as described above, "\vhich this paper calls
"file systems" and systems which will be called "data
management systems", such as Dl\I-1,8 GIM-1,13
and TD::\IS.17 The confusion is to be expected since
both types of systems contain all of the functional
levels described above. The systems differ primarily on
the emphasis placed on certain levels.
In general file systems, the file is considered the
most important item and emphasis is placed on the
directory organization (Logical File System) and the
lower hierarchical levels. It is expected that specialized
access methods will be written by users or supplied
with the system as needed.
In most data management systems, the individual
data items are considered the most important aspect,
therefore emphasis is placed on elaborate access
methods with minimal emphasis on the lower levels of
abstraction. Because of the heavy emphasis on a
single level, data management systems tend to appear
less hierarchical than file systems since the lower
levels are often absorbed into the access methods.
~~.1ulti-computer -netwurk e;nvitO'tI/rneni
5
is not possible to acquire a larger processor,
(b) reliability is important, or (c) there are
real-time or time-sharing constraints.
2. To serve the coordination requirements of a
network of regional computer centers.
3. To support the accessibility to a nation-wide
data base.
An example of the envl...rornnent to be considered. for
this paper can be illustrated in Figure 5. This type of
multi-computer network has been in limited use for
several years in many configurations. The IBM
7094/7044 Direct-Coupled System was probably one
of the earliest practical examples of such an interconnected arrangement.
There are several implicit constraints imposed upon
the multi-computer system illustated in Figure 5:
1. Independence of Central Processors.
Each of the central processors operates independently such that there are no direct processorto-processor data transfer nor signaling, and
furthermore there is no "master" processor.
2. Non-shared YIemory.
Each central processor has its own main storage
unit. These units are not shared with nor
accessed by another central processor.
3. Inter-locked Device Controllers.
The device controllers act as "traffic cops" to
the actual I/O direct access devices. They
control the traffic between a computer's I/O
channel and a selected I/O device. A single
device controller will only accept requests from
one channel at a time and will only select one
I/O device (among those under its control) at
a time. Once a device controller connects a.
CPU
---------MEMORY
----------
CHANNELS
CPU
CPU
--------MEMORY
CHANNELS
CHANNELS
--------MEMORY
----------
--- -------
A general file system design model must, of course,
be modified and elaborated to satisfy the needs of any
specific desired file system environment. To illustrate
the refinement process, a unique file system design will
be presented for a multi-computer network.
Multi-computer networks are becoming an increasingly important area of computer technologyY There
are several significant reasons behind the growth of
multi-computer networks:
1. To increase the power of a computer installation in a modular manner, especially if (a) it
Figure 5-Example of multi-computer file system network
6
Spring Joint Computer Conference, 1969
channel with a device, the connection lemains
intact until the channel releases the device or
an I/O error occurs,
The environment described above, although well
within the boundaries of current technology, has not
been the subject of much investigation. Such configurations are presently very expensive and, therefore,
chosen only for very specialized situations. Even then
there are only two or three processors and very
specialized software and operational factors. A discussion of the CP-67/CMS Time Sharing System 9,21
will serve to establish the relevance of the multicomputer network environment.
The CP-67/CMS Time Sharing System uses the
special hardware features of a single IBNI System/360
model 67 processor augmented by software to produce
an apparent environment corresponding to the multicomputer network illustrated in Figure 5, with many
independent central processors, device controllers, and
direct access I/O devices. In practice a typical single
processor 360/67 configuration w{)uld produce the
affect of about 30 active processors ("vii'tual" System/
360 model 65 processors each with a 256,000 byte
memory) and 50 active device controllers. ~10re
detailed descriptions of the CP-67/CMS System can
be found in the References. 1:n the traditional sense of
time-sharing, each user of the CP-67/CMS System is
provided with a "virtual" computer operated from a
simulated operator console (actually an augmented
remote terminal). Most importantly, each "virtual"
computer (i.e., user) operates logically independently
of all other" virtual" computers except for the specified
inter-connected I/O devices and device controllers.
Problems arising in multi-computer networks
There are many problems associated with the multicomputer file system network. Some of these problems
are unique to this environment. Other problems have
been solved in traditional file systems,2,17,20 but the
solutions require major revisions due to the peculiarities of the environment. The most significant problems
are listed briefly below.
1. No shared memory.
Usually file systems coordinate the status of
the files and devices by using main storage
accessible tables and data areas that describe
file status, access rights, interlocks, and allocation. There is no such common communication
area in main storage that can be accessed by all
the independent processors.
2, NQ inter-computer communication.
~1ulti-computer configurations usually provide
a mechanjsm for sending signals or data transfers
between the separate processors. With this
capability the non-shared memory problem
could be solved by either (a) electing one
processor to be the "master" processor that
coordinates the other processors, or (b) supply
all the processors with enough information
such that each processor knows what all the
other processors are doing. The concept of a
"master" processor opposes the intended homogeneous, independent processor assumption.
The possibility of supplying status information
to all other processors, although reasonable for
a three or four processor configuration, was not
considered a feasible solution for a system
with hundreds of processors and devices and
thouS'tands of files. For these reasons , intercomputer communication, although an available
capability, was not included as a required
capability of the multi-computer environment
described above.
3. No pre-arranged allocations.
For small specialized multi-computer file networks, each processor can be "assigned" a specific area of a device or set of devices that can be
used to write new files, all other processors can
only read from this area by convention. This
prevents the danger of two independent processors writing files at the same place. Such an
"arrangement" is not practical for a large, flexible multi-computer file network since the static
assignment of secondary storage space does not
take account of the dynamic and unpredictable
requirements of the independent processors.
4. Extendable device and file allocation.
The number of devices and sizes of devices as
well as the number and sizes of files are, within
reason, unlimited. For example, a specific
amount of secondary storage equivalent to
100,000 card images could be used to hold 10
files of 10,000 cards each or 1,000 files of 100
cards each. This consideration discourages
techniques that result in a strong efficiency or
main storage capacity dependency on the" size
and shape" of the file system. Of course, the
magnitude of the file system size will affect
the operation, but arbitrary restrictions such
as "no more than 64 files on a device" would be
discouraged unless essential.
5. R.emovable volumes.
It has become common to differentiate between
the I/O mechanism used to record or read information, called a "device", and the physical
Modular Approach to File System Design
medium on which the information is stored,
called a "volume". For most drums and many
disk units, the device and volume are inseparable. But, for magnetic tape units and
many of the smaller disk units the volume,
magnetic tape reel and disk pack respectively,
are removable. It is intended that the file system
include files that are on unmounted volumes
(discoY'.Jlected from an I/O device) as well as
mounted volumes. Therefore, a configuration
that consists of ten disk units may have a file
system that encompasses hundreds of volumes,
only ten of which may be actively in use at a
time. Since removing and mounting a volume
takes several minutes of manual effort, it will
be assumed that the "working set" of volumes
(volumes that contain files that are ~ctively in
use) remains static for reasonable periods of
time and is less than or equal to the number of
devices available. The fact that volumes are
removable and interchangeable (i.e., may be
mounted on different devices at different times)
does affect the organization of the file ~stem.
For example, a scheme that involved. )i,nking
files together by means of pointers .(Cihained
addressing) could require mounting volumes just
to continue the path of the chain even though
little or no "logical" information was requested
from files on that volume. In the worst case, it
might· be necessary to mount and unmount all
the volumes of the file system to locate a desired file. Such a situation should definitely be
avoided if not totally eliminated by the file
system.
6. Structured file directories and file sharing.
In a traditional file system, the mapping between·
the symbolic file name and the corresponding
file was accomplished by means of a single
)laster File Directory. For modern file systems
with thousands of files scattered over hundreds
of volfu"'1l6s, it became desirable, ii not necessary,
to form groupings of files by means of Secondary
File Directories. 4 These groupings are often
used by the system to associate users with files
they own (User File Directories). This capability
is also available to the user to arrange his files
into further sub-groups (libraries) or into separate project-related groupings. Occasionally it
becomes necessary for a file to be included in
two or more groupings (e.g., accessible by more
than one User File Directory) with potentially
different access privileges (protection) associated with each grouping. l\Iany of these features
7
that are relatively easy to implement in a
traditional file system are complicated by the
introduction of independent processors and
removable volume~.
7. Fail-safe operation.
Reliable operation is a very important requirement of a general purpose file system. There are
many known techniques for I/O error and
systematic backup and salvage procedures
that are applicable to this environment. The
important problem associated with the multicomputer network is that potential error conditions exist that are not normally found ill
traditional single computer file systems. For a
single computer system, a processor error
(including unexpected processor disconnection,
i.e., "turning off") is a rare occurrence. Such a
situation is remedied by repairing whatever
physical hardware is necessary and then running
a special "salvager" program to bring the file
system into a well-defined operational state.
In the environment of a multi-computer network, processors may be connected or disconnected at any time without any awareness
by the other processors. To prevent any inconsistent file system operation by the other
processors and eliminate the need for usually
time-consuming salvage techniques, it is necessary to keep the file system in a well-defined
consistent state at all times.
A file system design
The purpose of the remainder of this paper is to apply
the organization presented in th, File System Design
IHodel section to solve the problems associated with a
multi-computer file system network. Discussion of
the Access ::\Iethods and Input/Output Control
System will be omitted. This is necessitated for brevity
and consideration of the facts that the Access )Iethods
are highly application oriented, as discussed in a
previous section, and that the Input/Output Control
System is usually a basic and common component of
all Operating Systems. The principal contribution of
this model lies in the structure of the four other levels.
Logical file system
To present the goals and requirements of the Logical File System in a brief and demonstrative manner,
an example will be used. The reader should refer to
Figure 6 for the following discussion. It is important
that the peculiarities of the example, such as the
choice of file names (e.g., "FILE6" and "DIR4"), not
8
Spring Joint Computer Conference, 1969
VOLUME "Val I"
(User
VOLUME "VOl2"
VOLUME "VOL 3 "
1)
Vall (3)
F1LE.3
D1R 2
(User 2)
VOl2(3)
DIR 3
t
(User 3)
VOL 3 (2)
FILE 5
D1R 4
FILE 6
DIR 3
Vall (2)
VOL 2 (4)
I111111111I
I111111111I
VOll(6)
11/11111111
VOL 1(4)
111111/1111
VOL 1(5)
111/1/11111
VOL3(3)
11/1/111111
Figu!'e 6-Example of file directol'Y structure (to LFS)
be confused with the general characteristics of the
Logical File System.
. In Figure 6, there are 12 files illustrated. Associated
with each file is an identifier of the fomi "VOL1(3)".
The usage of this identifier will not be discussed until
later, in the meanwhile not.ice that each file's identifier
is unique. The 12 lftes are divided into 2 types, directory files (i.e., VOL1(3), VOL2(3), VOL3(2) , and
VOL3(b»), and data files (i.e., VOL1(2), VOL1(6),
VOLl (4), VOLt U5), VOL2(4), VOL2(2), VOL3(4),
and VOI~1(3». The distinction between directory
files and data files i~ only a matter of usage, the Access
lVrethods may operate upon a directory file in the same
manner as a data file, furthermore, all lower levels
(e.g., Basic File System) treat all files as data files.
This factor vdll be elaborated shortly.
I t is the stated function of the Logical File System to
map a file name reference into a unique file identifier.
This mapping is a function of the requested file name
(symbolic file name path) and a starting point (base
directory) in the file directory structure. In Figure 6,
three example base directories are illustrated by
associating VOL1 (3) with user 1, VOL2U~) with user
2, and VOL3(2) with user 3. Therefore, user 1 references to the file name FILE2 yieldR the file VOLl (4).
A more complex example can be illustrated by
considering the file VOL3(4). User 3 can refer to this
file under the name FILE8. Alternatively, it can be
referenced by the name DIR3.FILE7. The file DIRa,
which is associated with VOL3(5) from user 3's base
directory, is interpreted as a lower level directory.
Then from file VOL3(5) , the file name FILE7 is mapped
into VOL3(4) as intended. The file VOL3(4) can be
referenced from user 2's base directory as DIR3.FILE8
or DIR3.DIR3.FILE7, for example. From user 1's
base directory, it can be referenced as FILE3, DIR2.
DIR3.FILE8, DIR2.DIR3.DIR3.FILE7, or even
DIR2.DIR3.DIR4.DIR3.DIR3.FILE7.
Two important side effects of the base file directory
and file name path facilities are that (1) a specific
file may be referenced by many different names, and
(2) the same name may be used to reference many
different files.
The headings VOLUl\IE "VOL1", VOLUME "VOL2", and VOLUl\1E "VOL3" are intended to indicate
that the 12 files are scattered over 3 separately detachable volumes: VOL1 (containing VOL1(2), VOL1(3), VOL1(4), VOL1(5), and VOL1(6», VOL2 (containing VOL2(2), VOL2(3), and VOL2(4)), and VOL3
(containing VOL3(2), VOL3(3), VOL3(4), and VOL3(5»). If volume VOL2 were detached from the system,
user 1 could still reference VOL1(4) as FILE4 and
VOL3(4) as FILE3, but could not reference VOL3(4)
as DIR2.DIR3.FILE8 nor VOL1(5) as DIR2.DIR3.
DIR3.FILE6 since the path would logically require
passing through volume VOL2. Furthermore, user 3
is allowed to erase (Le., remove from file system structure)
the file VOL3(4) under the name FILE8, assuming
appropriate protection privileges, whether or not volume
VOL1 is mounted in spite of user 1's reference to file
VOL3(4) under the name FILE3.
The Logical File System could be extremely com ~lex
if it had to specifically consider the physical addresses
of volumes, the device characteristics, and the location
of file directories on volumes, in addition to its obvious
requirement of searching file directories. These problems
are eliminated by introducing the file identifier and
the interface with the Basic File System.
The Basic File System processes requests that
specify a file in terms of a file identifier consisting of a
volume name and index, such as (VOL3, 4), rather than
a file name. A sample call from the Logical File System
to the Basic File System, in PL/I-like notation, is:
CALL BFS_READ (VOLUME,INDEX,CORE_
ADDR,FILE_ADDR,COUNT); where VOLUME is
the name of the volume containing the file, INDEX
is the corresponding unique index of the file, CORE_
ADDR is the main storage address into which data is
:Modular Approach to File System Design
to be read, FILE_ADDR is the file virtual memory
address from which the data is to be read, and COUNT
is the number of bytes to be transmitted. Using these
features, the heart of the Logical File System (ignoring
opening and closing files, file access protection, illegal
file names, etc.) reduces to the PL/I-like code presented in Table 1. It is assumed that the file name
has been broken down into an array of path element
names (e.g., if name is DIR2.DIR3.FILE8, then
PATH (1) = 'DIR2', PATH (2) = iDIR3', PATH(3)= ;
FILE8', and PATH_LENGTH = 3), that BASE_
VOLUl\IE and BASE_IKDEX initially specify the
(VOLU::'VIE,INDEX) identifier of the base directory,
and that each entry in a file directory is N bytes long
and formatted as indicated in the FILE_ENTRY
declaration.
Of course, the handling of access (protection) rights,
errors, and other responsibilities will make the Logical
File System much more complex, but it is important
to note that the design and implementation of the
Logical File System escapes all physical file organization
and device characteristic considerations and complexities.
Basic file system
System was simplified by using the facilities
of the lower hierarchical level, the file descriptors
should be maintained in a manner that allows
the File Organization Strategy Module to
process them as normal files.
These problems are solved by the use of the Volume
File Descriptor Directory (VFDD). There is a single
VFDD for each volume, it contains the file descriptors
for all files residing on the volwlle. The file descriptors
are of fixed length and are located within the VFDD
positionally according to the corresponding file
identifier's index.· In order to exploit the facilities
provided by the File Organization Strategy Module,
the VFD D can be processed by the lower levels as a
normal file. It is assigned a unique file identifier
consisting of the volume name and an index of 1,
in fact the file descriptor for a VFDD is stored (when
not in use) as its own first entry. Figure 7 presents
diagranunatically the logical file structure of Figure 6
VOll(l)
Vall (1)
»»»>
Vall (2)
I111111111
I
»»»>
--------VOl1 (3) »»»>
1. There must be a unique file descriptor for each
file regardleSS' of how often the file appears in
file directories or what symbolic names are
used. This is required to maintain consistent
interpretation of a file's status.
2. The file descriptor information for a file must
reside on the same volume as the file. This is
reasonable since if either the file or its descriptor
is not accessible at some time by the system
(i.e., unmounted) the file cannot be used, this
possibility is minimized by placing them on
the same volume.
3. In the same manner that the Logical File
VOL1 (4)
VOl1 (5)
VOll(6)
Vall (3)
FilE 3
I V0L3(4)
---------+--------DIR 2
I VOL2(3)
---------+--------FilE 2
I Vall (4)
---------
Vall (2)
The Basic File System must convert the file identifier
supplied from the Logical File System into a file
descriptor than can be processed by the File Organization Strategy l\10dule. A file descriptor is essential1y
an entry in the Active FiJe Directory (AFD) that
contains information such as the volume name, physical
location of the file on the volume, and the length of
the file. Every file must have an associated file descriptor, but since the number of passive files (i.e., not
actively in use) might be very large, the file descriptors
are maintained on secondary storage until needed
(i.e., file is "opened"). In organizing the secondary
storage maintenance of the file descriptors there are
several important considerations:
9
---------
--------- t--------
---------
---------t--------FilE 1
I Vall (2)
»»»>
FilE 4
»»»>
---------
Vall (5)
»»»>
11/1/111111
I Vall (6)
VFDD for "Vall"
Vall (6)
Vall (4)
\1111111111
\1/11111111
VOl2 (1)
VOl2( 1)
>>>>>>>
VOL2(2)
»»»>
VOl2 (3)
»»»>
VOl2 (4)
»>>>>>
VFDD for "VOL 2"
I
-.
VOl3(1l
VOL 2(2)
DIR 3
--- ------ t--------FILE 6
VOL3(3)
VOl2(4)
.. _ _._
VOL 3(2)
VUL.:Hl)
»»»>
DIR 4
»»»>
--------VOL3(4)
»»»>
I VOl2(3)
---------t--------DIR 3
I VOl3(5)
»»»>
---------
I VOl2(4)
I11111I111I
-------- ...
VOl3(2)
I VOL3(2)
---------t--------FilE S I VOl2(2)
V0L3(3)
---------t--------FilE 8
I VOL 3(4)
111//////11
--------VOL3(5)
»»»>
VOl3(S)
VOl3(4)
1//111/1111
FilE 6
I VOL 1 (5)
---------t-------FilE 2 I VOl3(3)
---------t--------FILE 7 I VOL 3(4)
FigUl'e 7-Example of file directory structure (to BFS)
10
Spring Joint Computer Conference, 1969
with the added detail of the Volume File Descriptor
Directories and File Directory formats.
The File Organization Strategy Module processes
requests that specify a file in terms of a file descriptor
(the entry extracted from the VFDD) rather than a
file name or file identifier. A sample call from the
Basic File System to the File Organization Strategy
Module, in PL/I-like notation, is:
CALL FOSM_READ (DESCRIPTOR, CORE_
ADDR, FILE_ADDR, COUKT); where CORE_
ADDR, FILE_ADDR, and COUNT have the same
interpretation as discussed above.
The primary function of the Basic File System
reduces to the single request:
CALL FOSM:_READ (VFDD_DESCRIPTOR}
DESCRIPTOR,M*(IlXDEX-l),:Vl); where VFDD_
DESCRIPTOR is the descriptor of the VFDD associated with the volume name supplied by the Logical
File System as part of the file identifier, INDEX is
from the specified file identifier, M is the standard
length of a VFDD entry, and DESCRIPTOR is the
desired file descriptor.
The Basic File System performs several other tasks,
such as protection validation and maintenance of the
core-resident Active File Directory that enables
efficient association between a file's identifier and descriptor for files that are in use (Le., "open"). But, as
in the Logical File System, the domain of the Basic
File System is sufficiently small and narrow that it
remains a conceptually simple level in the hierarchy.
File organization strategy modules
table is a function of the file's length and is potentially
quite large. Therefore, it is not feasible to include the
entire mapping table as part of the file descriptor.
One of the most powerful file organization strategies
utilizes index tables, Figure 8 illustrates such an
arrangement.
In this example it is assumed that each file is divided
into 1000 byte physical records. A file can be in one of
several index arrangements depending upon its current
length. If the file's length is in the range 1 to 999 bytes,
the file descriptor contains the address of the corresponding physical record. If the file is between 1000
and 499,999 bytes long, the file descriptor specifies
the address of an index table located on secondary
storage. Each entry of the index table (assumed to
require 2 bytes) designates the physical address of a
block of the file (blocks are ordered by virtual file
addresses: 0-999, 1000-1999, 2000-2999, etc.). Furthermore, for files greater than 500,000 bytes, but less
than 250,000,000 bytes, there are 2 levels of index
tables as illustrated.
.
I ~~~~n-m:uul
I : I
Descriptor
INDEX STATE 1
999
L=J
»»»>
I------~
Descriptor
»»»>
The Logical File System and Basic File System are,
to a great extent, application and device independent.
The File Organization Strategy l\'Iodules are usually
the most critical area of the file system in terms of
overall performance, for this reason it is expected that
more than one strategy may be used in a larg~ system.
Only one strategy will be discussed in this section, the
reader may refer to the papers listed in the References2 ,12 ,17 ,20 for other possible alternatives.
The FOSM must map the logical file address onto a
physical record address or hidden buffer based upon the
supplied file descriptor information. In the simplest
cast', the mapping could be performed by including a
two-part table ill the file descriptor. The first part of
each entry would indicate a contiguous range of
virtual file addresses, the second part of each entry
would designate the corresponding physical record
address. It has been assumed, however, that all file
descriptors have a specific length, wherells the ma.pping
999
INDEX STATE 2
499,999
t----~----1
»»»> I - - - - - - - . . . ! »»»>
»»»>
Descriptor
»»»>
»»»>
INDEX STATE 3
Figure 8-Example of file organization strategy
Modular Approach to File System Design
This strategy has several advantages. Under the
worst conditions of random access file processing only
from one to three I/O operations need to be performed.
By utilizing several hidden buffers for blocks of the
file as well as index tables, the number of I/O operations
required for file accesses can be drastically reduced.
Device strategy modules
The Device Strategy Modules convert "logical I/O
requests" from the File Organization Strategy Modules
into actual computer I/O command sequences that are
forwarded to the Input/Output Control System for
execution. The Device Strategy Modules handle two
rather different types of requests: (1) read or write
blocks, and (2) allocate or deallocat~ blocks.
When a request to transfer a large portion of a file
(10,000 bytes for example) is issued, it is unlikely that
a significant amount of the needed blocks are in hidden
buffers. It will, therefore, be necessary to request
I/O transfer for several blocks (e.g., about 10 blocks if
each block 1000 bytes long). The FOSl\1 will generate
logical I/O requests of the form: "read block 227 into
location 12930, read block 211 into location 13930,
etc." The DSM must consider the physical characteristics of the device such as rotational delay and "seek"
position for movable heads. It then decides upon an
optimal sequence to read the blocks and generate the
necessary physical I/O command sequence including
positioning commands. The Input/Output Control
System actually issues the physical I/O request, error
retry, and other housekeeping as discussed earlier.
The detailed strategy for choosing the optimal I/O
sequence is, of course, very device dependent and will
not be elaborated here.
The function of automatic block allocation is somewhat more complex since it involves several separate
factors. Before describing the implementation of the
mechanisms, it is wise to review the desired characteristics:
1. A file is allowed to grow in size, the FOS.:\I will
request additional hlocks for the data portions
of a file or its index tables, as needed.
2. Common direct access devices contain from
8000 to 32000 separately allocatable blocks,
thus it is not feasible to store all allocation
information in main storage.
3. Since two independent processors may be
writing new files on the same volume at the
same time, it is necessary to provide interlocks
such that they do not accidentally allocate the
same block to more than one file, yet not require
11
one processor to wait until the other processor
finishes.
These problems can be solved by use of a special
Volume Allocation Table (VAT) on each volume. In
this scheme, a volume must be subdivided into arbitrary
contiguous areas. For direct access devices with movable
read/write heads, each discrete position (known as a
"cylinder") covers an area of about 40 to 160 blocks.
A cylinder is a reasonable unit of subdivision. For each
cylinder on the volume, there is a corresponding entry
in the VAT. Each entry contains a "bit map" that
indicates which blocks on that cylinder have not been
allocated. For example, if a cylinder consists of 40
blocks, the bit map in the corresponding VAT entry
would be 40 bits long. If the first bit is a "0", the first
block has not been allocated; if the bit is a "1", the
block has already been allocated. Likewise for the
second, third, and remaining bits.
When the FOS':'\{ first requests allocation of a block
on a volume, the DS':'\! selects a cylinder and reads
the corresponding VAT entry into main storage.
An available block, indicated by a "0" bit, is located
and then marked as allocated. As long as the volume
remains in use, the VAT entry will be kept in main
storage and blocks will be allocated on that cylinder.
When all the blocks on that cylinder have been allocated, the updated VAT entry is written out and a
new cylinder selected. With this technique the amount
of main storage required for allocation information
is kept to a minimUlll (about 40 to 160 bits per volume),
at the same time the numher of extra I/O operations
is minimized (about one per 40 to 160 blocks of allocation).
The problem of interlocking the independent processors still remains. As long as the processors are
allocating blocks 011 different cylinders using separate
VAT entries, they m:1y both proceed uninterrupted.
This condition can be accomplished by utilizing a
hardware feature known as "keyed records" available
on several computers including the IB~\I System/360.
Each of the VAT entries is a separate record consisting of a physical key area and a data area. The
data area contains the allocation information described
above. The key area is divided into two parts: the
identification number of the processor currently
allocating blocks on that cylinder and an indication if
all blocks on that cylinder have been allocated. A
VAT entry with a key of all zeroes would identify a
cylinder that was not currently in use and had blocks
available for allocation.
There are I/O instructions that will automatically
search for a record with a specified key, such as zero.
Since the device controller will not switch processors
"12
Spring Joint Computer Conference, 1969
in the midst of a continuous stream of I/O operations
from a processor (i.e., "chained I/O commands"), it
is possible to generate an uninterruptable sequence of
I/O commands that will (1) find an available cylinder
by searching the VAT for an entry with a key of zero
and (2) change the key to indicate the cylinder is in
use. This thus solves the multi-processor allocation
interlock problem.
CONCLUDING COl\1lVIENTS
To a large extent file systems are currently developed
and implemented in much the same manner as early
"horseless carriages", that is, each totally unique and
"hand-made" rather than "mass produced". Compilers,
such as FORTRAN, were once developed in this
primitive manner; but due to careful analysis of
operation (e.g., lexical, syntax, and semantic analysis,
etc.), compilers are sufficiently well understood that
certain software companies actually offer "do-it-yourself
FORTRAN kits". Since modern file systems often
outweigh all other operating system components such
as compilers, loaders, and supervisors, in terms of
programmer effort and number of instructions, it is
important that a generally applicable methodology
be found for file system development.
ThiEl paper presents a modular approach to the
design of general purpose file systems. I ts scope is
broad enough to encompass most present file systems of
advanced design and file systems presently planned, yet
basic enough to be applicable to more modest file
systems.
The file system strategy presented is intended to
serve two purposes: (1) to assist in the design of new
me systems and (2) to provide a structure by which
existing file systems may be analyzed and compared.
ACKNOWLEDGMENTS
The author acknowledges the many long and often
heated discussions with his colleague, lVIr. Allen
NIoulton, from which many of the basic ideas for this
file system design were molded.
Many colleagues generously contributed their time,
energy, and criticism to help produce this final document. Special thanks are due to Prof. John J. Donovan,
Prof. David Ness, and Prof. Robert 1\1. Graham, as
wen as, Stephen Zilles, Ben Ashton, Hoo-min Toong,
lVIichael l\tfark, Derek Henderson, Norm Kohn, and
Claude Hans.
REFERENCES
1 R E BLEIER
Treating hierarchical data structures in the SDC
time-shared data management system (TDMS)
PAC M 1967
2 F J CORBATO et al
The. compo-tiMe tirne-.'jhanng system
MIT Press Cambridge 1962
3 R C DALEY J B DENNIS
Virtual rnemory, processes and sharing in multics
C A C M May 1968
4 R C DALEY P G NEUMANN
A general purpose file system ofr secondary storage
Proc F J C C 1965
5 J B DENNIS
Segmentation and the design of multi-programmed
computer systems
j A C M October 1965
6 E W DIJKSTRA
The structure of the 'THE' multiprogramming system
A C M symposium on operating systems principles
Gatlinburg Tennsesee October 1967
7 E W DIJKSTRA
Complexity controlled by hierarchical ordering of function
and variability
Working paper for the NATO conference on computer
software engineering Garmisch Germany October 7-11 1968
8 P J DIXON DR J SABLE
DM-J-a generalized data management system
Proc S J C C 1967
9 IBM CAMBRIDGE SCIENTIFIC CENTER
CP-67 JCMS program logic manual
Cambridge Massachusetts April 1968
10 IBM CORPORATION
IBM System/360 ti'TY'.e sharing system access methods
Form Y28-2016-1 1968
11 S E MADNICK
Multi-processor software lockout
PAC M August 1968
12 S E MADNICK
Design strategies for file systems: a work:ingmodel
File/68 international seminar on file organization
Helsingor Denmark November 1968
13 D B NELSON R A PICK K B ANDREWS
Glllf-1-a gerU3lalized in/orlnation inanagernent Zangu,a,gc ar.,a
computer system
Proc S J C C 1967
14 B RANDELL
Towards a methodology of computer system design
Working paper for the NATO Conference on computer
software engineering Garmisch Germany October 7-11 1968
15 R L RAPPORT
Implementing multi-process primitives in a multiplexed
computer system
S M thesis MIT department of Electrical Engineering
August 1968
16 S ROSEN
Progratnm:i"ng systetns and languages
McGraw-Hill New York 1967
17 J H SALTZER
CTSS technical notes
MIT project MAC MAC-TR-16 August 1965
18 J H SALTZER
Traffic control in a multiplexed computer system
Sc.D thesis MIT department of electrical engineering
August 1968
l\iodular Approach to File 'System Desigu
19 A L SCHERR
An analysis of time-shared computer systems
MIT project MAC MAC-TR-18 June 1965
20 SCIENTIFIC DATA SYSTEMS
SDS 940 time-sharing system technical manual
Santa Monica California August 1968
21 L H SEAWRIGHT J A KELCH
A.n introduction to CP-67 JCMS
IBM Cambridge Scientific Center report 320-2032
Cambridge Massachusetts September 1968
13
RTOS-Extending OS /360 for
real time spaceflight control
by J. L. JOHNSTO~E
International Business Machines Corporation
Houston, Texas
INTRODUCTION
The Real Time Operating System/360 (RTOS/360),
a modified version of the standard IB::\1 System/360
Operating System (OS/360) *, was developed by the
Federal Systems Division (FSD) of IB::'VI for support of
the Real Time Computer Complex (RTCC) during
XASA's Apollo spaceflights. RTOS/360 is a real time,
mUlti-tasking, multi-jobbing operating system that
extends the basic features of OS/360 and adds additional features to:
• Process real time data
• Provide simplicity of use for the applications programmer
• Ensure fast response system activity (requirements
range from one-tenth of a second to one second)
•Improve efficiency
• Provide support for special devices not supported
byOS/360
• Provide a fail-safe system
• Increase job shop throughput
The presence of these features in OS/360 does not deter
from its basic capabilities; Le., all the facilities of the
current IB::\1 released OS/360 that operate in a
standard or non-real time mode of execution are
available in RTOS/360.
Some of the major functional areas which were developed at IB~1's FSD Houston Operations and added to
OS/360 in the formation of RTOS/360 were:
• Independent Task :Ylanagement
* IBM System/360 Operating System (OS/360) consists of a
comprehensive set of language translators and service programs
operating under the supervisory control and coordination of an
integrated set of control routines. The operating system is
designed for use with Models 30, 40, 50, 65, and 75 of Computing
System/360.
• System Task Capability
• Queue ~1anagement
• Data and Time Routing
• Time l\1anagement
• Real Time Input/Output Control System
• Data Tables
• Display Formatting Language (DFL)
• Real Time Linkages
• Large Core Storage Support
• Logging
• Simulated Input Control
• Fastime
• Fail-Safe Programs
• Background Utilities
• Houston Automatic Spooling Priority (HASP)
• Statistics Gathering System
• Job Accounting System
• Multi-jobbing
The RTOS environment
Although RTOS/360 can be used in a variety of
applications and computer system configurations, it is
pertinent prior to discussing its functional areas that
we establish the environment in which it was designed
to operate, i.e., the Rea.l Tit1le Computer Complex
(RTCC), the RTCC hardware, and the RTCC applications programs.
TheRTCC
The RTCC is a ground-based computing and data
processing complex for NASA's manned spaceflight
program. It includes the computer equipment, associated peripheral equipment and program packages to
monitor and support-in real time-Apollo missions,
simulations, and training exercises. l
RTCC is the core of NASA's Mission Control Center
------------------------------------------ 15 -----------------------------------------
16
Spring Joint Computer Conference, 1969
(MCC) at Houston, Texas. Flight controllers at lVICC
monitor every phase of a manned spaceflight, from
launch through orbit, reentry, and splashdown. During
a lunar mission, flight controllers also monitor and support the astronauts during their flight to the moon,
the descent to the moon's surface, the liftoff and
rendezvous with the mother ship, and the return to
earth.
RTCC provides flight controllers with the information they need to monitor the flight and make decisions
regarding the mission. This simply means flight controllers sitting at consoles in Houston have precise
information in real time such as the status of every onboard system, the condition of the astronauts, their
position in space at any desired time up to 40 hours in
advance, or t.he effect that any planned maneuver
would have on the spacecraft or the astronauts.
The RTCC is called on to do many things during a
mission. Some of the more important or more common
requirements include:
• Process radar data during launch and provide
ilight controllers with present position and velocity
• Provide flight controllers with information on
whether or not the spacecraft will achieve orbit
• Process telemetry data and provide flight controllers with vital information such as amount of
oxygen remaining in astronaut environmental
control system
• Compute the orbital path of the spacecraft from
radar data
• Predict the position of the spacecraft at some time
in the future
• Compute how and when the spacecraft must
accomplish a particular maneuver to change its
orbital characteristics
• Compute navigation information to update the
Apollo Guidance Computer on board the spacecraft
• Process radar range data and let flight controllers
know the spacecraft is on correct lunar transfer
flight path, and if not, what maneuvers are necessary to get it back on the correct path
• Monitor the Apollo Guidance Computer during
reentry and predict the spacecraft landing point.
In addition to these tasks, and thousands more performed during a typical Apollo mission, the RTCC also
has a key role in flight controller and crew training.
To perform the different requirements of the RTCC,
each of five IBM System/360 Model 75 computers are
assigned a different role and the RTCC is engineered so
that these roles can be exchanged at any moment. This
unified set of computers allows NASA to run either two
actual missions at the same ti..1'fle, two simulated mis-
sions at the same time, or a simulated mission and an
actual mission at the same time. Figure 1, The RTCC,
demonstrates the five systems at work in the latter configuration. In the mission configuration, network data
flows into the RTCC from one of the Communications
Command and Telemetry Systems (CCATS)at MCC.
The data are then sent to the :NIission Operational Computer (MOC) in the RTCC, which processes all the
real time processing tasks of the Mission, and the
Dynamic Standby Computer (DSC), which performs
redundancy processing and is ready to function as the
~![OC, if necessary. In the simulation and training
exercise 1 an Apollo trainer, either at the MCC or Cape
Kennedy, is in a closed loop with one of the identical
Mission Operational Control Rooms (MOCR). (The
other lVIOCR is being used for the mission in progress.)
One simulation computer contains an application program which is generating simulated network data; the
other computer is being used as a simulated operational
computer. The fifth computer is a standby computer
for both exercises; however, it is not idle, but performing job shop checkout for future application program development.
The hardware configurations
There are several System/360 hardware configurations used in the development and execution of the computing systems developed for the real time applications
at NASA. Each configuration is supported by a single
RTOS/360 system. The configuration used on each
of the five computer systems in the RTCC itself consists of a System/360 Model 75 computer with a onemillion byte main memory (IB¥ 2705). (See Figure 2,
System/360 Model 75 for :Mission Support.) An IBM
2361 Large Core Storage (LCS) acts as a four-million
byte exte,nsion of main memory as well as a buffering
MCC
Imls ~ I
GROUNORAMR
Is~
SHIP
COMMUNICA liON
75
~,
I
MISSION
COMNre~
~ -r:,:,r~.::75
COMPUreR
~~~·~~-=---~u·
-r::1---~
,~
TI~
/
r8~
I".., I ,~
S!MU ....
MCC
slMU ....reo
IEMOre
SITE
Figure I-The RTCC
75
RTOS
17
areas and features designed to extend OS/360 to form
RTOS/360. First, let's look at the functional areas.
Functional areas of RTOS/360
Independent task management
IlEAL
TIME
INTUFACE
In OS/360, all processing is done in conjunction with
units of work defined as tasks. Tasks are not programs
in core storage nor are data for a program a task. A task
SELECTOR
2705 CPU
CHANNEL
6
IMILUONBYT£S
(STORAGE
CHANNEll
Figure 2-8ystem/360 model 75 for mission support
device for retrieving data and programs from the IB2VI
2314 disk drives. The IBl\1 2701 provides a rapid demand response interface to the digital display (D/TV)
system in the MOCR and RTCC. Real time acceptance
and transmission of large amounts of data and control
information are accomplished through the use of the
IBM 2902 Multiplex Line Adapter (::.\lILA). A card
reader/punch, an IB:'VI 1443 printer, three IB.:Vr 1403
printers, two IBM 1052 consoles, and eight tape drives
complete the configuration.
Another System/360 l\:Iodel 75 configuration is used
primarily for Simulation exercises. In addition to those
devices given in the previous configuration, this Model
75 configuration supports a special Apollo Simulation
Processor Channel (ASPC), which receives data from a
Multichannel Demultiplexor and Distributor (MDD),
an IBl\1 2260 Display Device, and an IBlVI 2844 which
acts as a control unit for the IBl\1 2314 disk drives.
Several different System/360 :Model 50 configurations
are also supported by RTOS/360 at the RTCC.
The applications
The applications programming packages used to
perform in these various configurations include:
• The Apollo lVlission Systems
• The Ground Support Simulation Computer Systems
• The Dynamic Network Data Generation Systems
• The Simulation Checkout and Training Systems
• The Operational Readiness and Confidence Testing Systems.
We've now placed RTOS/360 in its environment; i.e.,
the RTCC, the RTCC hardware configurations, and the
RTCC applications used for real time processing under
RTOS/360 control. 'Vith this environment in mind, we
can now turn to a description of the various functional
is a unit of work (programs and data) requiring resources (CPU etc.) to complete its functions. A task
exists only when a Task Control Block (TCB) is established and its location is known to the supervisor
portion of the operating system. The TCB contains
information on such things as pointers to data (I/O),
the list of programs needed to operate under the task,
the priority of the task, etc. In OS/360, the word "multiprogramming" is replaced by "multi-tasking"; however, the meaning is still the same, i.e., many tasks
processing asynch.ronously-through various paths of
logic with the usage of the CPU being switched according to the requirements of the system. (Figure 3,
A Task, gives a graphic illustration of a task.)
Some of the characteristics of an OS/360 task are not
functionally oriented toward the types of work required
to be performed by a real time system. An OS/360 task
requires the existence of its creator in order to exist;
i.e., it is dependent on its creator. This OS/360 concept
has been extended within RTOS/360 to include tasks
which are independent of their creators. This causes a
distinction between dependent and independent tasks.
(A dependent task is identical to an OS/360 task.)
Therefore, an independent task does not require the
existence of its creator in order to exist.
How do the characteristics of an independent task
render it more especially suited to real time systems?
First, a real time system must be able to receive and
process varying data loads rapidly and efficiently. In
RTOS/360, an independent task may be defined for
each type of data to be processed in real time and be
r---
r-::I ---l
I~I
B
PROGRAMS
Figure 3-A task
18
Spring Joint Computer Conference, 1969
available to receive work at all times even if the data
rate is low or random. The major distinction here
between dependent and independent tasks is that the
independent task will continue to exist in the system
when it has no data to process. During this time it is
dormant. The OS/360 task requires at least one load
module executing in order to exist. Each independent task
is assigned an area in main core called a resource table.
This is a private area that can be used by the programs
running under the task. Usually, information is stored in
this area which is derived from the processing of earlier
data. In this way, the task can "remember" information
through periods of dormancy. When data are received by
the system for an independent task, they are sent to the
task in the form of a request. Each request has its own
priority which in turn becomes the task's dispatching
priority while processing that request. The 08/360
task has only the priority of its creator. If an independent task is processing a request when another request is
generated for it, the new request is enqueued according
to its priority. Requests in this queue will be given to
the task as it completes the processing of higher priority
or older requests.
When an independent task becomes active, it is
assigned a unique protect key. This protect key is
given to all dependent tasks created by the independent
task while processing a request. Therefore, a program
running under an independent task or its descendents
will be protected from all programs controlled by
other active independent tasks or their descendents.
Since dependent tasks are assigned the same protect
key as their creator's, all tasks of a job step in OS/360
have the same protect key. This is not practical in
large real time, multiprogramming systems where
many tasks handle various types of data. Independent.
tasks ensure that unique protect keys will be assigned
to unique functions.
Figure 4, OS/360 Task Structure, represents the
logical structure of tasks operating as a job step in
OS/360. This structure is obviously pyramidal in form.
All tasks depend either directly or indirectly on the
Job Step Task. The Job Step Task can create dependent tasks (subtasks) which in turn can create tasks
dependent upon them, etc. All tasks compete for system
resources (CPU, I/O, etc.), and OS/360 awards those
resources according to the priority assigned to each
task.
Figure 5, RTOS/360 Task Structure, represents the
logical structure of tasks operating as a job step in
RTOS/360. One can see that a new dimension has been
added. The Job Step Task and its subtasks exist as in
OS/360 while each independent task forms the basis of
another set of tasks which operate independently of and
JOB STEP
TASK
ETC.
Figure 4-08/360 task structure
ETC.
ETC.
Figure 5-RTOS/360 task structure
parallel to the Job Step Task and each other. This
structure is comparable to multi-jobbing in OS/360
with each independent task analogous to the Job Step
Task of each active job. However, in RTOS/360, all
independent tasks and their subtasks function within
a ";single job step, and all tasks in that job step are
awarded the system resources according to their dispatching priority.
System task capability
In the processing of real time data, it was found that
many units of work (tasks) were unrelated to an existing
task or could be performed asynchronously to existing
tasks. T\lese tasks were really tasks of the system.
Therefore, a capability was developed in RTOS/360
for these systems tasks. System tasks perform services
for the RTOS Supervisor or user-created tasks such as
message writing and logging of real time input data.
System tasks can be created and returned from within
1/25th the system overhead time required for either an
OS /360 defined dependent task or R TOS defined independent task. This reduction in overhead to perform
required system services in a real time environment
can prove tremendously important during those CPU
critical periods of high, real time, data processing.
RTOS
19
The large difference in overhead is due to the following:
• All control blocks required for a System Task have
been pre-allocated and pre-initialized for efficient
utilization.
_• The entry point for a System Task is an absolute
location instead of a load module name, as is the
case for dependent and independent tasks.
ETC.
Queue management
If an independent task is processing a work request
all other requests for that task must be held by the
system until the task is ready to begin processing a new
request. Therefore, RTOSj360 must build and maintain a queue of work requests which are waiting to be
processed by an active independent task. Information
concerning each request is held in a Real Time Queue
Element (RTQEL). (Figure 6, Independent Task and
RTQEL's, shows the logical structure of an independent task and its RTQEL's which are waiting to be pro..
cessed.) Each active independent task will be processing
one work request and that request is represented by the
active RTQEL. All other work requests for the inde~
pendent task are placed in a queue of waiting RTQEL's.
This queue is ordered by dispatching priority and, i~ the
case of equal priorities, it is first-in first-out (FIFO).
When the task completes processing ()f
~ctive
RTQEL, the top RTQEL in the que~ of waiting
RTQEL's is made active and is given to the task. If
there are no work requests (RTQEL's) waiting for the
task, then the task is made dormant and waits in the
system for the arrival of new work. All work requests
for independent tasks can be optionally placed under
queue management controls by directing each RTQEL
into a Real Time Queue (RTQ). Each RTQ is created
by a user macro instruction which defines the five
attributes of the queue:
Figure 6-Independent task and RTQEL's
RTQC8
TOPRTQEL
ACTIVE
RTQEL
NEWEST RTQEL
the
•Its unique name, which identifies the RTQ.
•Its length, which is the maximum number of
RTQEL's to be held in the RTQ before an overflow condition occurs.
• The sequence in which RTQEL's are to be removed
from the RTQ and given to independent tasks for
processing (dispatching priority, FIFO, LIFO).
• The overflow disposition which identifies the
RTQEL to be removed from the RTQ and discarded if the queue overflows (newest, oldest,
lowest priority RTQEL).
• Whether the RTQ is currently able to give
RTQEL's to independent tasks (enabled or disabled).
Figure 7, Real Time Queue Element Control, gives
Figure 7-Real time queue element control
an example of the logical structure of HTQEVs cont.l"()ll~cl
h" on
"' ... ....., ...................... - J ......,........
"RTf)
Tho ~.L
huo
cd·h.ih.,,+.no " .... ;!
~"' ..... ~ •
V
c:..tiUU.&..LuuU\J..::! GtI.1..L\.A..
..L ....... "'"
l'
A+h,,~
vuJ..1.\".I.J.
,,,.'"
vVU-
trol information pertaining to the R TQ are held in the
Real Time Queue Control Block. In the example, the
RTQEL's would be given to the independent task in
order one, two, three, four, if they were not controlled
by the RTQ. That is the sequence of their relative dispatching priorities. However, the RTQ has a FIFO
order attribute; therefore, the RTQEL's will be given
to the task in the order three, one, two, four.
If queue management is not used, the RTQEL's for
independent tasks in the waiting queues can accumulate indefinitely unless the tasks can process their work
requests faster than they are generated. Queue man-
20
Spring Joint Computer Conference, 1969
agement provides additional controls over the requests
in the waiting queues by limiting the maximum number
of RTQEVs held for independent tasks. It can also be
used to indirectly control the system load by not giving
work to an independent task until another independent
task has completed processing.
The number and structure of RTQ's is determined
entirely by the user. An RTQ can contain work requests
for any number of tasks, and any number of RTQ's can
contain work requests for the same independent task.
The point to be made here is that queue management is
very versatile in that it can be used in many ways to
regulate the system's \-vork flow.
Data and time routing concept
One of the characteristics of many real time, on-line
systems is that they are driven by the arrival of data to
be processed and by the passage of time; i.e., some processing is accomplished by the programming system
because certain data have arrived while other processing
is accomplished because certain reports and displays are
required at specific times. Another characteristic found
in the R TCC system is that much of the processing is
very repetitive; i.e., the same kinds of data come again
and again, representing different positions of the spacecraft or different data points for the various telemetered
activities that are being monitored. In developing
RTOS/360, and the independent task concept, it was
recognized that a mechanism was required which would
examine all types of input data and cause them to be
sent to the appropriate independent tasks for processing. This mechanism is called data routing, and it acts as
an interface between the hardware interrupt servicing
function and the resident nucleus of RTOS/360. Data
routing is a simple mechanism which requires only that
the applications programs execute a macro instruction
to identify the directives to RTOS which link a type of
input data to an independent task. When input data is
received in the system via the 2902 ::\fLA, RTOS compares the data with the current data definitions established by the applications programs. If a match is found,
the data are routed to the independent task that will
process them. If no match is found, the message is discarded. Data routing can also be instructed to accumulate a number of data messages (for example, input
messages) for the same independent task and generate
a request for the task only after the number of messages
specified by the user have been received. In this case, all
the accumulated messages will be sent to the independent task as one request.
As stated above, work requests may be gener,ated
according to the passage of time also. For example, an
independent task may be created to control a program
which updates the position of a space vehicle every
second. The only data necessary to perform this operation is the position of the vehicle a.t the last second and
some orbit and velocity parameters. Since this operation is controlled by an independent task, the necessary
data and parameters can be saved in the task's resource
table while it is dormant (possibly out of main memory).
Since data arrive in a random manner and not nece~
sarily sequentially or on a time cycle, there is no metllOd
m:ing input data which will cause requests to be generated for the task which must process a request each
second. Therefore, time routing must be used to generate the required results. To use time routing, a problem
program requests that a certain independent task is to be
activated Bot a certain time or cyclical when a given
delta time has elapsed. RTOS/360 routing and time
management functions will then activate the independent task at the time requested. If the activation is to be
continuous, it is left to the problem programmer to
request the activation's end.
The data and time routing functions (which operate
under a system task) have been constructed so that
their functions can be combined. For example, it is
possible to request the accumulation of data under
data routing with requests generated by time routing
on some specified interval. Each request generated will
contain all the data accumulated during the last interval. Another way of using the combined functions is
that messages can be accumulated over a timed interval and request generated either when the interval expires or when specified numbers of data messages have
been received in the system, whichever event occurs
first.
Time management
The System/360 ::\10del 75 computers used to support X ASA's real time applications are equipped with a
special high-resolution (lOJ,Ls accuracy) G::\1T (Greenwich ::\lean Time) clock and interval timer. In order to
provide support for this special hardware, a time management supervisor was developed for RTOS/360 which
functions in parallel with the standard OS/360 time
management routines. The time management supervisor
maintains the system thne in a job step pseudo clock,
and it controls the setting and interrupt processing from
the G::\IT hardware to keep time and service interval
timeout requests from the routing function and other
areas of RTOS/360. Additional functions have been
added to the time supervisor which provide optional
controls over the job step pseudo clock.
RTOS
It was necessary to develop a Real Time Input/Output Control System in RTOS/360 which would service
real time input/output requests rapidly and efficiently,
perform special device-dependent data manipulation,
and support the special real time input/output devices.
at the RTCC. RTIOCS is comprised of five logical
parts discussed in the following paragraphs.
A real time access method performs device-dependent
data manipu.lation and sends output messages to the
special real time output devices at the RTCC. In addition, standard sequential System/360 output devices
(2400 tapes, 1403/1443 printers) may be substituted for
the special RTCC devices simply by altering the UXIT
designation on cards in the user's input job stream. The
real time access method is also used to control the reading of information from the IB~.vI 2250 and 2260 graphic display units. This section of the real time access
method functions closely with the graphic display
attention control routine, and together, these two areas
of the real time I/O control system provide RTOS/360
users the ability to read information from the IB::'v12250
or 2260 devices. Writing on the display devices is controlled by the real time access method alone. In this
case, the displays are processed as normal real time
output requests.
The real time interrupt servicer and start-stop input
routine provides software control over the real time
input devices at the RTCC. The interrupt servicer
passes input data to the data routing and logging functions in RTOS/360. The start-stop input routine accepts data whenever an active routing request is present for each particular device. An OS/360 OPEN" /
CLOSE is not required.
The digital display control routine provides centralized and simplified control of the special R TCC devices
called digital television displays (D /TV). This control
program is entered by user tasks signaling the change
of status in one or more of the displays, The current
status of the display is updated by the control routine,
and it then gives control to the real time access method
which updates the actual hardware display.
The digital/TV display control routine provides a
software support for the Philco digital/TV display
system at the RTCC. This program services all digital/
TV display requests, maintains information indicating
which displays are currently being viewed and the con8ol,.~ which is viewing them, controls the dynamic alloca·
tion of the digital/TV channels, and generates work
requests for the user tasks which create and update the
actual numbers or figures wit: ':'1 each display.
Data management-data tables
The large amounts of data required to be accessed by
the Mission Systems at the RTCC during spaceflights
prompted a careful evaluation of the OS /360 Data
i\1anagement methods. First, it was found that
although the methods were adequate for the environments for which they were designed, the RTCC real
time environment nroduced a llnim]p, ~it.1Hdi{)n in urhinh
system overhead needed to be reduced for reading and
writing data. Second, there was no efficient means to
enable RTOS independent tasks to share data. Third,
due to the critical importance of data in the system, a
means to ensure data integrity and consistency had to
be developed. Finally, an easy method had to be developed to allow users a simple method of reading and
writing data, thereby eliminating the need for complicated coding techniques. The resolution to these
RTOS data management problems was the development of control programs to support data tables.
Data tables are blocks or arrays of data maintained
on direct access devices (2314 disk) in the partitioned
format. (Data tables are treated as members of partitioned data sets.) Each datg table is identified by its
unique EBCDIC name and is defined by its block size
and number of blocks. A data table generation program
employs these parameters in allocating direct access
space for each table, providing the controls required to
access it, and storing its initial data in the direct access
space provided.
The main utility of data tables is the additional
facilities provided by the data table control programs.
Here, the standard OS/360 Data i\1anagement OPEN/
CLOSE logic has been eliminated, thereby increasing
the speed at which data can be read or updated. Data
can be used commonly by any number of different
tasks. The data table programs provide methods of
"locking" data tables which ensure data integrity and
consistency by delaying any tasks which try to write
into a data table until the table is "unlocked." In this
way, various portions of a table can be read through
different requests and the user is ensured that no update has taken place between requests.
...
.
_____
~
Real time input/output control system
(RTIOCS)
21
___
_ _ _ _ _ ....... _
..................
,
...... .&..&.""',1,1
Functional arear-Summary
Briefly, we placed RTOS/360 in its environment and
outlined the major modifications made to OS/360 in its
functional areas of Task l\Ianagement, I/O l\Ianagement, Time }lanagement, and Data Ylanagement to
extend it for real time spaceflight control. In addition,
we have shown the addition of two new functional
areas, Routing and Queue l\lanagement, which add
additional controls necessary for RTOS/36G to effi-
22
Spring Joint Computer Conference, 1969
ciently perform the strenuous requirements of real time
processing. However, RTOS/360 development does not
end here. Experience had taught us that many additional features and facilities would be necessary in an operating system to process and develop real time programming packages. These features are outlined in the following section.
2314 DISK
Special features and facilities of RTOS/360
Large core storage support
The IB1\1 2361 four-megabyte Large Core Storage
(LCS) is supported in three modes of operation by
RTOS/360. The first mode is to use the LCS as a means
for imprO'lJing job shop operations~ This is accomplished
by: (1) using the Le8 as assembler work space instead
of tapes or disks, thereby improving assembler execution time; (2) using the LCS as work storage for compilers to allow larger compilations to be performed in
main memory, thereby decreasing compile time and
increasing job throughput; (3) placing job control information on the LCS, thereby job throughput is increased; (4) using the LCS as a system residence device
for nonresident operating systems programs, thereby
giving faster access to them and increasing throughput.
The second mode is to use the LCS as an addressable
extension of main 'Yne'Yfwry. This is especially applicable
to large applications packages being developed on the
one-half megabyte main memory System/360 Model
50's.
The third mode of operation was initiated by the fact
that it was known from the initial development of the
Apollo mission application package that the package
would exceed the capacity of main memory and the
LeS. (The Lunar Landing ~ii88ion p.xceeds six megabytes.) Therefore, an LCS algorithm was developed
that dynamically allows the funneling of data and programs into main memory (see Figure 8, Allocation of
1:Iain l\:Iemory). Basically, this dynamic LCS allocation means that the LCS is used as a high-speed dynamically changing residence device for load modules and
data tables which are heavily used but which cannot be
contained in main storage for the duration of the need
for them. A load module or data table will be put on the
LCS when it is requested and is not presently on the
LCS. As long as the load module or data table is frequently used, it will be retained on the LCS; when it
appears that the load module or data table is no longer
required on the LCS, it may be replaced with another
load module or data table.
It is possible to identify load modules and data tables
with such low response requirements that they need
never he placed on the LCS, i.e., residence on a direct
access device is sufficient. Conversely, some load
4 MEGABYTE
LCS
1 MEGABYTE
MAIN
MEMORY
Figure 8-Allocation of main memory
modules and data tables are very critical; therefore,
these may be permanently "locked" on the LCS.
To support the third mode of LCS operation, a Large
Core Storage Access Method (LeSAM) was developed
to provide the R TOS control program with a facility of
moving blocks of storage from the LCS to main storage
or from main storage to LCS. LCSAM will perform the
data move either with the normal System/360 instruction set or by performing a.n I/O operation through
the storage channel, depending on the size of the block
of data.
Real time linkages
Two problems encountered in large real time systems
required the development of a feature in RTOS/360
called Real Time Linkages. The first problem pertains
to the fact that the system library subroutines referenced by standard OS/360 load modules (programs)
must be included within each module when built by
the 08/360 linkage editor. This requirement often
results in a large duplication of system subroutines
present in main core at one time. This duplication can
be very wasteful since the amount of main core available
is reduced, and the amount of time required to load a
module is increased, and the amount of space required
to hold the module on a direct access device is increased.
Real time linkages solve this problem by allowing load
RTOS
modules to reference common resident reentrant library
subroutines.
A second problem pertains to the fact that certain
constants (such as the diameter of the earth) used in the
real time missions must be identical to all programs and
be under close control by the coordinators of the total
application mission system. The real time linkage
mechanism solves this problem.
By holding task priorities in a common parameter
table, the system can be "tuned" by simply changing
those priorities found in that single tab]e rather than
performing a reassembly of a large number of programs.
Real time linkages resolve all the external references
that a load module cop.tains for system subroutines or
common parameters when the module is loaded into
core for execution. The system subroutines and common
parameters are loaded into main core during real time
initialization and held there for the duration of the run
(job step). Therefore, the addresses of these routines
and parameters can be inserted into the appropriate
external address constant fields contained in a module
as it is loaded so that the cost at execution is no greater
than if they appeared in the load modules in the norma]
fashion.
Logging
In most real time applications, especially those which
require post-run analysis, it becomes important to perform some type of recording activity which saves the data
received, transmitted, and processed by the system.
This feature is referred to as logging in RTOS/360.
Logging automatically records all real time input and
oatput messages on magnetic tape. Also, a macro instruction has been provided which will write problem
program generated information on the log tape if an
application programmer wants a record of selected
data or processing results.
Simulated input control
One important factor, which is almost essential in the
of real time systems, is the ability to send
simulated input data to the applications programs. In
real time environments, it is impossible to employ or
always obtain the necessary equipment to produce
"live" data for all applications program checkout. To
solve this situation, RTOS/360 contains a feature
termed Simulated Input Control (SIC), which allows
the uer to run his development programs with simulated input data in an attempt to find most interface
proble'llS between modules and programming errors
prior t ) final checkout with actual data.
The SIC programs which operate as part of RTOS/
develop~ent
23
360 obtain the simulated input data from cards or tape,
or both. All data have a time of receipt associated with
each data message which allows SIC to send each one to
the data routing function when the time of receipt on
the message equals the current internal computer time
(job step pseudo clock time). This in turn generates
requests for independent tasks which will process the
data as if they were a real time message. For convenience,
the SIC package has been designed so that magnetic
tapes produced by the logging function can be used as
SIC input sources without special editing. The SIC
programs will pass over all output messages on the log
tape and send only the input messages to the data
routing function.
Fastime
Another special RTOS/360 function that has become
very valuable at RTCC is Fastime. Fastime is often
used in conjunction with SIC when testing new areas of
the user's system. Its only function is to step the job
step pseudo clock when there is no system activity.
Fastime operates as the lowest priority task in the
system so that it is entered when there is no other
activity. If the Fastime program running under this
task determines that there is no further work to be performed before the next routing request, the time management function is signaled to step the pseudo clock to the
time of the next routing request. One can see that many
hours of computer time can be saved because the system
will not wait for the actual passage of time to generate a
time queue if the system becomes inactive, as time
queues will be generated immediately when idle C;PU
time occurs. This function is further enhanced in SIC
runs because the SIC programs use time queues in
determining the exact moment a message is to be sent to
data routing. Therefore, in a SIC run, time may be
stepped to the time of the next data message. This message will be immediately sent to data routing and then
to a task for processing. In this way, simulated data
messages can be given to tasks as fast as the tasks can
process them, thereby reducing the actual computer
time to Mst new programs. By using Fastime with SIC,
the checkout of an 80-minute orbit can be performed in
about 10 minutes. Fastime and simulated input control
have no place and are not used when the system is
performing its real time production work. These functions are used only in testing new versions of the application systems.
Display- formatting language
There is a large variety of display devices at the
RTCC that have different internal format requirements.
24
Spring Joint Computer Conference, 1969
There is a high probability of change in these devices,
their internal formats, and the displays shown on them.
This changeable character of the display devices increased the need for a series of display formatting
programs. To meet this need, RTOS/360 programmers
designed and developed a versatile display formatting
language (DFL) which isolates the applications programmers from the unique characteristics of each display device and the internal format changes resulting
from modifications to those devices.
The display formatting process consists of two steps.
First, the user must define his display by assembling the
DFL format macro instruction with his program. The
format macro instruction expands into a "format statement" or character stream when assembled.
This character stream provides the display format
controls used by the DFL conversion routines in the
building of an actual output block for the desired display. During execution, the applications programmer
can prepare output data for a display by executing the
DFL conversion macro instruction. When the conversion routines complete processing and return control to
the calling program, the data are in converted form and
ready to be sent to the device specified by a particular
control card (DD card) in the job control language for
the job step. The user can subsequently output the
data to the display device via the real time access method portion of the real time I/O control system. The conversion routines build output blocks for a particular
device. The device is specified by identifying to the conversion routines the DD name of the DD card for the
data set. From this information, the conversion routines can identify the particular device whICh is to receive the converted data and activate the appropriate
conversion modules. This means that the DFL package
provides complete device independence among those
devices supported (see Figure 9, Device Independent
I:ispla.y Language).
Through the simple alteration of control cards in the
mer's job stream, the user can alter his display devices.
This feature can be very valuable when the actual display devices are not readily available. The applications
programmers can code and debug their display programs using common or standard devices, such as IB:;VI
1403 printers. When t.he display devices become available, the programs will be ready for actual production
work after changing the appropriate control cards.
The d3vices currently supported by the DFL package
are printers: IB.M 1403, IBNI 1443; display devices:
IB1\'J 2250, IBl\l 2260, Raytheon l\lCVG, Philco
RTCC Digital/TV; plotters: RTCC X-Y Plotboards,
RTCC Scribers; and Teletypes. The device independence feature and some of the devices supported by D FL
are also shown in Figure 9.
FORMAT STATEMENT
RTPUT
~
®
II
I
ITPUT
RTPUT
)
aBJ
ItAYTHEON COMMNY
MCVG
RTPUT
I
!
!
\
\
HELP
--
-\
IBM 2250
DISPLAY UNIT
PHILCO COlPOIATION
TV
Figure 9 ---Device independent display lang uage
Fail-safe programs
Because of the critical nat.ure of real time manned
spaceflights, it is extremely important that RTOS/360
be able to process abnormal conditions so that it is
virtually impossible for a portion of a flight to go unmonitored because of a software, data, or hardware
failure. Four areas of software support have been developed and included in R TOS /360 to meet this need:
selectover, high-speed restart, error recovery, and time-out.
Selectover is performed by exchanging the operational roles of the :\'Iission Operational Computer (MOC)
and the Dynamic Standby Computer (DSC) without
interruption to the input/output data on the real time
interfaces. During Selectover, the integrity of the mission outputs is maintained.
The Apollo mission support system operating under
RTOS/360 in a System/360 lVIodel 75 with one megabyte main storage and four megabytes LCS, may be restarted in less than 10 seconds on an alternate Model
7!> computer system which may be idle, processing job
shop, or performing real time test operations. This is
accomplished through IBIVI Channel-to-Channel Adapters (CCA) which link each comhination of two out of
five machines. An Initial Program Load (IPL) sequence
is generated from a remote console to the proper CCA
on the operational computer system, simultaneously
RTOS
enabling the CCA path between the two systems. A
special IPL hardware modification enables a restart
even if the machine to be restarted is in manual state.
All of allocated storage is then transferred over the
CCA from the operational system to the selected standby system before resuming in the restarted system. A
similar restart can be performed from magnetic tape by
creating the tape on an operational computer and
carrying it to the standby computer for IPL. (This
operation takes about five minutes.)
The error recovery package of R TOS allows the
system to recover from errors due to the program errors,
hardware-malfunctions, or abnormal conditions arising
within the system itself. As recovery occurs, appropriate messages and recommendations are printed
which indicate the current status of the system. A part
of the error recovery activity includes device switching,
i.e., if one I/O device fails, RTOS will automatically
(or by external signal) select another device of that
type. When the control program detects an error condition, an end-of-tape, or when a user requests a device
switch, Alternate Device Support (ADS) is invoked to
locate an alternate unit of the same device type and
perform the necessary adjustments to allow the alternate to replace the primary device. RTOS/360 programs contain built-in logic which allows recovery
from a situation where an alternate is unavailable. The
computer operator is informed on the console typewriter of all device switching operations. Currently,
device switching is provided for the 1052 typewriter,
tapes, printers, and 2314 disks.
Certain I/O device failures are such .that an interrupt to the CPU is never generated to signal the completion of the I/O operation or an error condition. A
software timeout facility exists in RTOS/360 which
will check once per second to determine if an I/O operation has not completed in a period of time which is
normal for the particular device. When such an occurrence is detected, the I/O operation will be purged and
appropriate messages will be printed. Normal use of the
device will be attempted on subsequent requests.
Since the former was far too expensive, a programming
system was developed specifically for RTOS/360 that
allowed all the peripheral functions normally associated
with off-line support computers to be performed in the
single l\10del 75 CPU. The system was called the Houston Automatic Spooling Priority (HASP) system.
HASP acts as a dependent task under RTOS/360 (cohabitates in a single CPU with other RTOS/360 operations) and uses small amounts of prLlllsry CPU thne to
operate the peripheral functions. These functions include transferring the job stream to direct access to
await execution, collecting job output on direct access,
and printing and punching job output from direct
access following job execution. Jobs awaiting any stage
of processing (print, punch, or execution) are queued on
a priority basis so that the effect of a true priority
scheduler is gained not only for normal job execution
but for associated peripheral functions as well.
A complete "warm start" capability also exists in
HASP so that untimely interruptions of the system will
cause no loss of job input or output queued for processing under HASP. Sophisticated operator communications exist that provide control over the number of
input job streams, the number of output devices, and
the order of job executions.
Background utilities
There are many utility functions in any data processing operation, especially a system which employs
disks, that must be performed. These include: dumping
direct access volumes to tape, restoring direct access
volumes from tape, copying and comparing tapes,
labeling tapes, changing volume serial numbers on
direct access devices, etc. This is especially true when a
large variety of applications systems are under development as in the RTCC. Utility operations usually require the complete dedication of the computer while
they are being performed. This dedication was found to
be unrealistic from both the cost and time required;
therefore, all utility operations were designed so that
loon
tney COUla operate III --oacKgrounu-- unuer 1\,.1VO/OUU
control as dependent tasks. These background utilities
execute asynchronously with the normal job processing
and can be initiated and terminated by the computer
operator at the console typewriter.
.'1
Houston automatic spooling priority system
The tremendous development effort required to meet
critical mission schedules requires that the computer
systems be used to the maximum at all times during job
shop operations. It was known from the onset of Apollo
development that either a large number of "peripheral"
off-line support computers would be required to perform such operations as loading jobs for execution and
printing the vast amounts of output (usually large core
and LCS dumps) or the Model 75 computers would
have to be used to their maximum CPU availability.
25
,
,
I ·
tll
1
",
1
T"'\rnACt
Job accounting system
With the large number of computers being used by a
vast array of development groups, it was found tbt
the R TCC required a means to report accounting and
system measurement data. This was accomplished by
the inclusion of a set of programs called the Job Ac-
26
Spring Joint Computer Conference, 1969
counting System (JAS). Since all computer operations
at the RTCC are under control of RTOS/360, JAS
automatically generates, through punched cards, a
data base for three types of reports which are valuable
for both the accounting and system measurement purposes. The three report types are:
• A Job Shop Analysis Report which provides job
mix and computer system performance statistics.
.A Computer Utilization Report which is used to
charge compute! time to user.
• A Management Report which provides information
on program development costs through statistics
on the use of the computer by individual programmers.
r-----------------------~-l
MASTER
SCHEDUliR
~~TIATOR
TERMINATOR
JOt INITIATOR
TERMINATOR
JOt INITIATOR
TERMINATOR
~~~:SOUND
JOt
HASP
SYSTEM
L ________________________ J
Statistics gathering and modeling activities
Each Apollo mission presents the RTCC with a
unique set of processing requirements. For example,
real time data sources may change in number, arrival
rate, or message size. These and other such factors
cause changes in the performance of real time computing
systems. So that changes do not cause the systems to
perform below acceptable limits, performance of current
systems is measured and that of future systems is
modeled. 2
To measure the performance of a real time system
and monitor its execution, a comprehensive Statistic
Gathering System (SGS) was developed. SGS is a program and not a hardware device attached to the computer. It provides an accurate means of measuring
performance on RTOS/360 by collecting:
• Timing information on control program services
and application programs
• Percentage figures showing how definable system
functions use the CPU resource
• Elapsed time figures showing task response time in
a multiprogramming environment.
The SGS design for RTOS/3oo is patterned after an
earlier version used with the Gemini 7094 Executive
Control Program.
The Real Time Computer Complex is not a project
that is blessed with a firm definition of mission requirements. Results of each mission impose requirements for
future missions and, thus, levy new demands for real
time support. It is essential to the orderly development
of RTCC real time systems to anticipate problems in
computer system configuration or system program
design that could impair the success of future missions.
To analyze future system performance, RTCC uses
models written in the language of the General Purpose
Simulation System (GPSS/3OO).
Figure Io-A multi-jobbing/multi-tasking RTOS/360
Information obtained from SGS is used in these
modeling activities.
Multi-jobbing in RTOS
Within this paper, it has been shown that RTOS/360
in the real time environment is a multi-jobbing system
in the broad sense; i.e., a real time job step can be processing several independent paths of logic (independent tasl{s vthich could be termed jobs since the)T sb...are
the system resources) at the same time the multi-tasks
are performing, and the background utilities and HASP
are also vying for the CPU. However, after careful investigation of statistics obtained from SGS and JAS, it
was found that large amounts of time were still spent in
the I/O wait state, and that the full computing power
of the System/3oo Model 75 was not being used. Therefore, the final feature to RTOS/360 was developedreal time mUlti-jobbing under RTOS/3oo control.
The RTOS/360 multi-jobbing differs from the OS/360
multi-jobbing in that RTOS/360 does not require partitioned memory nor, of course, a fixed number of tasks.
An illustration of RTOS/360 multi-jobbing is shown in
Figure 10, A Multi-jobbing/Multi-tasking RTOS/360.
CONCLUDING REMARKS
The development of real time control systems for
spaceflight programs has been an evolutionary
~~ ASA's
RTOS
process. For the Mercury Program, IBM devel?ped the
Mercury Monitor, which performed only real tIme control and occupied only a small portion of an IBM 7090
computer. Next came the development of the real time
Executive Control System for the Gemini program.
Executive occupied about 13,000 words of an IBM
7094-11 computer. The third system in this evolutionary
process was the RTOS/360, which is presented in this
paper. RTOSj360, a 150,000 byte system, was the first
system not only containing real time control facilities,
as in the Mercury Monitor and Executive, but also
containing the complete gambit of operating system
functions (assemblers, compilers, job shop processing
techniques, etc.).
Today, RTOS/360 has not only successfully su~ported
several NASA Apollo Missions, but because of l~ real
time facilities and special features, coupled with the
current OS/360 System, is being used by other installations outside the RTCC to meet their special require-
27
ments for a real time operating system.
ACKNOWLEDGMENTS
I wish to acknowledge the contributions of all those
members of the RTOS departments whose documents
and comments aided in the preparation of this paper.
Special thanks go to Ray Strecker and Ken Adams,
whose technical documents on RTOS were a major
source oi iniormaiion. For ihe encouragement to write
the paper, I wish to thank W. D. Pollan.
REFERENCES
1 J JOHNSTONE
A real time executive SY8tem for manned 8paceflight
Proc F J C C 1967
2 W STA...~LEY H H E R T E L . ';
Statistics gathering and simulation for the apollo re4l ti1iU
operating system
IBM Systems Journal Vol 7 No 21968
A panel session-On-line business applications
On-line business applications
by JOHN T. GILMORE, JR., Chairman of Session
Keydata Corporation
Watertown, Massachusetts
For purposes of background and personal introduction, I would like to begin by stating a few facts about
Keydata and its services.
Keydata Corporation was founded in 1959 by
Charles Adams and myself and was originally called
Adams Associates. Until 1965, when we became the
first to offer time-shared business data processing
services, our main activity was the design and implementation of real-time, graphic display, and online process control systems. That activity is now
being carried on by our Keydata Associates Division.
The Keydata system, centered in Watertown,
Massachusetts, consists of a private dedicated teletype network that extends as far west as Missouri and
south to Delaware. The primary concentration, however, is in New England and Metropolitan New
York. Three kinds of computers are used. The
UNIVAC 494, utilizing Fastrand and high-speed
fixed-head drun1S, is the time-shared processor and
wil1 be duplexed with another 494 before the end of
this year. Honeywell DDP-516 computers, used as
teletype line monitors and message concentrators,
are strategically located geographical1y within the
network to minimize communication costs. An IBM
360 Model 40 is the batch-oriented off-line processor.
Based on the kinds of service we are now providing,
the system has a capacity of 800 to 1,000 lines with a
response time of less than two seconds. Our present
load is about 175 lines with access to more than
630,000 records or 92 miHion characters. Our basic
services are distribution accounting and accounts
payable. Certain services are used by a small number
of subscribers and other services are under development.
We call our system a "business computer utility"
because it provides the businessman with computer
power and programs that serve as an efficient tool in
operating his company. Like the telephone and
electrical utilities, we provide our services through
on-line tenninals located at his place of business and
operated by his employees who are trained in his
company's activities and who are not-and need not
be-specialists in the service provided by the utility.
Right now, the average businessman would be
satisfied to have his conventional data processing needs
fulfilled without costing him an ann and a leg and
confusing the hell out of his employees. However, once
this is accomplished and he realizes what else is possible,
he'll roar like a lion. Will we in the computer field be
readS for him?
The businessman has as tough a problem to solve as
the scientist-perhaps even tougher if one counts his
variables and unstable conditions. His basic problem
is his data base. He cannot watch it or experiment with
it as easily as his brother scientist or engineer can. More
often than not, his access to "current" infonnation in
his data base is measured in several days to weeks-by
which time it is far from being current. However,
modern co~puter technology and on-line communication techniques will enable him to keep his data base
current and available in milliseconds. With this kind of
luxury he could rapidly become as sophisticated a
computer user as his scientific friend. When he does,
and when there are many like him, the impact on the
business community will probably cause the operations
research textbooks to be rewritten and the economists
to take a second look at their crystal ball!
What it boils down to is this. On-line business applications, whether on-line to one's own computer or to a
computer utility, will provide a dynamically updated
________________________________________ 29 ______________________________________
30
Spring Joint Computer Conference, 1969
data base. Once that occurs, the businessman will be in
a position to request the initiation of various operations
either at will or automatically. This will provide him
and his employees with the timely information essential
to the efficient operation of his company. Changes in a
data base will automatically cause reactions to other
parts of the same data base and, through the use of
communications, changes to other data bases, etc.
For example, in performing its invoicing and inventory control function, our system signals the terminal operator when a re-order point is reached based
on the quantity just processed in the invoice being
prepared. The re-ordering of the item is now being done
in the conventional manual way. But the time will soon
come when the computer will communicate directly
with vendors of the item, compare prices and delivery
dates, and order a specific forecast-calculated quantity
of the item from the vendor selected. The same reorder example might instead trigger a production
order message to another terminal in the plant or
perhaps directly to a process control computer. The
examples could go on and on, but the main theme
assumes a data base that is being dynamically processed.
Among the questions I feel the panel should discuss
are:
• What are some of the problems in dynamic data
base systems? What protection must be provided
to safeguard information? What kind of reliability
and availability criteria should there be? What
kind of back-up procedures should be employed?
• To the businessman, each successive stage of developing what for him will be the optimum system
has to be economically justified. V\rhat are some oi
the major impasses? What are the intermediate
payoffs? What kind of time period are we talking
about for a sophisticated computer-oriented business community?
• What industries or job groups may suffer from a
drastic increase in on -line processing? What government intervention, if any, can be anticipated or
perhaps urged?
.l\-fost of us in the computer field see the computer
and its p()wer as a valuable tool to the business
community. Are we missing anything? For example, will it cause a major cleavage between the
unskilled or semiskilled and the bright workers and
managers who will use the computer tool to run the
plants and offices? Will the leisure class ironically
consist of the rich and the unemployed even more
so than it does today?
On -line business applications
by CHARLES T. CASALE
Paxon Corporation
Sunnyvale, California
If we look at business applications which are truly
on-line today, we see far fewer than were predicted four
or five years ago when time-sharing and on-line systems
were promised as ultimate solutions. Why is this so? I
believe there are several reason, intertwined, which
have in tum caused secondary effects. I would like to
review some of these briefly.
On-line as a philosophy
To some, on-line reaches the proportions of a religious
belief: it is good for everyone, there are ceremonies,
there are the articles of faith, and there are the missionaries and prophets. In fact, there are large numbers of
people who simply reject onlinism or say that they
simply don't need it. At least not now.
Much of the reason for apparent slippage in implementing on-line systems comes from the earlier
prophetic statements of dire need. If dire need is "assumed, then it can be reasoned that an economic
solution is not far behind.
The degree of need
There is real need for on-line, "instant verification"
of credit cards at gasoline filling stations to capture
voided or stolen cards. So far, we have no systems
filling this need since we don't need the systems badly
enough to pay the current price. The technology is
there. On the other hand, the benefits of having quick
retrieval of airline seat availability are worth the cost
to the airline. So we have large airline seat reservation
systems .
How loud are the demands for on-line inquiry of the
weekly payroll file? Or accounts payable? Or for change
in status of major sales prospects? The promise of
"instant data" in management information systems is
proving illusory in many cases; the information just
doesn't change that frequently, or to that degree, to
warrant the expense and complexity of an on-line
system.
The transition period
The transition from an "old style" manual system to
a fully on-line automated system is an undertaking as
On-line Business Applications
enjoyable as crossing the Italian Alps by elephant in the
winter. It can be done, but the participants and bystanders are loath to ever repeat the experience, at
least in the foreseeable future. Hardly an issue of the
popularized computer magazine 'goes by without at
least one glamour or horror story of the transition pe-riod. These periods take time, rub nerves raw, chew up
valuable resources that others think could be used elsewhere, and are full of surprises. When finished, the
accomplishment is indeed impressive ... so much so that
we are reluctant to make any changes to the new system. This brings us to some other matters:
Who is going to do the system?
First, there is the jurisdictional problem. Secondly,
there is the resources problem. Where do we find skilled
people to plan and implement the system, who will
maintain it, how will they explain it to its users? The
shortage of skilled practitioners need not be restated.
The shortage is responsible for delays in putting
business systems on-line. Once installed, how do
we keep it current? With what tools? Can the system
grow gracefully, or must it be abandoned when it gets
modestly larger?
31
Central storage costs and central computer hardware costs
These continue to decrease relatively, and each year
sees a lower threshold of economic entry. However,
logic and electronic costs are decreasing at a faster rate
than storage costs. Consequently, main frame manufacturers are adding more logic to a given storage size
to do a more sophisticated job. Weare beginning to
see parts of software systems being hardwired into
Conlputer-s as a cheaper way to get the job done. This
same phenomenon of rapidly declining logic costs has
given rebirthto the mini-computer.
The mini-computer
What it lacks in capacity it makes up in muscle. With
storage being the majority hardware expense and more
logic being condensed onto one semi-conductor chip,
the present types of mini-computers will tend to become off-the-sheJf components marketed by distributors
and produced by the memory houses. What this means
to on-line business systems is smaller subsystems
operated relatively independent of the parent data base.
Weare already seeing specialized subsystems based on
"standard" mini-computers.
Specialized subsystems
Profits and returns
After the fact, what are the real bottom-line profits
that the system gives me? Can I show a return on this
sizeable investment comparable to my other business
investments? Are the marginal benefits being used to
justify more than their proportionate costs?
Where do we go from here? What are the
trends?
I t would be useful to look at the major influencing
factors that will accelerate or impede progress towards
more and better on-line business systems. Some of
these are in conflict, others are synergetic.
Data transportation costs
For a given quantity of data, rates decrease slowly.
For the same costs, the quantity of data that can be
pumped over common carriers increases much faster.
Consequently) the threshold of economics for cost
justification remains reJatively constant; but once
justified, the marginal costs of transmitting additional
data are small. This will be changed when the full
impact of the Carterfone decision is implemented. The
result will be a lower threshold caused by reduced
termination costs.
Data acquisition, data distribution and highly structured repetitive tasks can be performed more cheaply
with specialized subsystems than by a general-purpose
system. This is true only because of the continued decreasing cost of logic and storage. We have seen the
success of this in the keypunch replacement area, where
no loss of system capability is experienced in using keyto-tape devices instead of the more generalized and
flexible keypunches.
The programmer gap
::vruch has been said, and much is being done about it.
there just aren't enough of them around to
get done all of the jobs that are on the drawing boards.
And it seems that the gap doesn't close as fast as many
expect.
~1eanwhile,
Programming costs
These are increasing because of personnel shortages
and because there is a Parkinson effect about any productivity increase made in programming. While today's
programmer can produce (via higher-level languages)
ten times what he could ten years ago, the job is enlarged to an even greater multiple. Documentation demands are considerably greater and productivity increases have been significant.
Spring Joint Computer Conference, 1969
32
Consequences of these trends for on-line business systems.
Large data bases will continue to prosper and flourish,
as will their extensions, the time-shared terminals. In
addition to this, an entire sub-industry will mushroom
based on successful exploitation of the disparity in
trends among decreasing hardware costs, rising software costs, and relatively level transportation costs.
The results will be specialized subsystems, ranging
from a few thousand dollars to several hundred thousand dollars. They will be application-oriented, limitedpurpose and highly cost-justifiable.
the years ahead. It is helpful to review the main issues
and examine the actions taken to date as a basis for
distinguishing trends and anticipating future policy
and legislation. The intelligent businessman today cannot afford to become fully preoccupied with hi~ own
plans and problems in a framework shaped solely by
competitive forces. The role and influence of the federal
government should be studied and understood.
On =Iine business applications
by WILLIAM M.
On-line business applications
ZA~I
Harvard Graduate School of Business Adminisfraliurl
Allston, Yrassachusetts
by MARTIN GREE~BERGER
The Johns Hopkins University
Baltimore, Maryland
The federal government is destined to play a kev
role in the future development of on-line business
tems and the stn1.cture of the new industry grov.-mg up
around them. Six points of contact already are evident:
sy;-
1. Anti-trust action (real and implied) as in the
current cases against IB~1 and AT&T.
2. Inquiries on the practices and policies of the
3.
4.
5.
6.
conununications conunon carriers as in the recent FCC inquiry on the relationship between
computers and conununications, and the now
discharged Task Force on Telecolnmunications
appointed by Lyndon Baines Johnson.
Hearings on privacy and associated rights of the
individual as conducted last year by Congressman Ga1lagher and Senator Long.
Legislation on copyrights and other possible
mechanisms for protecting computer software.
Encouragement of standardization and economy
measures as in the Brooks Bill alid intended
activities by the National Bureau of Standards
the General Services Administration, and th~
Bureau of the Budget.
Direct and indirect subsidies of development
through research grants, purchase of services
and equipment, and support of education.
A great deal of government participation and in.has go~e on in the past year, and every
IndlCatlOn IS that Its pace and scope will intensify in
:ol:e~ent
On-line computing systems are a relatively recent
development in conunercial computer technology.
Most of the experience to date with the use of such
systems has been gained at universities, large governmental organizations and a few pioneering businesses
like American Airlines, Westinghouse and Keydata
Corporation. Today, from the literature and recent
announcements of computer plans, it appears that online systems are ready to be implemented in many
organizations to perfonn a large variety of tasks.
There are experts predicting that by 1970 the majority
of computer systems sold win be perfonning some online functions. Huge growth is expected to occur in
computers capable of operating on an on-line or timeshared basis.
Much of the growth in usage of on-line systems will
be economically justified. The on-line systems have the
pot~ntial to dramatically change business data processmg and the manner in which business will be conducted. On-line business systems can be used to improve decision making, the operations of a business and
customer service. Certain aspects of decision making
can be improved with on-line systems because a problem
solver is 2 ble to test on-line to the computer several
alternatives and get immediate feedback of results.
The interaction of a problem solver with a computer may
provide an understanding of a problem and its solution
that is not possible to achieve with the long delays in the
computer-generated answer cycle of systems without
on-line capabilities.
Operations of a business improve with on-line computer systems because the reduction in data processing
delays can be used to reduce inventories, provide more
On-line Business Applications
efficient distribution systems and more effective production schedules. Westinghouse has implemented an
on-line inventory control system for its distribution
network, and was able to close seven warehouses and
dramatically reduce the level of inventory required.
On-line systems have the potential of improving customer service by insuring a complete stock of goods and
enabling faster response to customer requests. American Airlines was the first to use an on-line passenger
seat reservation system. The company expected increased passenger sales to result from its ability to process customer requests more speedily and accurately.
While much of the growth of on-line computer use
will be justified, a significant portion of on-line use will
not and cannot possibly be economically justified.
Many companies will repeat the same mistakes in
switching to on-line computers that were made when
computers were first introduced into their organizations. Many companies could not economically justify
their original computers, but they purchased them
because:
• their competition had a computer and they felt
they could not compete successfully without one;
• the companies wanted to keep up-to-date with the
latest management techniques, and
· the computer offered many subjective advantages,
such as quicker and more information.
Companies, because of the potential advantages of
on-line systems, are in danger of being caught up in a
whirlwind of unnecessary and uneconomical change.
While on-line business systems can be extremely
valuable, this value is not automatically achieved nor
is it applicable to every business situation. Before any
company decides to implement an on-line system, it
must examine the economics of the specific applications;
otherwise, expensive mistakes can be made. The reasons
for this follow.
33
On-line computing systems do not automatically
improve operating performance. They generally increase the speed of information flow in an organization,
but if this speed is not used or needed it has no economic
value. On-line systems will generate operating savings
only if the reduction in information delays are meaningfully integrated into a management process, and if
the reduced information delays can improve a company's
operations.
On-line systems do not necessarily provide a marketing advantage vis-a-vis competition which does no
use such systems. The nature of the industry, tht
competition and business may not provide an oppore
tunity to gain a competitive advantage. It would be
erroneous to impute the competitive advantage gained
in the airline industry by American Airlines to companies that use on-line systems in all industries. The
generalizations of competitive advantage from on-line
systems must be made carefully and only after considering whether: (1) on-line systems can improve cus-tomer service, and (2) the improved service will result in
increased sales. It is therefore not necessary to use online systems simply because competition is doing so.
Depending on the nature of the industry, a company
using traditional data processing equipment can satisfactorily compete with a company using on-line systems.
In an evaluation of whether or not to implement an
on-line system, it is not sufficient to state that on-line
systems are better simply because they provide more
rapid information flow. It must be shown how and why
the quicker information can be used, and the potential
savings that can be related to the faster availability of
information. If a company does not have a clear idea of
the specific benefits an on-line system will provide and
how these benefits are to be achieved, on-line systems
should be evaluated on a cost displacement basis; that
is, the method of data processing that performs the
required functions at the lowest cost should be selected.
A panel session-Computers and the underprivileged
JAMES H. BURROWS, Chairman of Session
Th£ Mitre Corporation
Bedford, Massachusetts
Computers and the underprivileged
by MILTON BAUMAN
Price Waterhouse and Company
Philadelphia, Pennsylvania
A group from the Delaware Valley Chapter of AClVl
have joined together to form the Urban Education
Committee. :Members of the committee believe that,
in these days of urban crisis, the data processing industry offers a unique opportunity to the disadvantaged
to become involved in the mainstream of the American
way of life.
Mter several abortive attempts to determine where
to employ its professionalism, the Committee has decided upon several projects recommended to it by
different groups within the city of Philadelphia. These
projects include providing counseling on data processing
to the Pennsylvania Employment Service and Philadelphia high school counselors; providing advice and
counsel to the Board of Education on the data processing curriculum taught in high schools; providing
data processing consulting to the Philadelphia Urban
Coalition; and; most. important, running a computer
operator training course in a Philadelphia high school.
The computer operator training course is being given
to 20 high school seniors from Thomas Edison High
School. The Philadelphia Board of Education was asked
to provide the students. We requested that the students
not be college bound, but be of such caliber that would
probably insure the success of the training program.
The Board of Education, in turn, asked the Principal
of Thomas Edison to select the students whom he believed showed leadership qualities and the intelligence
necessary to successfully complete the progr~m. The
20 students finally decided upon were selected from a
--------------------------------------35
group of 48 recommended by the Thomas Edison
faculty.
The training program meets Wednesdays and Saturdays. The curriculum is aimed at IB.:.v1 360/30 operator training and extensive hands-on training will be
provided. The curriculum is divided into two parts. The
first sessions deals primarily with training on punched
card equipment to provide the students with a background in data processing and operations done on computers. The 360/30 training will concern itself primarily
with IBM's Disc Operating System.
The curriculum for the course was developed by a
sub-committee composed of three members. We attempted to obtain curricula from other AClVl chapters
who had gone down this road; but the other chapters
had not, when w.e were beginning the program, formalized their curriculum to the point where we could use it.
It became necessary, therefore, for the suo-coIIlmittee to
collect operator training manuals from various computer manufacturing organizations and from private
sources.
Developing the curriculum was only one of several
problems that were encountered when the program was
started. Other problems were finding instructors (paid
instructors, not volunteers), obtaining funds for paying
for instructors and field trips, etc., finding machine
time (both punched card and computer), and, finally,
placing the students in jobs after graduation (we were
advised that if students were trained and were not
placed in jobs, the training would be at best worthless,
36
Spring Joint Computer Conference, 1969
or even worse than no training at all). I can report, at
this juncture, money has been donated, that instructors
have been hired, machine time has been donated, and
12 of the 20 students have been placed in various companies throughout Philadelphia and the Delaware
Valley.
In summary, the technique used by the Delaware
Valley Chapter in becoming involved in urban affairs
was by becoming involved-headfirst. We collectively
made up our minds to do "our thing" and, with a little
urging from the Board of Education, we did it. We had
a few anxious moments in getting started without having
all of our problems resolved, but the fact that we had to
resolve them in a short period of time made us devote
that extra amount of effort necessary. If we had held
off our program until all problems had soiutions, our
course probably would not have started in 1968, but
rather in 1969 or perhaps never.
Our plans for the future include a similar program in
a Camden High School (we do have a number of interested members from RCA at Cherry Hill, New
Jersey) and expansion of our Philadelphia program to
another high school.
aspect of recent technology, e.g., lasers, computer systems.
A basic program for the first sector in computer programming was established. The tuition to the school was
set at five dollars, a figure low enough to exclude an
absolute minimum and yet still be a commitment on the
part of the student. The response to our notice in local
newspapers, radio and through public relations channels
at 1V1.LT. was overwhelming. For lack of staff to screen
applicants, the first five hundred were accepted. Although our largest interest was in providing access to
education for ghetto dwellers of limited resources, our
inability to screen applications resulted in a net of
about 140 hardcore "deprived" out of the total of five
hundred. Of these 140, about 70 percent were black.
Five graduate students at N1.l. T. provided the instruction and were assisted by ten l\1.I.T. undergraduate teaching assistants. The plan is to initiate a chain
of lectures by asking successful teaching assistants each
year to lecture the following year. We focused on the
140 hardcore "deprived" assigning seven of the M.LT.
teaching assistants, most of whom were black, to those
students. These students were divided into smaller
tutorial sections of ten to fifteen students headed by one
of the teaching assistants. Teaching assistants were also
available for consultation in the keypunch rooms.
An -:.\tLl.T. student-run computer company has
offered to assist in a placement service for these students. vVe feel that follow up to the program is very
important and is presently very weak.
An advanced systems programming course was
offered to the second sector of the community, the
highly educated sector. We accepted 80 into that program. We feel that these programs will tend to complement each other in t.ha,t t.he advanced program will
be taught to people who may later assist or influence the
hiring of those in the other program.
The basic program will be expanded to include
courses in computer maintenance, Boolean algebra,
basic business algebra and other practical courses. As
technology changes business trends change; the program will be modified to fit the needs for training in the
changed environment. It is our overall purpose to offer
courses broad enough to establish a basis for training in
a particular area. We do not pretend to offer a substitute
for the broad knowledge acquired from a college education. We do try to offer a program in a specialized area
which has two undeniable attractions: job opportunities
and subject excitement. Computer programming is such
an area.
A program for the underprivileged and
overprivileged in the Boston Community
by JOH:\' .J.
DO~()V AN
M assachusetis Institute of Technology
Cambridge, MaHsarhu:.;etts
In response to the needs of the Boston Community,
a new direction has been taken in the Lowell School, a
school under the auspices of the Massachusetts Institute
of Technology, which will offer education to the community for no more than the cost of two bushels of
wheat. The program focuses mainly on the needs of two
sectors of our community.
One sector is those individuals who are undereducated
and underemployed, many of whom are the "llnderclass" of the ghetto, suffering from the crippling syndrome of education-motivation-employment deprivation. The other sector is those senior men of industry
who are very well educated but need retraining in some
o..-_ _ _ _ _ _ _"--......;;:.=_ _ _ _ _ _ _
-"
~""~"
_-~"~.~
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __
Computers and the Underprivileged
What the JOBS program is all about
by WILLIAM B. LE\VIS
U.S. Department of Labor
Boston, Mass~,d1Usetts
One of the thorniest problems in America today
is that of the habitually unemployed people living
within the inner core of our 50 largest cities. For a long
time employers and organized labor have written them
off as unemployables. The U.S. Department of Labor
has, over· the years, tried various approaches to these
hard-core jobless, with uncertain success.
In January 1968, President Johnson announced a
program of Job Opportunities in the Business Sector
(JOBS). The new program looked to industry to apply
its full resources and "know-how" in cooperation with
the Government, to help break the cycle of unemployment of the hard-core by making them permanent
productive mem bel'S of the labor force.
In announcing the JOBS program, the President
said he was calling on American industry to establish a
National Alliance of Businessmen (NAB) to launch it,
help achieve its goals, and advise the Government.
Under the leadership of Henry Ford II, NAB was
created early in 1968 with leading local businessmen
volunteering to spearhead the effort in the 50 largest
cities of the country.
The K AB goal for JOBS is to put 500,000 disadvantaged persons in jobs by June 1971, with an
interim goal of 100,000 to be placed by June 1969.
The JOBS program involves a commitment by employers to hire workers first and train them afterwardbuilding on the accumulated evidence that initial placement in jobs at regular wages does much more to motivate a disadvantaged individual than a training period
before employment with only a promise of a future job.
The program puts at the disposal of industry the services and financial support of Government, which experience has shown are essential if the disadvantaged
unemployed are to receive the range and depth of services required to help them become productive workers.
The cooperating companjes provide jobs and training
for hard-core unemployed workers and bear as much of
the cost as would be involved in their normal recrui tment and training operations. The extra cost of added
training, counseling, remedial education, prevocational
training, health services, and other specialized support
needed to bring disadvantaged individuals to a satisfactory level of productivity and keep them on the job
may be offset by funds provided through a Department
37
fo Labor contract. In order to encourage smaller companies to participate, an optional standardized program
approach has been developed. Intensive efforts have
also been made to give cooperating employers all possible technical assistance in developing plans and formal
proposals.
The first-year NAB goal of 100,000 hard-core persons
on the job has been reached by the JOBS program ahead
of schedule.
A full assessment of the JOBS program results is not
possible at this early stage, but it is apparent that the
start made is highly promising. The attitude of participating compames is generally either optimistic or
enthusiatic, and they concur regarding the validity of
the JOBS idea and intent.
The immediate effect of the JOBS program has been
to employ those formerly thought to be unemployable.
However, the benefits of JOBS are more far reaching.
The skills gained through the JOBS program open the
doors to advancement to those formerly without hope.
110reover, what the private employer's experience in
the JOBS program has taught him about the problems
of the hard-core and the possible solutions to their
special problems will, in a large number of cases, have
a spillover effect on the company's regular training and
employment practices.
Computers and the underprivileged.
by ALLE~ L. MORTON, JR.
Computer Personnel Development AssociaMon, Inc.
Xew York. Xew York
Statem.ent of objectives
The Computer Personnel Development Association;
Inc. (CPDA) is an organization that has been set up to
secure openings in the computer field for individuals
from ghetto areas. To prepare these people for work in
a business environment, CPDA will provide orientation
and training courses in data processing. The program
is organized by professionals within the computer
industry in collaboration with local community development groups who will help select participants for the
program, and with industrial leaders who will locate and
provide job opportunities for the participants.
The long term objective of CPDA is to establish
career paths in the computer industry for our students.
38
Spring Joint Computer Conference, 1969
This will be accomplished by providing continuous job
training and career guidance in all areas of data processing.
The following points define the broad areas of
CPDA's capabilities.
1. Computer Operations Training Program-Training ghetto personnel judged capable of completing a training program in computer operations and functioning in this capacity within the
data processing area.
2. Computer Programmer Training ProgramTraining similar personnel who are in a position
to complete a training course in computer programming and to function as programmers.
3. Job Placem.ent and Development-Yloving graduates of the above programs from the training
phase into jobs which will be identified prior to
and concurrent with training.
4. Career Guidance-Providing follovy up procedures to smooth the students' transition from
the training to the business environment.
5. Related Personnel Services-~laking available
to management on a consultant basis more
precise selection and training procedures for
minority group personnel.
Implementation of the above program will provide
an opportunity for untried minority group persons who
show a potential for achievement. This program will
serve as a source for desperately needed technicians in
the data processing field as well as provide a program
which realistically meets the job-related directive of
the President's Bipartisan National Commission on
Civil Disorders.
OUf first project is a pilot program to train ann place
computer operators. This program is limited in scope
but can succeed only with the active support of industry.
Experimental and demonstration
manpower projects
by JOSEPH SEILER
U .S.Department of Labo'f
Washington, D.C.
The U. S. Department of Labor's experimental and
demonstration (E and D) program seeks to develop and
test through actual project operation, new ideas and
techniques to meet manpower problems more effectively. Projects focus on the particular problems which
impede employment of Lhe unemployed and underemployed and which are not being met effectively by established manpower program methods. They seek,
through innovative techniques and new types of organizational arrangements, to determine how the programs
might better "reach" and help prepare such workers for
jobs, place them, and retain and upgrade them in gainful employment.
Because each project is specially designed, experimental and demonstration projects are not readily
categorized. They differ widely, not alone by group or
problem focused upon, but by technique or combination
of techniques tried and, of great importance, by type of
institution or combination of institutions enlisted to
conduct the effort.
The groups concentrated on have been primarily unemployed ghetto area youth, minorities with cultural,
emotional and other handicaps to employment, lowincome rual residents, and older workers with limited
education.
Although the E and D program's key objective is to
stimulate and guide innovation rather than to provide
services directly, it does provide significant assistance to
the thousands of participants in its projects.
~l any of the techniques for delivery of manpower
services have been developed or refined in E and Dsponsored projects. Briefly, important concepts which
E and D efforts have helped pioneer and introduce
widely into manpower programming include:
(a) outreach to identify, attract and retain participation of the disadvantaged who do not come forward on
their mvn for needed. manpnwer services; (h) multi-service programs and centers to provide comprehensive
service on a coordinated readily -accessible basis; (c)
work sampling to evaluate the potential of those with
limited education and to build the confidence of those
with limited communication skills; (d) prevocational
training, work orientation and related preparation as
an aid to effective skill training and employment; (e)
use of nonprofessional and indigenous staff as a vital aid
in manpower development for the disadvantaged; (f)
new occupations, particularly as subprofessional aides
in human service activities, to broaden opportunity for
the undereducated; (g) use of community and minority
organization capabilities to complement government
agency manpower development efforts; (h) inducements for employer initiative and action to hire, orient,
train, and retain workers customarily regarded as "unacceptable"; (i) post-placement coaching and "high
support" to enable employers and disadvantaged
Computers and the Underprivileged
workers to overcome difficulties jeopardizing job retention in the initial months after hiring.
1\Tore specifically, the following are major examples
of types of E and D accomplishments:
The major new Concentrated Employment Program
(CEP) and Job Opportunities in the Business Sector
(JOBS) manpower programs, initiated in part on the
basis of E and D findings, were given significant start-up
assistance by the E and D program:
1. lUany features of the CEP have been designed
from examples developed by E and D projects.
The orientation, coaching, and employer involvement components particularly are based on
E and D-developed models. Several E and D
projects, most notably the JOBS NOW program
in Chicago, provided the initial staff training
and technical guidance for CEP personnel. And
key staff needs in several of the initial CEPs were
filled by personnel drawn from E and D projects.
The E and D program also developed specific
guide materials on job development methods,
orientation and coaching to assist the new CEPs
in such activities.
2. The new JOBS program initiated with the
National Alliance for Businessmen was similarly
influenced by E and D pilot experience The
findings of several E and D projects shaped the
guidelines for JOBS efforts, and materials developed in the E and D program have served as
basic resources for JOBS employer-contractors.
0
New ways have been developed by E and D projects to
open and improve employment opportunities for the
disadvantaged in major occupations:
1. E and D projects in Cincinnati and Washington
have with union cooperation been exploring how
to provide work preparation and experience for
disadvantaged, particularly minority, youth to
enable them to enter building trades apprenticeships and employment in housing renovation and
construction. These projects have been looked to
as practical examples to aid development of
Model City program guidelines for employment
of neighborhood residents in ghetto rebuilding.
2. A demonstration project with the Post Office
Department has developed a technique which
other Federal agencies are considering to help
overcome test barriers to employment of the
disadvantaged. Workers unable to pass civil
service tests were recruited and hired on a temporary basis and, after special instruction while
39
employed, a high proportion were enabled to
meet the test requirement for permanent employment-and have performed effectively on
the job.
Techniques are being developed to help employers upgrade their unskilled workers. A pilot E and D effort
provided brief but intensive in-plant training to workers
in traditionally dead-end jobs to qualify them for upgrading to newly designed higher-level jobs which the
employer might not otherwise fill from his own employees. The employer response to this project has led
to its extension for further development in new projects in three major cities, preparatory to likely largerscale application iOn the near future.
Techniques are being developed to help identify the
"real" job potentials of disadvantaged persons. The
disadvantaged person's lack of skills and insufficient
knowledge of his own capabilities combined with his
usual very poor performance on paper-and-pencil tests
all conspire to qualify him in the eyes of the counselor
or personnel man for only the most menial dead-end
jobs.
Work sample tests, originally developed by sheltered
workshops for physically and mentally disabled, have
been shown by E and D to be useful with the disadvantaged as a substitute for the unworkable written tests.
The work-sample technique has been refined by the
Philadelphia Jewish Employment and Vocational
Service in an E and D project that has led to a ten-city.
pilot operation that will further extend our knowledge of
its utility as an approach to appraising the job potentials
of the unemployed.
Other interesting E and D efforts in their early stages
are:
1. Crime problems. E and D efforts on several proj-
ects are designing systems with courts and police
to develop training and employment as an alternative to criminal prosecution and imprison
ment.
2. Job Zart{iuage facility. Projects are focusing, not on
basic literacy as such, but on "job English" for
Spanish speaking workers and on "occupational
language" for workers with limited literacy
backgrounds.
3. Employer Based Day Care. One project is exploring the feasibility and value of an employer
sponsored day care center as an aid in recruitjng
the inner-city unemployed for existing job vacancies, and as a means of enhancing employee job
stability and performance.
40
Spring Joint Computer Conference, 1969
The E and D program's emphases will steadily shift
as earlier findings are absorbed by established programs
and attention is required by emerging new manpower
problems and by a growing need for measurement and
analysis of relative effectiveness of alternative approaches.
A panel session-Computers in service to libraries
of ihe fuiure
CALVIN N. MOOERS, Chairman of Session
Rockford Research Institute Incorporated
Cambridge, Massachusetts
Computers in service to libraries of the
future: Library requirements
by
w. N. LOCKE
Massachusetts Institute of 'Pechnology
Cambridge, Massachusetts
An outstanding computer engineer recently compared
libraries to the whaling industry, a relic of the romantic
past. As whales disappeared, so will books, he said. We
should stop building libraries, store all information on
tape and retrieve it through consoles.
This may be acceptable as a piece of blue skying but
hardly comes to grips with the problems of information
handling today and tomorrow. At a time when the
world outpouring of written words is going up ten percent a year (an estimated 300,000 books and 100,000
serial titles in 1968), it doesn't make much sense for
librarians or anybody else to plan in terms of a replacement of print by any other form in the near future.
So let's come down out of orbit and talk about
mundane facts. Libraries cost dollars and serve people.
For dollars they compete with other goods and services.
The people they serve are as diverse as the population.
Some just want. a quiet, comfortable place to read or
think; others want a particular book or journal; still
others want all the information you have on some
special topic; some need items that have tQ he located
and brought from some other lihrary. Then there are
those who want to check a fact, a name, and so on. The
library has to he all things to all people. And this
requires complex organization, specialized staff, and
constantly expanding space: it requires a lot better
inventory control techniques than we now have. This is
the challenge to computerniks. If they want to take over
and operate the information handling husiness, they
must do so in a real world of program budgets and cost
benefit analysis. They must also work closely with
librarians to provide a transition from the present to the
future.
It might be well to look at today's information
retrieval in the library context, see how much of it goes
on, and calculate the cost. This amount is in the budget
and presumably available for a computerized service.
The total is not encouraging. Additional services that
can he provided hy the computer will have to be costed
out and budgeted for next year or some future year.
At present, it is the customer who does most of the
information retrieval; only he, and frequently not even
he, knows what he wants. The library staff spends most
of its time on document handling, acquiring, cataloging,
and retrieving, not information, but books and book-like
materials in dozens of forms, fuB size and mini, plus
maps, music scores, manuscripts, sound and video
recordings. The library is the memory of the race. It is
different from the memory of the individual in that the
individual's memory is associative while the library
deals with discrete packages. Cataloging is a poor but
expensive suhstitute for what goes on automatically
and suhconsciously in our minds as we record our
experience.
About 33 percent of the average library personnel
budget goes into the preparation and filing of information about the many kinds of items that come into the
lihrary. This input can as well go into a computerized as
41 -------------------------------------------
42
Spring Joint Computer Conference, 1969
into a manual system; but it is hard to see how savings
can be effectuated by a computer at this point unless we
can get machine readable input ready-made from a
source like .:\IARC II tapes. If it is cheaper to process
these tapes to find the descriptive and subject catalog
information for individual items as they come to a
library, rather than get it from printed copy or originate
it, then we will Use them. Unfortunately, present
indications are that it may cost more.
Storage is one of the cheapest things we have today.
Even amortizing land and building cost, we can keep
reference books a year on the shelf for 20¢ apiece.
At;j =\f bits each, this is 4¢ per million bits per year. The
card catalog is somewhat more expensive at 48¢ per
year per million bits. Add an annual increment of eight
percent or so atld costs of conventional storage are still
bearable. Not so the costs of on-line storage, \vhieh is
the only conceivable forin of computer storage for this
ty·pe of material.
The numbers are not much better for present day
library reference staff work in information retrieval.
Reference work and catalog service may account for
about ten percent of the personnel budget of a large
library. Half of the time of these professionals may go
into information retrieval. Assuming that they will have
to spend a good deal of time training customers in using
the computer, we may be able to save half the present
budget to put toward the machine. This will not go far.
In fact, my conclusion is that computerized information
retrieval will require practically all new money. ~Iajor
new financial support will be needed for large scale
information retrieval, SDI and other individualized
computer based services which we in the libraries want
to provide.
Librarians have always been quick to adopt new
technology, for instance for catalog card production,
for micro storage, for quick, expendable copies. Computers are no exception. They are urgently needed now
for inventory control. If we can afford anything that
computers have to offer, it is this.
Using computer technology-Frustrations
abound
by HENRIETTE D. AVRAM
Library of Congress
Wa~hington,
D. C.
The automation of libraries is a fairly recent entry to
the growing number of areas of applications for computers. Is this an indication that librarians have been
resisting advancing technology or could it be that the
process of controlling large stores of information is so
complex and the hardware, software, and brainware
still too limited to cope with this complexity? lVlight it
also be that computer specialists, underestimating the
challenges, have evinced little interest in the library
problem?
My experience in the library world suggests that these
states and conditions have all combined with negative
effect. The function of a library is to provide reference
service to users and to make readily available the
contents of its collections. The efficient performance of
this function is directly related to the successful and
timely completion of processing, Le., the selection
acquisition, cataloging, classification, and shelving of a
book. The rapidly increasing number of books and
periodicals places the greatest strain in this area and
thus pinpoints the prime candidate for mechanization.
Before discussing one of the major automation
activities at the Library of Congress and its associated
problems, some facts about LC are in order to set the
environmental background. The Library of Congress
has in its collections about 55.5 million items: books,
serials, maps, music, prints and photographs, manuscripts, etc. Approximately 75 million records contain
the control information and bibliographic description of
this collection. I ts largest file, the Official Catalog,
contains some 14.5 million records. An inventory of files
showed that there are about 1,260 different files which
are used in the Library's operations. Under Title II-C
of the Higher Education Act of 1965, the Library has
been charged with the additional responsibility of
acquiring and cataloging all works, published anywhere
in the world, important to scholarship. The materials
flowing into the Library include items written in 70
different languages, represented by 20 distinct alphabets.
One of the basic functions of librarians is the recording
and organizing of bibliographic data to facilitate access
to and use of the books and other materials contained in
the collections of libraries. Although bibliographic data
may be recorded and stored in a variety of ways, the
card catalog record has been the preponderant medium
used by libraries in the United States. The bibliographic
information on the catalog record is basically of two
kinds: (1) a description of a book in terms of author,
title, etc., and (2) some kind of notation to be used in
locating the book on the shelves. The locating notation
also usually comprises a means for arranging together
materials on the same and related subjects. A catalog
record distinguishes in a unique place one book from all
the other books represented in the catalog. The catalog
Computers in Service to Libraries of the Future
card, with its basic information, can be used again and
again to provide multiple access capability-usually
Ituthor, title, subject-and forms the basis of what is
known as the unit card system. Essentially librarians
Bl"e attempting to organize and make readily available
the intellectual output (books) of other humans in all
disciplines. This involves the application of a rather
complicltted set of rules to the output of very unpredjctable human ~ings; the result being that it is safe
to say that a1m~t every rule will find its exception
manifested.
Since the Library of COJlgress is the major source of
bibliographic infon:rmtion for the American library
community, it was naturQ.l to conduct an experiment at
LC to test the feasibility a.nd utility of centrally
producing cataloging data and di$tributing these data
to users. Project MARC (foJ' MAcbin~-Readable
Cataloging) was in operation for 19 JIlQntM in. ~st and
pilot phases involving sixteen coopel'tt-ting libraries. The
project was successful and a full operational system
providing selected machine-readable cataloging data for
all interested libraries will begin early in 1969, During
the pilot period, recommendations for improvement
were received from the participants, a cost mod~l was
maintained, and the procedures for preparing bibliographic data for conversion to machine-readQ.ble form
and the processing of these data were improved. The
format for the interchange of the record was evaluated
by staff members of many organizations: the Library
of Congress, the National Library of :M:edicine, the
National Agricultural Library, the United States of
America Standards Institute Z39 Subcommittee 2 on
Machine Input Records, the Committee on Scientific
and Technical Information (COSATI), and other
interested organizations both here and abroad. The
result was the adoption of a format designed for the
interchange of data and hospitable to the bibliographic
description of all forms of material.
The format for monographs as adopted by the
Library of Congress has four important characteristics:
1. It establishes the means by which bibliographic
information may be transmitted between
libraries.
2. It describes the rigorous rules by which bibliographic information, available in human-readable
form, may be converted to machine-readable
form.
3. It suggests that if the same format is used for the
exchange of information by all libraries, programs and procedures may be exchanged and
automation costs reduced.
4. It follows the United States of America Standards Institute Code for Information Interchange
43
(ASCII), the standard for Recorded Magnetic
Tape for Information Interchange, and the
proposed standard for Magnetic Tape Labels and
File Structure.
The library community, although operating in a very
imperfect world in terms of having both second and
third generation computers, configurations progressing
from minimal to maximum (when is a 1401 a 1401 ?),
and I/O devices not capable of handling the necessary
character sets, has forged ahead to adopt standards.
This is a significant step forward.
The introduction of computers to libraries poses
special problems in file organization and hardware while
providing new opportunities for multiple access to
information. We are faced with deciding how information can best be structured and stored for effective
retrieval. Imposed on top of all classic functions
performed by librarians, i.e., acquisitions, cataloging,
classification, reference, is the function of searching. The
search argument varies with the inquiry. It ranges from
data on an order slip to the information on the title page
of a book, to the Library of Congress catalog card number, to a name in an authority file. The questions of file
structure-where in the file to search and when to
stop searching-are related to discovering the criteria
for the determination of identity. The human mind has
certain categories of analytic capability which cannot
yet, if ever, be captured by machine. Therefore, we
must create ploys which cause the machine to approach,
in effect, the desired objectives.
Studies at the Library of Congress show that the
storage requirements for 1972 is 4 X 1()9 characters.
Int.eresting developments in hardware technology in the
next five years should partially resolve the problems
of large random access stores at acceptable costs. If we
can approach an efficient solution for organizing
information and consequently retrieving from the files,
one nagging question that remains is how best to
convert the files and in what order of priority. Because
libraries cannot limit coverage in time and discipline,
files reflecting the past must in time be converted to
machine-readable form. Many conversion strategies
have been proposed and the final decision must be based
upon reasonable grounds as to use and cost. The
conversion of bibliographic information requires specifications for the representation of this information in
machine-readable form, i.e., decisions regarding data
elements that need explicit identification and the
definition of a character set for input, storage, and
display. The character set needed to encode bibliographic data is essentially infinite because it is openended. Not only are we concerned with many hnguages
in a multiplicity of alphabets, but in addition, any
44
Spring Joint Computer Conference, 1969
ij,l,lthor can use any character at will. The obstacles then
become challenges seeking creative solutions.
Librarians and computer scientists have rarely
communicated well with one another, and this lack of
communication results from the fact that each group is
too parochially oriented to its own field. Both groups
are ~ctually ~triving toward precision but each sees
pr~cisiQn hi a different way. The librarian is concerned
with pre.cision in the definition of the record, for he
must be p~cise in this definition in order to uniquely
represent ~ book for retrieval. The computer person is
interested in precision in method,· i.e., an exact descriptioll of a process, so that his program will perform
efficiently and produce the output required. Machine
people have a tendency to minimize the librarian's
problems of precision and exhibit a general reluctance
to become interested in the data except as it affects the
computer application. Without a complete understanding of the co:rnple~ty of the data, the capabilities of the
computer are. oversold, thus later causing what might
be. tenned a credibility gap. Librarians, on the other
hand, must recognize the potential and the limitations
of the new technology and provide the necessary
guidance for the efficient use of communication and
information manipulation devices.
Success will not come overnight but will depend upon
the combined efforts of the most talented people that
can be found in many disciplines.
Computers in service to libraries of the
future
by HOWARD W. DILLON
Harvard University
Cambridge, Massachusetts
Automation activities in libraries have been undertaken with accelerating frequency over the past ten
years. I t is no longer uncommon to find successful
projects in almost every type and size of library
throughout the country. Libraries have demonstrated
that they can develop and operate ordering and
processing systems to control financial and bibliographic
information at the time a new item is added to the
collection. Book catalogs and other holdings lists are
produced and distributed in many formats. Automated
circulation control systems, particularly the data
collection type, are widely accepted and functioning
successfully.
This portion of the panel discussion will describe a few
projects with which the speaker is familiar. The projects
selected have been chosen because they represent major
attacks on problems which must be solved in order for
all libraries to move forward with automation.
A recurring problem for systenis of library processing
developed over the past years has been the reliability of
the data first entered into the system at the time a
purchase order is placed. In off -line systems, the need to
edit or replace the information used at the time of the
order with better data obtained when the item purchased
is in hand has been a critical update problem. FeVwr
systems; therefore; attempted to carry computer processing from ordering through to the completion of
cataloging as one integrated system. On-line processing
capabilities and the development of a nationally
distributed, timely bibliographic record by the Library
of Congress in the NIARC II communications format,
make it more likely that integrated technical processing
systems for libraries can be made operational.
Second, given a communications format for the
sharing of bibliographic data, libraries with common
processing requirements are undertaking to share in the
cooperative development and design of processing
systems. Standardization and compatibility have been
hallmarks of library systems for many years. While not
always perfectly achieved, librarians have traditionally
demonstrated their concern with the sharing of bibliographic data and collections. The advent of computer
processing has not altered that basic philosophy. Rather,
it provided an opportunity to realize the goal of
compatibility with greater perfection.
Systems to be considered in this presentation will
include:
SYlVIBIOSIS-SYstem for Medical and BIOlogical
Sciences Informat.ion Searching
NELINET -The New England Library Information Network
The Integrated, Computer-Based, Bibliographical
Data System for a Large University Library,
being developed by the University of Chicago
Library, including the subsequently coordinated
activities of Columbia and Stanford university
libraries in this acquisitions and cataloging
system.
Computers in Service to Libraries of the Future
The Washington State University Library Technical Services System, which is a project to
develop an on-line processing capability for that
library.
45
The presentation will review the objectives of these
projects, summarize their accomplishments to date, and
discuss hardware or operating system software problems
encountered.
Batch, conversational, and incremental
compilers
by HARRY KATZAN, JR.
Pratt Institute
Brooklyn, New York
INTRODUCTION
Compiler-writing techniques have received a great deal
of pragmatic and academic attention and are now fairly well-defined. * It was and still is generally felt that the
compiler is independent of the operating system jn
which it resides, if it resides in one at all. The invention
of time-sharing systems with conversational capability,
however, has required that compiler experts re-evaluate
existing concepts to make better use of external
facilities. This was done and conversational and incremental compilers have evolved. A generalized and
consolidated discussion of these relatively new concepts
is the subject of this paper. First, a model of a batch
compiler is introduced. The concepts are then modified
and extended for a conversational programming environment. Finally, a recent development termed
"incremental" compilation, which satisfies the needs of
both batch and conversational compiling as well as
interactive computing, is presented. First, some introductory material is required.
Basic concepts
In the cla~:::;ical data processing environment, ** t.he
"compile phase" or "souree language pl'ocet):sing phase"
is of prime importance as are definitions of source program and object program. The latter are redefined in
light of the time-sharing or iuteractive environment.
Extran~ous items, such as where the object program is
stored or whether or not the compiler should produce
assembler language coding, are practically ignored.
The source program is the program as written by the
• Two books devoted entirely to the subject are worth mentioning: Lee, J.A .N., 'Phe Anatomy of a Compiler,l and Randell, B.
and L. J. Russell, Algol 60 Implernentation. 2
*. See Lee,l p. 9.
programmer. It is coded in symbolic form and punched
?n cards or typed in at the terminal. The object program
IS the program after being transformed by the compiler
into a machine-oriented form which can be read into
the computer and executed with very few (if any)
modifications. Also of interest is the information vector
which gives initial conditions for compilation and denotes the types of output desired. A sample of specifications which might be found in an information vector
follow: (1) location of the source program; (2) name of
the program; (3) the extent of compiler processing, i.e.,
syntax check only, optimize, etc.; (4) computer system
parameters; (5) compiler output desired; and (6) disposition of the object module. The form of the source
program is sometimes required, although in most cases
this information is known implicitly. This pertains to
different BCD codes and file types which may range
from sequential or indexed files on conventional systems
to list-structured files in virtual machines.
Similarly for output, the user can request a specialized
form of object module or none at all, source or object
program listing, and cross-reference listings. The object
module is known as a Program Module which contains
the machine language text and relocation information.
Additionally, it may contain an Internal Symbol Dictionary for use during execution-time debugging. The
Internal Symhol Dictionary is especially useful in conversational time-sharing systems where execution can
be stopped on a conditional basis and the values of
internal variables can be displayed or modified.
Batch compilation
Batch compilation methods are required, quite naturally, in a batch processing environment. The term
"batch processing" stems from the days when the programmer submitted his job to the computer center
47 ----------------------------------
48
Spring Joint Computer Conference, 1969
and subsequently received his results later in time. A
collection of different jobs was accumulated by operations personnel and the batch was then presented to the
computer system on an input tape. The important point
is that the programmer has no contact with his job between the time it is submitted to operations and when he
receives his output. The concept has been extended to
caver .:\1ultiprogramming Systems, Remote Job Entry
(HJE), and the trivial case where no operating system
exists and the programmer runs the compiler to completion.
The generalized bat.ch environment
The most significant aspect of the batch processing
envirOlllllent is that the entire source program is available to the compiler initially and that all compiler output can be postponed until a later phase. The compiler
writer, therefore, is provided with a liberal amount of
flexibility in designing his language processor. For example, specification (i.e., declarative) statements can
be recognized and processed in an initial phase and
storage allocated immediately. In the same pass, statement labels are recognized and entabled; then in a
later phase, validity decisions for statements that use
statement labels can be made immediately rather than
making a later analysis on the basis of table entries.
If desired, source program error diagnostics can be
postponed. ::.Yforeover, the designer may specify his
compiler so that the source program is passed by the
compiler or so that the compiler is passed over the
source program, which resides semi-permanently in
memory.
This inherent flexibility is not exploited in the compiler model which follows. Instead, an attempt has been
made to present the material in a conceptually straightforward manner.
A generalized batch compiler
By itself, a model of a generalized batch compiler is
of limited interest. The concept is useful, hmvever, for
comparison with those designed to operate in timeshared computer systems. Therefore, the presentation
is pedagogical in nature as compared to one which might
present a step by step procedure for building one.
Processing by the compiler is rather naturally divided
into several phases which tend to be more logical than
physical. Each phase has one or more specific tasks to
perform. In so doing, it operates on tables and lists possibly modifying them and producing nmv ones. One
phase, of course, works on the source program froin the
system input device or external storage and another
produces the required output. The entire compiler is
described therefore by listing the tasks each phase is to
perform; ordinarily, the description would also denote
which tables and lists each phase uses and what tables
and lists it creates or modifies. The specific tables and
lists which are required, however, tend to be language
dependent and are beyond the scope of this treatment.
The compiler is composed of five phases and an executive routine, as follows:
The Compiler Executive (EXEC). The various
phases run under the control of a compiler executive
routine (EXEC) which is the only communication
with the outside world. It establishe.s initial conditions and calls the different phases as required.
It can be assumed that EXEC performs all system
input/ output services, upon demand from the phase
modules. :\Iore specifically, the EXEC has five
maj or and distinct functions:
1. to interface "\vith the compiler's environment;
2. to prepare the source statements for processing
by phase one;
3. to control and order the operation of the
phases;
4. to prepare edited lines for output; and
5. to provide compiler diagnostic information.
Phase 1. Phase 1 performs the source program syntactic
analysis, error analysis, and translation of the program
into a tabular representation. Each variable or constant is given an entry in the symbol table, with formal
arguments being flagged as such. Initial values and
array dimensions are stored in a table of preset data.
Lastly, information from specification statements is
stored in the specification table. The most significant
Pl'ocp.ssing; howfwer, occurs wi.th respect to t.hp. Program
Reference File and the Expression Reference File.
Each executable statement and statement label is
placed in the Program Reference File in skeletal form.
In addition to standard Program Reference File entries,
the Program Referellee File contains pointers to the
Expression Heferenc(' File for statements involving;
arithmetic or logical expressions.
The Expression Reference File stores expressions in
an internal notation using pointers to the symbol table
. when necessary. As wjth the Expression Heference File,
the Program Reference File also contains pointers to
the symbol table.
Phase 2. In general, phase 2 performs analyses that
cannot be performed in phase 1. It makes storage assignments in the Program l\Iodule for all variables that
are not formal parameters. It detects illegal flow in
loops and recognizes early exits therefrom. It also
detel'lnine::; blocks uf a program with IlU path of control
Batch, Conversational, and Incremental Compilers
to them; and lastly, it detects statement labels which
are referenced but not defined.
Phase 3. The object of phase 3 is to perform the global
optimizations used during object code generation, which
is accomplished in phase 4.
The first major function of phase 3 is the recognition
and processing of common sub-expressions. Phase 3
determines which arithmetic expressions need be computed only once and then saved for later use. In addition, it determines the range of statements over which
expressions are not redefined by the definition of one or
more of their constituents. If the occurrence of an expression in that range is contained in one or more DO*
loops which are also entirely contained in that range,
Phase 3 determines the outermost such loop outside
which such an expression may be computed, and
physically moves the expression to the front of that
DO loop. Only the evaluation process is removed from
the loop; any statement label or replacement operation
is retained in its original position. The moved expression is linked to a place reserved for that purpose
in t,he program reference file entries corresponding to
the beginning of the respective DO loops.
The second major function of phase 3 is the recognition and processing of removable statements. A "removable statement" is one whose individual operands do
not have "definition points" inside the loop; obviously,
the execution of this statement for each iteration would
be unnecessary. A definition point is a statement in
which the variable has, or may have, a new variable
stored in it (e.g., appears on the left-hand side of an
equal sign). In removing statements, they are usually
placed before the DO statement.
Phase 3 also processes formal parameters and develops the prologue to the program; it optimizes the use of
registers; and it merges the Program Reference File and
the Expression Reference File to form a Complete
Program File in preparation for phase 4.
Phase 4-. Phase 4 performs the code generation function.
I ts input consists of the symbol table and the Complete
Program File and its output is the Code File, which represents completed machine instructions and control
information.
Phase 5. Phase 5 is the output phase and generates the
Program Module, the source and object listings, and the
cross reference listing. Upon request, an Internal Symbol
Dictionary is also included in the Program Module.
* Although the DO keyword is a constituent part of several
programming languages, it should be interpreted as representing
the class of statements from different languages which effectively enable the programmer to write program loops in a
straightforward manner.
49
Any compiler model of this type is clearly an abstraction; moreover, there is almost as much variation between different compilers for the same programming
language as there is between compilers for different
languages. The model does serve a useful purpose which
.
'
IS to present a conceptual foundation from which conversational and incremental compilers can be introduced.
Conversational compilation
Compared with the "batch" environment in which
user has no contact with his job once it is submitted, the
conversational environment provides the exact opposite.
A general-purpose time-sharing system of one kind or
another is assumed, * with users having access to the
computer system via terminal devices.
In the batch environment, the user was required to
make successive runs on the system to eliminate syntax
and setup errors with the intervening time ranging from
minutes to days. Excluding execution-time 'bugs",
it often took weeks to get a program running. In the
conversational mode, syntactical and setup errors can
be eliminated in one terminal session. Similarly, execution-time debugging is also possible in a time-sharing
system, on a dynamic basis.
. Conversational programming places a heavy load on
a compiler and an operating system; the magnitude of
the load is reflected in the basic additions necessary to
support the conversational environment.
The time-sharing environment
The time-sharing environment is characterized by
versatility. Tasks can exist in the "batch" or "conversational" mode. Furthermore, source program input can reside on the system input device or be prestored. The time-sharing operating system is able to
distinguish between batch and conversational tasks;
therefore, batch tasks are recognized as such and processed as in any operating system. The ensuing discussion will concern conversational tasks. It is assumed,
also, that the user resides at a terminal and is able to
respond to requests by the system.
During the compile phase, the source program may
be entered on a statement-by-statement basis or be prestored. In either case, the compiler responds immediately to the terminal with local syntactic errors. The
user, therefore, is able to make changes to the source
program immediately. Changes to the source program other than in response to immediate diagnos-
* Two typical general-purpm;e time-sharing systemR are
T&.,/36(}3·4 and MULTICS.o
50
Spring Joint Computer Conference, 1969
t.ics cause a restart. of t.he compilation process. Obviously, the system must keep a fresh copy of the source program for the restart case. To satisfy this need, a copy
of the current up-to-date source program is maintained
on external storage; if the source was prestored, the
original version is updated with change requests; if the
source program is not prestored, the compiler saves :J.ll
source (and changes) as they are entered line-by-line.
With the user at a tenninal, the compiler is also able to
stop midway during compilation (usually after the global statement analysis and before optimization) to inquire whether or not the user wants to continue. Under
error conditions, the user may abort the compilation
or make changes and restart the compilation process.
Moreover, the user can utilize this pause to have his
program syntax checked only.
During the execution phase, dynamic debugging is
often desirable. This facility is uSU811y a part of the
command structure of the operating system. In preparation for execution-time debugging, the user would probably request an Internal Symbol Dictionary during
compilation so that internal variables can be addressed
symbolically. Since execution-time debugging IS a
relatively new concept, it is discussed briefly.
Debugging commands usually fall into three categories: (1) program control; (2) program modification;
and (3) debugging output. Debugging commands may
be imbedded in the program itself or the program can be
stopped (either asynchronously or with an AT command) and the actions perfonned immediat.ely. Examples of typical program control commands are:
AT
symbolic-location ... STOP
RUN
RUN symbolic-location
Examples of program modification commands are:
SET
A
= 1.0
IF A (0, SET A = 0
Examples of debugging output commands are:
DISPLAY MAIN.I ::\IAIN.A
DUMP ARRAY
Furthennore, they can be used m combination as
follows:
AT PTWO.100
IF A = 0,
STOP
AT T34.360 DUMP T34.A SET CNT = CNT + 1
As was mentioned. earlier, a considerable amount. of
the compiler's effort is devoted. to producing an efficient
object program. As a result, the instructions to perform
certain computations are sometimes not located where
one would expect to find them. In fact, this is a direct
consequence of common sub-expressions and removable
statements, which were discussed previously. Although
these processes contribute to efficiency, they have a
side effect which hinders the debugging effort. Therefore, when expecting to use dynamic debugging, the
user should request an Internal Symbol Dictionary and
select the option which does not produce optimized.
code.
The conversational compiler and the time-sharing
operating system must support several aspects of the
conversational environment. These are sUlnmarized as
follows: (1) the ability to change or forget the effects
of the preceding statement; (2) restart logic; (3) maintenance of the entire source program, in up-to-date
form, on external storage; (4) the ability to scan statements and produce diagnostics on an individual statement. basis; and (5) the option to produce optimized or
unoptimized code.
The conversational compiler
Basically, the conversational compiler is a conventional batch-processor containing special features making it suitable for conversational, terminal-oriented.
operation.
Structurally, the major addition over a batch compiler is Compiler Control Program (CCP) , which in
effect controls compilation. CCP is cognizant of whether
the mode of operation is batch or conversational and is
able to fetch source records and dispose of output print
lines, accordingly. CCP is the facility which maintains
the source program on external storage and is able to
tell if a new source record is indeed. new, a change to
last one entered, or a change to a previous one. When
processing a request to fetch a source record for the
compiler, CCP can use this information to simply return the record, return it with the "forget" flag on, or
call the compiler at its initial entry for the restart case.
The function to fetch a source record is termed GETLINE and is summarized in Table 1. Accordingly, an
overview of the CCP is given in Figure 1.
The overall logic of the conversational compiler is
shown in Figure 2. Clearly, it differs very little from the
batch version. The differences in the compiler itself are
found in phase one and at the end of phase two. In
phase one, as shown in Figure 3, the compiler uses CCP
as its external interface. IVloreover, the compiler always
compiles a statement conditionally; later it uses the
Batch, Conversational, and Increnlental Compilers
Initial
Ent:rv
51
Continue
Ent:rv
1r
Phase 3
'n _ _ &: _ _
Initialize
Compiler
,
Figure 1-0vervie\Y of the compiler control program (CCP)
Table I-GETLINE Function of the Compiler Control
Program (CCP)
Conversational
Presto red
Not Prest.
GBTLINE
A
B
Batch
Prestored
Not Prest.
A
,
Phase 2
Assign
Storage;
~ind Global
Errors
Global
Optimization
,
Phase 4
Generate
Object
Code
t
Phase 5
Build PM
and ISD;
Prepare
Listings.
C
A.
Fetches the next source record from external storage and
returns it to compiler EXEC.
B.
Fetches another source record from the terminal input
device and updates the source file on external storage.
If it is the next source record, the line is returned to
the compiler with the "forget" flag off. If the give~
source record is to replace the previous one, the
"forget" flag is turned on and the line is again returned.
Otherwise, a previous line has been modified and the
compiler is entered at the "initial" entry point for the
restart case.
C.
Phase 1
Translate
Source;
~ind Syntax
Errors.
CC.I..l.V.I..lll
Fetches the next source record from the system input
device and updates the source file on external storage;
the line is returned to EXEC with the "forget" flag off.
"forget flag" to freeze or delete the compiled information.
After phase two, as shown in Figures 1 and 2, the
conversational compiler again exits to CCP. In the
batch mode, of course, CCP simply returns to the compiler. In the conversational mode, as shown in Figure 1,
the user is asked for changes and whether he wants to
,
Exit to CCP
~,
Exit to CCP
Figure 2-Logic of the conversational compiler
continue. At the user's request, CCP can change the
source program, still residing on external storage, and
restart the compiler at the "initial" entry. If the user
desires to continue, the compiler is entered at the "con-tinue" entry. Otherwise, CCP exits to the command
system and the remainder of the compilation is aborted.
Conversational compilation offers significant advantages over standard batch processing, most of which
deal with the interactive mode of operation. The major
disadvantage is that the entire source program must be
available before execution can be attempted. In other
words, one would like the versatility and flexibility of a
language interpreter with the performance of a conversational or batch processor. ~1oreover, the performance must be reflected in the execution time as well
as the compile time.
52
Spring Joint Computer Conference, 1969
Lock7 entitled "Structuring Programs for Multiprogram Time-Sharjng On-Line Applicat~ons" and the
second by RyanS and others entitled" A Conversational
System for Incremental Compilation and Execution in
a Time-Sharing Environment." In order that the above
goals can be realized, t~e following capabilities are required:
Initialize
1. The ability to execute a statement immediately;
2. The ability to modify a prior statement without
forcing a recompilation;
:3. The ability to execute a source program as it is
being input;
4. The ability to execute selected portions of programs;
05, A language processor that can also operate in the
batch mode.
Clearly, all of the above requirements, except speed, are
met with an appropriate interpretive program. In a
large time-sharing environment, however, this resource
is of prime importance, especially when 50 or more terminals are being serviced.
statement Processors
r------I
Last statement
+
(
The environment for incremental compilation
Return)
N
y
Delete
Previous
statement
Figure 3-Compilel' Phase 1 interface with the eompiler
eont.rol program
I ncremenlal compilation
One of the rnost promising ideas in this era of online computing is a concept termed Incremental Compilation. In an interactive programming environment,
one would like to achieve both the speed factors inherent in compiled programs and the flexibility available
with interpretive systems. Incremental compilers are an
attempt to achieve these goals. ~1uch of the pioneering
work in this area is reported in two papers: the first by
Basically, the environment for incremental compilation is the same as for its conversational counterpart.
By assuming a sophisticated operating system such as
TSS/3603.4 or MULTICS,5 many of the problems described in the cited papers by Lock and by Ryan, such
as memory protection among users, an effective command system, and memory organization and management, are obviated. Dynamic loading facilities, for
utilizing hand coded subroutines, and a memory relocation feature,9 for mapping virtual addresses to real
addresses, simplify problems involving the execution
of code compiled incrementally and are also assumed.
The programming language is naturally of importancp
and of great interest to most, systems programmers. A
language more powerful than standard Fortran or
assembler language is expected, although the techniques
would work satisfactorily therewith. A rich language
which would enable a significant amount of computation per interaction is most desirable. Languages such
as PL/po and Iverson's Languagell are well suited to
incremental compiling and executing.
The incremental compiler
This method of compilation permits two modes of
operation: batch and incremental. In the batch mode,
the user may compile prestored source program but
may not modify or execute the program during compilatioIl. In t.he incrernenial mode, normally uRed only
Batch, Conversational, and Incremental' Compilers
conversational1y, special facilities are available to permit the modification, execution; and checkout of the
program during compilation. These operations are performed through a combination of control and source
language statements.
Incremental compilation consists of accepting a
source program on a statement by statement basis.
Each statement is compiled as it is received and the
code generated for it is immediately made available for
executioll. Associative links between the source program
and object code are maintained, thus permitting the
user, during compilation, to modify his source program
and have the modification immediately reflected in the
object code. The ability to compile, execute, and modify
a program on a statement by statement basis gives the
user a degree of flexibility over his program usually
available only with an interpreter, yet reduces the
principal objection to interpreters: that of requiring an
excessive amount of execution time. While, in an interpreter, each statement must be processed each time it is
executed, in an incremental compiler it needs to be
processed only when it is entered initially or when the
user makes a source program modification. The Incremental Compiler has the added advantage of ensuring
that the object code the user tests incrementally is
virtually the same as the code produced for an object
module, since the same code generators are used in
both modes.
\\,~hen an Incremental Compiler is used in the batch
mode, all of the usual facilities are available to the user.
When used in the incremental mode, all of the batch
facilities are available in addition to those provided to
control the execution and debugging of the generated
code. During both modes of compilation, the following
options are permitted:
53
statement is a statement in the source language being
compiled which is executed and discarded immediately.
I t allows the user to intervene during the execution of
his program and print results or change values. Commands are control statements which allow the user to
make modifications outside the scope of the source
language. A good example would be to change the control point of the program.
Source program compilation and execution in the
incremental mode is under direct control of a Language
Controller (LC). Each interaction, by LC, with the
user is divided into a processing cycle and/or an execution cycle, depending upon the input parameters. The
compiler is called by LC to process source language and
transient statements and if exeoution is requested, it is
initiated and monitored accordingly. After execution,
transient statements are discarded whereas source
language statements are retained. The command system
of the operating system is called by the Language-Controller to process commands. Clearly, there is a need to
tie the various elements of a program together, for
operational reasons, and this requirement is satisfied
by the Program Structure Table, described below.
Since the Language Controller controls a major portion
of the processing when in the incremental modes, it is
structured accordingly. As pictured in Figure 4, it contains program elements for maintaining the source program and the Program Structure Table, for controlling
the compiler, for monitoring the execution of incremental code, and for interpreting and then dispatching
or processing control statements. These functions are
summarized in the following descriptions of the modules
which comprise the Language Controller:
Program Structure Routines. The program structure
routines maintain the source program on external
1. Analyze the program only for syntactic errors;
do not perform a global analysis or generate code.
2. Analyze the program for syntactic and global
errors; do not generate code.
t
•
;~. Analyze the program for syntactIC and global
The object program may be executed, in either the
batch or incremental mode, only if the third option
is selected. In most compilers of this type, the user may
select one of several modes of executing the incremental
code concurrently with compilation; as errors are UIlcovered, he may make modifications to the source language, without, in most cases, requiring a recompilation
of the existing code or affecting previous execution.
In order to provide the user with the degree of control
desired, two categories of control statements are necessary: transient statements and commands. A transient
Figure 4-Structure of the language controller for incremental
compilation and execution
54
Spring Joint Computer Conference, 1969
storage and manage the Program Structure Table,
which contains an entry for each source language
statement in the program being compiled. The relationship of statements is also established for subsequent use by the Execution Monitor.
Compiler Controller. The compiler controller provides the interface between the user and the compiler.
It passes the identity and location of source statements to the compiler EXEC and receives the location of. the compiled code in return. In so doing, it
handles diagnostics and updates the Program Structure Table.
Execution Monitor. The Execution Monitor controls program execution as determined by the established mode of operation. It passes control between statements or halts execution after specific
statements, as required. It utilizes the dynamic
loader of the operating system and envokes other
program modules when requested to do so.
Command Interpreter and Dispatche1'. The Command Interpreter analyzes control statements and
calls either the Compiler Controller or the conunand
system of the operating system depending upon
whether a transient statement or a command is being
processed.
The Program Structure Table is obviously of great
importance since it indicates the relationship of statements and the static properties of the program. Elements in the table are generated dynamically as source
language statements are entered and are composed
from the following quantities: *
1. A type indicator specifying the type of statement;
2. A list of structure pointers linking this statement
to preceding and succeeding statements and to
any function module** in which it might be contained;
3. A pointer to the compiled machl:ne code for the
Rtatement;
4. A locator, such as data set name or physical
location, of the source program on external storage; and
5. A statement identification, such as a line number,
used for referencing the statement and for making insertions, deletioIl::;, and changes to the program.
* The article by Lock contains a comprehensive description of
internal program structure in a programming environment such
as this.
**The term function module i!:l used to represent either a block
or internai proced1lre as found in Algol or PL/I.
Due to the nature of the incremental compilation process and the Program Structure Table, it iR not necessary that t.he incremental code for a given program reside in contiguous memory locations. In fact, only
rarely will this be the case. Although this is conceptually
different from the established practice of generating
object code, it poses no serious problem in the incremental mode of operation.
In general, the incremental compiler is composed of
the same basic components as the batch and conversational versions. Some differences, which tend to be related to the interrelationshw of statements, do exist
but are relatively minor. The" global" analysts of statements, for example, is severly crippled by the fact that
all statements in a source module may not be available
for analysis. The "global" optimization of statements is
in the same category but must be eliminated entirely. It
is very feasible, however, to include it as a special phase
in the batch mode or provide a mechanism to convert
from incremental to object code, including global
optimization, in the conversational mode.
The basic compiler processing cycle begins when it
is called at its source input entry. (Another entry could
conceivably exist which might be to convert incremental
code to object code.) The compHer EXEC obtains the
source text to be processed from the Language Controller and builds a Program Table consisting of t.he
text to be processed during the cycle; information Oil
additions, insertions, and delet.ions; location of the existing symbol table; and parameter data relating to
mode of compilation, listing options, BCD codes, etc.
The EXEC then invokes Phase 1 of the compiler which
performs a statement classification and syntax analysis
and builds the Program Reference File and Expression
Reference File from all of the statements specified ill
the Program Table. Pointers to t.he encoded statements
are then returned to the EXEC, where the encoded
statements are linked back to the Program Table. Phase
2 is then invoked to perform a global analysis, when
possible, and to assign storage for the statements indicated in the Program Table. This phase updates the
symbol table and merges the Program Reference File
and Expression Reference File to form the Complete
Program File maintaining the links to the Program
Table, as required. Phase 4 t is now called to translate
the encoded statements into object code forming the
Code File. Phase 5 which must generate either object
code or incremental code is considered below.
Operation of the compiler for each of the two basic
modes, batch and incremental, can now be described.
In a batch compilation, the source text available at entry
t Recognizing that no Phase 3 exists.
Batch, Conversational, and Incremental Compilers
consists of the complete program. The Program Table
passed to each component points to every statement in
the source program, so that in a single cycle, the complete compilation is produced. Other than the Executive (EXEC), the only phase which must be aware of
the batch parameter is Phase 5, which must build an
obj ect module instead of generating incremental code.
Again, the obj'ect module consists of a program module
(i.e., text and relocation data) and optionally, an Internal Symbol Dictionary. The text portion consists of
the object code produced and is entirely self-contaihed,
with the code generated for a statement linking directly
to the code for the next statement. The source text
available at entry to an incremental compilation may
represent anything from a single statement to a complete program. Normally, however, the source text
available represents only a portion of a program. The
Program Table; therefore, contains a group of statements to be added or deleted in the current program.
The Program Table is in the same form as for a batch
compilation and does not require different handling by
Phases 1, 2, and 4. In this mode, Phase 5 generates incremental code. Incremental code differs from an object
module in that the Program Module (i.e., the relocation information) must be dynamically generated
requiring some special processing by the Language
Controller and the system's' dynamic loader. The text
is organized on a statement-by-statement basis with
inter-statement linkage provided to allow the intervention by the Language Controller* at statement
boundaries:
.
As a result of the incremental process, four modes c~·
execution are possible: automatic, controlled, block
step, and step. In the automatic mode, statements are
executed by the Language Controller immediately after
they are processed by the compiler. In the coni;rolled
mode, statements are executed only when explicitly
requested by a RUN command, which may designate
a range of statements. In the block step and step modes,
an entire program (i.e., an external procedure) is available for execution, For the block step case; the Language
Controller pauses for user intervention after each block
(or possible subroutine) in the program. When the step
mode is specified, Language Controller suspends obfect
program execution after each statement.
Early efforts and special problem areas
The two specific references to incremental compilation, i.e .. by Lock7 and by Ryan,S are in a sense complementary. Lock tends to emphasize the structural
* That is, the Execution Monitor.
55
aspects whereas Ryan emphasizes the systems aspects,
even though different computers are involved.
The effort by Lock, and probably others, at the California Institute of Technology is part of an experimental time-shating proj ect for the IBM 7040 computer. The programmmg languages supported are
ALGOL, FORTRAN, and LISP with much of the
paper beIng devoted to the internal organization of
programs in an on-line programming environment.
The Conversational ComplIer System, reported by
Ryan and others, is an outgrowth of Lock's work and
runs under an SDS 940 time-sharing system.' ALGOL
and FORTRAN are also supported here with the paper
emphasizrn.g the command language, memory organization, and compiling techniques.
These projects have uncovered some interesting problems of which the most sigriifi cant , perhaps, is considered here. It involves changing a data declaration
when executable code exists which uses the variables
declared therein. In fact, the code may have been executed previously. Lock solved the problem by designing his pseudotmachine code so that all references to
identifiers are indirectly addressed through non-relocatable entries in the user's symbol table. This certainly
solves the problem but it partially nullifies one of the
basic 'Objectives ot incremental compilation; that is, to
gain the speed fact(Jr inherent in compiled code. A
hardware mapping of identifiers to physical locations is
feasible if relocation hardware and possibly a small
associative memory are available, although it remains
tD be seen whether dynamic address translatiDn can be
used in this particular manner. Finally, one might ask
the follDwing philDsDphical questiDn: "Is it unreaSDnable tD require a recDmpilatiDn fDllDWing a change tD a
data declaratiDn?" Clearly, the answer must be evaluated in light 'Of the 'Other benefits tD be gained through
incremental cDmpilatiDn.
CONCLeSIONS
The world of time-sharing and its potential for interactive computing at a general level has raised SDme
interesting tDpics.
First, it shDuld be recognized that althDugh batch
techniques are currently very efficient and well defined,
they were developed 'Of necessity. 'Vhen these techniques gained their acceptance, the hatch mDde was
the 'Only 'Operational prDcedure available fDr using the
cDmputer. The prDgramming cDmmunity shDuld alsD
recDgnize that prDgram develDpment in a batch envirDnment may nDt be the most natural or the 'Optimum
methDd.
SecDnd, it shDuld be recDgnized further that CDnver-
56
Spring Joint Computer Conference, 1969
sational techniques do not offer a complete solution in
that execution of parts of a program is usually not permitted. Clearly, language syntax errors can be detected
as they are being input and this is certainly a step in the
right direction. But ita programmer has to develop his
algorithm completely before any of it can be executed,
he might as well compile in the batch mode and rely on
execution-time debugging.
Some form of incremental compiling, therefore, seems
to be the only answer in sight to questions regarding the
development of algorithms in an interactive computing
environment. The ability to execute a program as it is
being compiled is certainly a natural way and very well
may be optimum from a development point of view. It
remains to be seen if the gains can justify the complexity of an incremental compiler.
REFERENCES
1JANLEE
The anatomy of a compiler
Reinhold Book Co New York 1967
2 B RANDELL L J RUSSEL
Algol 60 implementation
Academic Press N ew York 1964
3 W T COMFORT
A computing system design for USe?· service
Proc F J C C 1965
4 C T GIBSON
Time-sharing in the IBM /360: Model 67
Proc S J C C 1966
5 F J CORBATO V A VYSSOTSKY
Introduction and overview of the MULTICS system
Proc F J C C 1965
6 IBM System/360 Time Sharing System
FORTR./1N IV Program logic manual
IBM Corporation Y28-2019 Yorktown Heights N Y 1967
7 KLOCK
Structuring programs for multiprogram time-sharing
on-line applications
Proc F J C C 1965
8 J L RYAN R L CRANDALL
M C MEDWEDEFF
A conversational system for incremental compilation and
execution in a time-sharing environmeni
Proc F J C C 1966
9 B RANDALL C J KUCHNER
Dynamic storage allocation systems
C A C M Vol 11 No 5 May 1968
10 G RADIN H P ROGOWAY
Highlights of a new programming language
C A C M Vol 8 No 1 January 1965
11 K ElVERSON
A programming language
John Wiley and Sons Inc New York 1964
TRANQUIL: A language for an
array processing computer
by NORl\1A E. ABEL, PAUL P. BUDNIK, DAVID J. KUCK,
YOICHI l\iURAOKA, ROBERT S. NORTHCOTE,
and ROBERT B. WILHELl\,IS0N
University of Illinois at Urbana-Champaign
Urbana, Illinois
INTRODUCTION
Figure 1 also shows the essential registers and paths
in the CU and their relations to the PE's. Instructions
are decoded and control signals are sent to the PE
array from the control unit. Some instructions are
executed directly in the CU; e.g., the loading of CU
accumulator registers (CAR's) with program literals.
Operand addresses may be indexed once in the CU
and again separately in each PE. It is possible to load
the local data buffer (64 words of 64 bits each) and
CAR's from PE memory. Local data buffer registers
and CAR's may be loaded from each other. A broadcast instruction allows the contents of a CAR to be
transmitted simultaneously to all PE's. It is often
convenient to manipulate all PE mode bits or a number
from one PE in a CAR. For this purpose, the broadcast
path is bidirectional.
TRANQUIL is the algoritlunic language which will be
used to write programs for ILLIAC IV, a parallel
computer which has been described by Barnes et aZ. 1
ILLIAC IV is designed to be an array of 256 coupled
processing elements (PE's) arranged in four quadrants
in each of which the 64 PE's are driven by instructions
emanating from a single control unit (CU). Each of
the 256 PE's is to have 2048 words of 64 bit semiconductor memory with a 250 nanosecond cycle time
and an instruction set which includes floating point
arithmetic on both 64 bit and 32 bit operands with
options for rounding and nonnalization, 8 bit byte
operations, and a wide range of tests due to the use
of addressable registers and a full set of comparisons.
The PE's differ from conventional digital computers
in two main ways. Firstly, each is capable of communicating dat.a to its four neighboring PE's in the array
by means of routing instructions. Secondly, each PE
is able to set its own mode registers, thus effectively
enabling 01' disabling itself for the transmission of
data or the execution of instructions from its CU.
Figure 1 shows 64 PE's, each having three arithmetic
registers (A, B, and C) and one protected addressable
register (S). The registers, words, and paths in Figure 1
are all 64 bits wide, except the PE index registers (XR),
mode registers, and as noted. The mode register may
be regarded as one bit which may be used to block the
participation of its PE in any action. The routing
registers are shown connected to neighbors at distances
± 1 and ±R; similar end around connections are
provided at 1, 64, etc. Programs and data are stored in
PE memory. Instructions are fetched by the CU in
blocks of 8 words as required and are stored in a 64
word CU instruction buffer.
The four control units may be operated independently, as pairs, or all together. In the united configuration,
all 256 PE's are effectively driven by one CU and
routing proceeds across PE boundal ies. This allows
some flexibility in fitting problems to the array.
If ILLIAC IV, or any other parallel array computer,
is to be used effectively, it iH es.."ential that a.lI possible
parallelism be detected in those algorithms which are
to be executed by that computer. This is difficult, if
not impossible, if the algorithms are specified in
languages such as FORTRAN and ALGOL which
es..<:;entially express all computational processes in terms
of serial logic, as required for conventional computers.
Since it is also more convenient for the user to express
array type computation processes in terms of arrays
and parallel operations, rather than having to reduce the
the inherent parallelism to serial computational form,
the specification of a new language for array processor
computation is clearly necessary.
57
Spring Joint Computer Conference, 1969
58
r------ --- ------ -- ---- --- - - ---- --- --- -----------...,
I
I
INSTRUCTION AND DATA FETCHING
I
I
I
I
I
I
I
I
i
I
I INSTRUCTION
BUFFER
I
I
I
I
I
1111
:e
I
INSTR.
FETCH
REQUEST
I:'
I'"
It::
1
[I
1
64
WORDS
OAT<
I
10
1
ASSOCIATIVE
array operators, and revised loop specifications, including the addition of the set concept. Some of the
ideas embodied in TRANQUIL follow similar constructs in other languages, e.g., the index sets in ~lAD
CAP3 and the data structures and operators in APL.4
The syntax of the current version of the TRANQUIL
language is specified in Appendix B.
MEMORY
1
lID
IN
I;;;
I
Data structures
,CAR 0
I
I
INSTRUCTION
DECODER
I
I
:
1_-
C U IWEXING
CAR 3
----- -- -- -------------t----------------it ---1
CONTROL UNIT
,
P E CONTROL SiGNALS
DATA FETCHING
I
A
-r
64
57
2048
C
S
R
--!:...-
~
S
i+l
R
~
2!!..J
i+
i-1
2
9
~
-8
• ••
I MODE I
I :
8
C
I
•
MIR
MIl
PE
MEMORY
PE
PE
MEMORY
MEMORY
PEi
PE64
MIR
L I- :is-l
PE 1
Figure l-Il..LIAC IV quadrant configuration
into blocks for array storage
The TRANQUIL language has been designed to
achieve both simpler specifications of, and explicit
representation of the parallelism in, many algorithms,
thus simplifying the programmer's task and maximizing the efficiency of computation on a computer such
as ILLIAC IV. An overview of the software and
application programming effort for the ILLIAC IV
system has been given by Kuck. 2
The data structures which are recognized in TRANQuIL are simple variables, arrays and sets. All data
structUres, and quantities such as labels, switches and
procedures, must be declared in some block head as in
ALGOL. The data type attributes are INTEGER,
REAL, COMPLEX and BOOLEAN. Certain precision
attributes also may be specified.
A mapping function specification must be associated
with every declaration of an array. The judicious
choice of mapping functions is crucial to the efficient
use of ILLIAC IV. Arrays must be mapped so as to
optimize I/O transactions, minimize unfilled wasted
areas of memory, and keep most of the PE's busy
most of the time. In many array operations it is necessary to operate either on a whole row or a whole column
of an array. All the PE's would be kept busy in the
former case (one operand in each PE) but in the latter
case all operands would normally be in only 1 PE.
However, by specifying the skewed mapping function
which rotates the i
1st row across i PE's, columns
as well as rows of the array can be accessed simul~ane
ously. The more commonly used mapping functions
such as STRAIOHT, SKEWED, SKEWED PACKED,
and CHECKER are included in TRANQUIL. Array
bounds may be specified dynamically, as in ALGOL,
but all other attributes are nondynamic, for example:
+
REAL SKEWED ARRA Y A[I:M, I:N]
The 'J'RANQUIL language
An important consideration in designing a language
such as TRANQUIL is that the expression of parallelism in the language should be problem oriented
rather than machine oriented. This does not, and should
not, preclude programmer specification of data structure
mapping at run time, but once the storage allocation
has been made the programmer should have to think
only in terms of the data structures themselves.
Secondly, the means of specifying the parallelism
should be such that all potential parallelism can be
specified.
The structure of TRANQUIL is based on that of
ALGOL; in fact, many ALGOL constructs are used
with the addition of furt.her data declarations: standard
The user who wishes to specify his own mapping
function may make use of a PE memory assignment
statement. For example:
PEME1lfORY PB [1 :10, 1 :64];
PEM FOR (I, J) 81M ([1, 2, ... , 10] X [1, 2,
.. .',64]) DO
PB [I, J]
+-
B [I, MOD (64, I
+
J - 1)];
REAL ARRA Y (PB) B[l :10, 1 :64];
where 81M is discussed in a later section, establishes
virtual space of size 10 X 64 in PE memory, and then
TRANQllL:
stores a 10 X 64 array B there in skewed form. Thus,
instead of making up the aforementioned subarrays
out of an array declaration, space reserved in PE
memory may be used. In the program, the programmer
refers to an element of memory space via the assigned
array name B and its subscripts, as usual. It should
be noted that storage mapping functions can not be
specified dynamically. Should remapping of data be
required, an explicit assignment statement may be
used; e.g., to change the data in an array B from skewed
to straight storage an assignment statement
Af-B
INCSET
JJ
ftfONOSET
II [27, 6], KK [75, 75]
GENSET
A [150,100]
PATSET
P(3) [0:20,0:20, -5:15, 10]
The monotonic set II is to have at most 6 one-dimensional elements the integer values of which are
1~,..
.1..L\.i
;'"
.L.l..l.
+1,.",
UJ..L'l.I
"0"-"""'"
U.LL5"'"
..L
r1
'>"71J.
l..L,~.
or arrays. All meaningful combinations of operands
and attributes are valid; e.g., if A and B are matrices
then AlB will mean A X B-1 if B has an inverse and
the dimensions are correct. The result of a relational
operator operating on two matrix operands is reduced
to a single logical value through use of the qualifiers
ANY and ALL, e.g.,
ANY A
<
B or ALL A
1). The declarations also
may specify bounds for the integer values of the components of the n-tuple set elements, in ways analagous
to the specification of array SUbscript bounds in ALGOL
and FORTRAN, and an upper bound for the number
of elements in the set. Some examples of set declarations
are
+'"
UV
59
'"Ph,..
..L J....1.V
+U.1..LJ.
1,. ..\..I\..I-\A..1..l..L.l.v.LLQ.l.V.LLUJ,.
",,,, .rl~ ....... nn"';"'T>n 1
pattern set P is to have at most 10 3-tuple elements
the first two components of which will lie in the range
[0,20] and the third components will be in [-5, 15].
Expressions
Expressions which can be formed in ALGOL can
in general, also be formed in TRAKQUIL. In addition
arithmetic, logical and relational operators, and
function designators may be used on arrays. The
meaning of an operator is determined by its corresponding operands, which may be simple variables
SET2 f- [1, 2, 3, 4, 5, 6, 7, 8]
SET3 f- [1, 2, ... , 8]
SET4 f- [-2, P, Q, 25]
SET5 f- [[10, 10], [9, 8],[ 8, 6]]
where SET2 and SET3 are equivalent definitions and
SET5 is a 2-dimensional pattern set. Replication
factors may be used in general sets. For example:
SET6 f- [1(3),4, 5(2)]
is equivalent to
SET6 f- [1, 1, 1, 4, .'5, .5]
A useful device for the generation of a set is the run -time
comparison of data values in parallel. For example,
if A and B are vectors stored across PE memory,
A = {-I, 3, 2, 10} and B = {2, -3, 1, 12} ,
then the operation
SET7 f- SET [I : A[1]
< B[1]]
where I takes on the values 1, 2, 3, and 4 simultaneously,
generates the set [1, 4], the order being defined as
monotonically increasing. These definitions are readily
extendible to multidimensional pattern sets which
are generally used for picking scattered values in an
array for simultaneous operation.
The set operators INTERSECT, UNION, and
COMPLEMENT (a binary operation equivalent to
the relative complement) may be used in TRANQUIL
and always result in the generation of a monotonic
set by reordering elements if necessary. The two additional set operators CONCAT and DELETE do
Spring Joint Computer Conference, 1969
60
not result in reordering of the elements. Some examples
of set operations are:
if
R
= [1, 2, 3,4, 5]
S = [2, 4, 6, 8, 10]
I,
where {} means one of the alternatives separated by
the scope is the statement S, n is an integer, L(i = 1,
... , n) are control variables, and IIi (i = 1, ... , n)
are i-dimensional set identifiers or literal set definitions.
The use of this statement is illustrated by the following
examples.
a. FOR (I, J) SEQ ([1, 2, ... , 10], [5, 10, ... , 50])
DO
T = [6, 4, 6, 5, 6, 7]
U = [100,40,0, 13]
A[I]
then
~
B[I
+ 1] + C[J]
is evaluated as
RUNION U is [0, 1,2, 3, 4,5, 13,40, 100]
A[I]
R CONCAT Sis [1, 2, 3, 4,5,2,4,6,8, 101
T
COMPLEMENT R is [6, 7]
T
bELETE R is [6, 6, 6, 7]
[1, 2] X [3,4] , [5, 6] is [[1,3,5], [1,4,6], [2,3,5],
[2,4, 6]]
where , has higher precedence t.han X.
C[5];
+ C[10];
B[II]
+
C[50]
b. FOR (I) SEQ ([2, 4, 6]) WHILE I
A[I]
~
< A[I]
DO
B[I] - A[I]
will continue looping until the Boolean expression is
FALSE or the index set has been exhausted. As in
ALGOL, no pass through the loop is made if the value
of the Boolean expression is FALSE after the index
variable is assigned the initial value of 2.
c. FOR (I, J) SEQ ([1, 2, 3,4], [5, 6]) DO
Control statements
Control statements in TRANQUIL are used to
designate sequential loops, simultaneous statement
execution, and the usual conditional and unconditional
transfers of control. Index sets play an integral part
in these control statements. They are used as a source
of values fO! iterative or loop control, and as a means
of simultaneously specifying a number of array elements. Their association with the enablement and
disablement of PE" b should be obvious.
Sequential contr()l: The SEQ statement
Sequential control refers to the existence of a loop
through which designated index variables take on the
values of a set or sets, one element at a time. It is
written in the following general form :
FOR (11, ... , 111 ) SEQ (Ill {X
~
+
Note that the comma between the two set definitions
denotes pairwise ordering for the control variables
values.
[1, 2, 3, 4] , [2, 4, 6, 8] is [[1, 2,] [2, 4], [3, 6], [4, 8]]
is [[1, 3], [1, 4], [2, 3], [2, 4]]
B[2]
A[2] ~ B[3]
A[10]
.. Fih~uy, it is possible to create sets with multidIIDertsional elements out of sets with scalar elements
through use of the pair (,) and cartesian product (X)
set operators, e.g.,
[1, 2] X [3,4]
~
I ,} ... {X I ,} lIn)
{ (empty) I W H I LE (Boolean expression)} DO S
B[I, J] (- A[I, J]
In this case the difference in size of the two defined
sets is resolved by considering only the pairs (1, 5)
and (2, 6), that is, the exhaustion of the smallest
index set signals the end of the loop. To indicate
otherwise an asterisk is placed after the set the exhaustion of whose elements is to be used as the stoppin h
condition. This means that any other sets which run
out of elements before completion will be repeatedly
used as many times as necessary. If the previous
statement is rewritten as
FOR (I, J) SEQ ([1, 2, 3, 4]*, [5,6]) DO
B[I, J]
~
A[I, J]
the result is
B[I, 5] (- A[I, 5];
TRANQUiL
B[2, 6]
~
A[2, 6];
B[3, 5]
~
A[3, 5];
B[4, 6]
~
A[4, 6];
d. FOR (I, J) 8EQ ([1, 2] X [6, 7, 8]) DO
A[I, J]
~
61
Some examples of the use of SLM are:
a. FOR (I, J) Slllf ([1, 2, 3]*, [4, 5]) DO
A[I, J]
~
B[J, I]
is evaluated as
B[J, I];
A[l, 6]
~
B[6, 1];
A[l, 7]
~
B[7, 1];
A[l, 8]
~
B[8, 1];
A[2, 6]
~
B[6, 2];
A[2, 7]
~
B[7, 2];
A[2, 8]
~
B[8, 2];
where the lengths of the two sets do not create the
problem that occurred with the pairwise operator.
This example also illustrates that the frequency of
element change is greatest for the rightmost set used.
Simultaneous control: The SIM Function and the
SIM Statement
The parallel structure of ILLIAC IV is' utilized in
TRANQUIL by the specification of simultaneous
control functions and statements. The general form of
the 81M function is:
81M BEGIN (assignment statement); ... ; (assignment statement) END where the enclosed assignment statements are executed simultaneously, i.e.,
the data used by anyone of them are the data available
before the 81.Af function was encountered.
The general form of the 81jt/ statement for simultaneous control is:
FOR (II, ... , La) 81M (Ill f X I ,l ... t X I ,}
lIn) DO S
., .
.
81M BEGIN A[l, 4]
~
B[4, 1];
A[2, 5]
~
B[5, 2];
A[3, 4]
~
B[4, 3]
END
b. FOR (I, J) 81M (II, X JJ) DO
BEGIN
C[I, J]
~
0;
FOR (K) 8EQ (KK) DO
C[I, J]
~.
C[I, J]
+
A[I, K] X B[K, Jl
END
is a general routine for the multiplication of two com
patible matrices A and B if the index sets II and JJ
specify the rows of A and the columns of B, respectively
It should be noted that when a set is used in a
sequential or simultaneous control statement, it
cannot be altered within the scope of that statement.
Nested 8EQ and SIM statements
The 8EQ and 81M control statements described
above may be nested. The effect of nesting is clear
except when a 81M statement occurs within the
scope of another 81ll! statement, in which case statements inside the scope of both are executed under the
control of sets which are related by the cross product
operator, for example:
FOR (I, J) 81M (II, JJ) DO
where m, n are integers, Ii (i = 1, ... , n) are control
variables, IL (i = 1, ... , m) are k-dimensional sets
(0 < k :::; 7), n equals the total number of dimensions
of all IIi, and S is a statement. For this statement each
substatement Si of S is executed with the data available
before it is reached, i.e., just as if a 81M function was
placed around each S,. In this regard it is important to
note that simultaneous control is not loop control, but
designates that each Si is to be executed in parallel and
thus the order of the associated sets is not important.
BEGIN FOR (K) 81M (KK) DO
BEGIN
Area A
END;
END
62
Spring Joint Computer Conference, 1969
where the control statement in effect in area A is, in
effect,
The TRANQUIL compiler and its implementation
Introduction
FOR (I; J; K) 81M (II; JJ X KK) DO
If clauses
General forms:
a. IFSET (indexed Boolean expression) THEN
b. IF {FOR (II, ... , In) SIM (III {XL} ... {x I,}
IIm)\ (empty)} {ANY\ALL\ (empty)} (Boolean
expression) THEN
If clauses may be used in arithmetic, Boolean, set
and designational expressions. The Boolean expression
in form (a) must involve a control variable under
SIM control and thus not have a single logical value.
This is meaningful in arithmetic and Boolean expressions
of assignment statements having left parts which use
the same control variable, and also in conditional
statements where the control variable is used in the
left part of some associated assignment statement,
An example of this use is:
FOR (I) SIM ([1, 2, ... , 100]) DO
T[I] ~ IFSET A[I]
ELSE B[I]
<
B[I] THEN A[I]
Array blocking and storage allocation
is equivalent to
FOR (I) SLY ([1, 2, ... , 100]) DO
IFSET A[I]
<
~
B[I] THEN T[I]
ELSE T[I]
~
A[I]
B[I]
In either form T[I] ~ A[I] for all values of I for which
the value of the Boolean expression is T RUE and
T[I] ~ B[I] otherwise.
The form (b) results in only a single Boolean value
based on the ANY or ALL modifier, and the scope of
the SIM control (if explicitly present) extends over the
Boolean expression only. If the vector A of length 2 has
elements 5 and 10, the if clause test
IF FOR (I) SIM ([1, 2]) ANY A[I]
<
7
has the value true since A[l] < 7. The same result is
achieved by use of the if clause
IF ANY A
<7
The syntax of TRANQUIL has been specified in a
form which is accepted by the syntax preprocessor of
the Translator Writing System (TWS)5,6,7,8 being
built at the University of Illinois. The preprocessor
automatically generates the parsing algorithm for the
compiler. In pass 1 of the compiler the recognition of
source code constructs invokes calls, via the action
numbers embedded in the syntax definition, to semantic
actions. These actions build descriptor tables containing' in part, information about declaration types,
attributes, and block structure, and transform the
source code into an intermediate language form which
is composed of operators and operands, the latter
being references to the descriptor tables.
Pass 2 is the main body of the compiler. The intermediate language stream is read and operators call
pass 2 semantic actions (on the basis of their context)
for generation of assembly language instructions using
associated operands. A number of other important
considerations arise, among which are the storage of
arrays and sets, and the efficient allocation and use of
CU registers. These problems and some solutions are
discussed in the following sections.
The compiler partitions all arrays into 2-dimensional
blocks the maximum size of which is 64q X 64q words
(q = 1, ,2, or 4 according as 1, 2 or 4 quadrants of 64
PE's are being used) since ILLIAC IV may be regarded as an array with 2048 rows (number of words
in a PE) X 64q columns (number of PE's). For the
purposes of this section it will be assumed that q = 1.
The sizes of the blocks obtained by the array partitioning then fall into 4 categories:
a. 64 X 64
b. m X 64
c. 64 X n
d. mXn
m, Il
< 64
which are called SQUARE, HBLOCK, VBLOCK and
SBLOCK, respectively. Small blocks belonging to the
same array are packed together to form a larger block,
details of which are given' by Muraoka.9 Figure 2
illustrates the partitioning of a 3-dimensional array
into 12 blocks and Figure 3 illustrates how the smaller
subblocks are packed together to form larger blocks.
The partitioning of an array into blocks is independent
of the mapping function; i.e., for a SKEWED array
skewing is done after partitioning.
TRAL~QUIL
~~------15------~~
64
63
"~t----48 ....
- -~."I
11
PACKING VBLOCKs
75
0
64
1
T1-------
64
2
11
3
33
A[1. *. *]
30
11
6
1
I
I
2
I
50
:4
5
I
HBLOCKs
PACKING
SBLOCKs
10
I
I
I
PACKING
Figure 3-Block packing for array A[l :3, 1 :75, 1 :75]
_______ ..JI
A[2. 50.30]
6
7
v
9
10
11
Q
A[3. *. *]
Figure 2-The partitioning of array A[l :3, 1 :75, 1 :75]
into blocks for array storage
All array operations and data transfers between
ILLIAC IV disk and PE memory are done in terms of
these blocks. A block of size m X n may be placed in
any m adjacent words (rows) stored in n adjacent PE's
in PE memory. Blocking facilitates the use of arrays
which are larger than the PE memory. All data are
normally stored on the 109 bit ILLIAC IV disk and
blocks are only brought into PE memory (at a transfer
rate of .5 X 109 bits/second) as required. The TRANQUIL compiler automatically generates block transfer
I/O requests, which are handled by the operating
system. Thus, it is possible to write a TRANQUIL
program which includes no explicit data transfers.
ThA AffAt>t.l'tra:
Q.rlrll"AQQ nf
Q.n'tr Q.1"rQ.V A1ATnAnt.
u .............
_ ............J
........... _ ..............",..... "' let
..- nht.Q.lnM
. - .......-
_ .....a. _ _
---~
~"'-J
--~~~
by computing the block number, which determines an
absolute base address (the address of the upper leftmost element of the block if the block is in memory)
and a relative address within that block. The block
number for an element A[h, i2, . , " in-l, in] of an
array declared
(( ... ((it - (l)M2 + (i2 - t,»Ma
· + . . . (i,,_2
- (,.-2» M,._~
+
i,,_~) M:
+
i~ ,
Spring Joint Computer Conference, 1969
64
where
lUi =
Ui -
~J i = (l\L
fi
+ 1,
+ 63)div 64, i~
= (h - fk)div 64 .
If the array is SKEVVED the relative PE number and
relative PE address of the element in the specified block
are given hy
and
respectively. After skewing of the blocks in Figure 2,
the element A[2, 50,30] is specified by the block number,
and PE number and PE address relative to the base
address of the block, which have values 4, 14 and 49,
respectively. In most cases some or all of the elements
in a row or colunm are used simwtaneously. In the
case of column operation, for example, each PE can
simultaneously compute the relative address (index
value) which it will require.
In allocating memory space for a block a linked
space list, which keeps track only of the nunlber of
rows of memory which have been used, is utilized. If
a block of size m X 64 is to be stored, the list is searched
to locate a space of m adjacent rows and the block is
stored there. In the case of a block of size m X n
(m, n < 64) 64 rows of PE memory may be allocated
and a sublist corresponding to this 64 X 64 block of
storage is established. The sublist consists of a Boolean
array in which each bit represents the use or otherwise of each 8 X 8 subblock of the associated 64 X 64
block of storage, thus allowing several small blocks to
be stored together in a larger unit.
The storage and use of sets
Associated with the introduction of sets in TRANQuIL is the task of finding storage schemes which
can be used efficiently. Sets can be used for loop control,
for enabling or disabling PE's, or for PE indexing.
The increment set can be used in all three ways and is
stored using two words per. set. One word contains the
a.~t element, the increment, and the lilY'it packed for
use by CAR instructions. The other word is used as a
bias value in the case where negative elements are, or
may be, in the set.
When an increment set is used for sequential control,
CU test and increment instructions operate on the
appropriate CAR register. When an increment set is
used for simultaneous control, it can be expanded at
run time into mode words or explicit numbers. Mode
words are 64-bit words used to store the elements of
a set by position number, where a 1 in the n-th bit
indicates tbat n is an element of the set. These words
are most frequently used in PE mode registers to
enable and disable PE's. Mode words can be generated
from an increment set by using a memory row that
contains the PE numbers in ascending and descending
order and regular mode patterns similar to the 4 PE
system shown in Figure 4. In the figure the mode
pattern was formed by considering the bo bits to be
all ones, the b1 bits to be alternating zeros and ones,
the ~ bits to be two zeros alternating with a one, and
finally the b s bits to be three zeros alternating with a
one. In the general 64 PE case, the word in the i-th
PEis
I :\Iode pattern
63-il
where the 32-bit mode pattern results by considering
the bo bits to be all ones: i.e., all PE's on when in use,
the b1 bits having the pattern 0101. .. , the ~ bits
001001. .. , and the b i bits O,JO,:1 where 0" stands for
i zeros.
N ow consider the example of expanding the increment set JJ of Appendix A into mode words and
explicit numbers. The set JJ is used simultaneously
in forming the comparison set KK by a Boolean test
on the skewed arrays A and B. For a given I every
other element of A, as signified by JJ, is moved to the
A register in the PE's, using the base address of A
that has been brought to the CU data buffer as indicated in Figure 5. Every other element corresponds
to the hI bit mode pattern, this pattern appearing in
the PE mode positions of Figure 5 which is based on
Figure 1. The case for I = 2 is shown. Every other
element of the I -th column of B is moved to the B
register. In this case every other ascending PE number
is used in the PE index registers, XR, with appropriate
routing to account for the skewed storage. For I = 2
Figure 1-:\'!ode patterns and explicit v3.1ues for increment sets
TRANQUIL
CU storage allocation and use
LOCAL DATA aUFFER
100000001001010000010011
II MOOE WORD
BASE ADDRESS OF A
BASE ADDRESS OF a
ACAR REGISTER
I
J J IN MODE FORM
R
E
G
I
/
I
/
1
0
/
1
7
1
I
0
'x
I
1
'x
I0
A
A[ 2. 63]
A[2.
1]
A[2. 61]
~ a
a[63. 2]
a[ 1. 2]
a[61. 2]
61
A[0, 63]
5
T
S
XR
M
E
M
o
R
y
I
A[ O.
0]
A[ 1. 63]
A[ 2.62]
.. .
PEO
1
I
I
1]
A[ I, 0]
A[ O. 2]
1 1
A[O. 3]
A[ 1. 1]
A[l. 2]
A[ 1,62]
A[2.63]
A[2.
0]
A[2. 1]
A[ 2. 61]
63
A[ 0,
.. .
65
...
...
PE3
PEz
Figure 5-PE and CU status for I
.. .
=
2 in the example problem
in Figure 5, an end around route of two is necessary.
Every other element of a column is fetched to the B
register again by the use of JJ in mode form.
The sets II and KK in Appendix A are examples of
monotonic sets and are stored in mode form. For
looping on II the CD does leading ones detection on
the II mode pattern, illustrated in Figure 5, to determine the explicit set elements used in the .CAR as
CD indexes for array A, and KK is used in mode form
in the PE mode registers under simultaneous control.
Monotonic sets can also be stored as explicit numbers
for index use. The general set is always stored in
explicit form, for obvious reasons, and pattern sets
are stored as mode words.
The actual management of mode and explicit storage
schemes involves the use of a permanent storage area
and a stack. All set defInitions are stored in the perrr...anent storage area except comparison sets. The stack
is used for storing current set values that are obtained
from the permanent area or generated by the user or
compiler. The stack is also used because program flow
is not known at compile time, in general, due to data
based branches, and thus changes in these sets are
unpredictable. In PE memory the storage of either
the mode or explicit set representation begins on an
8 word boundary to make best use of the 8 word CD
fetch capabilities. Further details of the handling of
sets are given by Wilhelmson. 10
The allocation and use of CU registers is a very
important ILLIAC IV problem since CU instructions
which caIUlot be overlapped with PE instructions
leave all PE's idle. The allocation of CU registers for
needs known at compile time is accomplished by
calling one of a group of procedures that have an
underlying allocation priority system and that use
compile-time pointers to and from important tables
and storage locations. The local data buffer is divided
into two parts: the lower part for use as determined at
compile time and the upper part for dynamic use at
run time. The lower part is further divided into three
parts. The first is one word used for bit storage and
later testing. A list of free bits is kept, bits being
assigned on a space available basis. The second part
is 16 words in length, where the use of this space is
kept to low priority requests unless space is needed
for high priority requests. Priorities range from 0 to 3
and are assigned by the compiler writer, these assignments being based on intuition and experience. The
third part has n words (0 ~ n ~ -17), where the optimal
value of n is yet to be determined. The space is used as
much as possible for high priority requests. The reason
for this device is to try and keep low priority requests
in the lower area, since the lower area will be used to
store 8-word blocks transmitted to the CU. When the
local data buffer becomes full a word is freed, with
appropriate storage and pointer modification if necessary. Thus a user can let the procedures free words
when necessary unless he wishes to do so earlier.
Three of the CAR registers are allocated using the
same priorities as in the local data buffer. The fourth
is a free register which may be used in a variety of
ways.
Another CD problem is connected with its particular data composition, and results from transfers.
For example, at the begininng of a loop data in the CD
has a certain composition. This composition should
be reinstated each .time through the loop. This is
made possible by remembering the composition of
the CD data at the beginning of the loop.
For backward transfers code to set up the CU
properly is placed at the jump point while for forward
transfer code is placed at the location transferred to.
The priority scheme may appear to add to the problem
of moving words in and out of CU memory at transfer points. This scheme has been developed since
8-word block stores to PE memory are not allowed;
only one word at a time can be stored in PE memory
by the CU.
66
Spring Joint Computer Conference, 1969
Assignment statements
The use of sets, the notion of S1j}/, the number of
different types of arithmetic and storage schemes,
combined with the need to compile efficient code for a
parallel machine necessitate a substantial analysis of
each assignment statement. We now consider this
analysis as it is carried out in pass 2 of the compiler.
The analysis is effected in several passes over the
postfix intermediate language. Consider the last
assignment statement in the example in Appendix A:
A[I, K] +- A[I
+
1, K]
+
B[I, K
+
1] ;
Before we even begin to generate code a decision must
he made as to which index is to be proces..'3ed simultaneously (i.e., across the PE's) and which is to be
done sequentially. The first pass over the intermediate
language determines this and also copies the intermediate language into a table to be used for future
passes. When a set linked * identifier is entered in the
table, additional information provided by the set
definition or declaration is also entered. In the case of
I, which is linked via 81M control to II, the set is
known exactly and precise information from the set
definition is entered in the table. For K the compiler
makes an estimate of the size and density of the set
based on the upper bounds given in the declaration
ofKK.
In general, when operations are performed on pairs
of subscripts or pairs of subscripted arrays, infor-:
mation about the interaction between these subscripts
must be generated. For example, in the case of the
subscript expression I + 1 in the example above, the
addition of 1 in no way alters the size, density, or
type of the set. Thus, the information provided for I
will be recopied with the + operand.
After the subscript expression has been processed,
a check is made to see how well the type of set resulting
from the index expression will work with the particular
dimension of the array involved. In the example there
are oniy two-dimensional skewed arrays in which either
columns or rows can be easily accessed in parallel.
If one of the arrays were straight, then at. this point.
it would be discovered that no set will work weI] for
the column index, because each column is stored in a
single PE. This information plus information about
the set density, set size, and the array size are all
combined to compute a probable efficiency; i.e., the
number of PE's that will probably be enabled if this
index were varied simultaneously. Of course, it is
* We say that I
SIlr! (II) DO.
is set linked to II in a stat.ement like FOR (I)
easy to think up cases in which the estimate will be
totally wrong, but in most practical cases encountered,
the estimate is reasonable. A table of these probable
efficiencies is generated for each set. If the set appears
in different subscripts, then on the second occurrence
the new estimate is set to the minimum of the previous
and present estimates.
When the end of the assignment statement is reached,
the table of probable efficiencies is sorted and the result
of this determines the order in which the indexes will
vary. In the example K will be the index chosen to
vary across the PE's because the set II is known to be
small (6 elements) and the declaration of KK holds
the probability of it being fairly large. Now an outer
loop must be compiled to generate sequentially the
elements of II. Finally, the remainder of the statement
is compiled. The effect of the code that is compiled
for the example assignment statement foHows.
One local data buffer location is set aside as an index
to the mode words of KK. Four more locations are
set aside for the base addresses of the subblocks of
the arrays A and B. The first mode word for KK iR
loaded and the leading ones detector is used to set the
first value of K. This value, plus the base address of A,
plus 1, plus the index set 0, 1, 2, ... , 63 in the PE
index registers is used to access the first colwnn of A.
In a similar manner the address for the first row of B
is fetched, loaded into RGR and a route left one PE
is performed The addition is executed and the first
mode word for KK is used to store the result in A.
N ow the same process is repeated for the next sub block
of A, except that the mode pattern for KK must be
ended with a word having Ill's followed by O's,
because the second sub block of A is only 11 words wide.
Additional complications, such as pairwise 81M
control specification, small sub arrays , and 81M blocks
add to the complexity, but not to the substance, of
the algorIthm outlined above.
It is clearly impossible to efficiently compile a single
short assignment statement for ILLIAC IV, but it is
conceivable that a large number of simple assignment
statements could be integrated into a fairly efficient
ILLIAC IV program. Incorporating such a feature
into a compiler presents two basic problems. The first
is an algoritlun for efficiently integrating a large number
of interrelated assignment statements. Ordinarily the
simple assignment statements will be scattered throughout the program. Also, many of the sequential calculations that are prime targets for an integration scheme
are likely to be embedded as sUbexpressions in assignment statements containing 81M controlled variables.
Filtering out and gathering together these candidates
TRANQUIL
Figure 6-The tree structure for a set of interrelated
arithmetic statements
for the integration scheme constitutes the second
problem.
Figure 6 is a tree structure for the set of assignment
statements:
A+-B+CXD
E+-L+B-C
F+-G+HXI
K+-A+E+F
No node on this tree can be calculated until all
nodes on subbranches have been calculated. The
method of computing such a tree on ILLIAC IV
involves first mapping assignment statements into
PE's, in a more or less arbitrary manner. The assignment statements are restricted to a small num ber of
operations like addition, subtraction, multiplication
and division. ILLIAC IV can only perform one of
these operations at a time. A count of the number of
PE's that can take advantage of each of these operations is made and that operation which will be executed by the most PE's is the one that code is compiled
for. Then the PE counts for all operations are revised
and the process continues until all calculations have
been perfonned. A similar algorithm is used to do routing to bring the results computed in one PE to the
PE's where they are needed. This algorithm is invoked
67
whenever the number of PE's eligible for any operation
falls below a certain limit.
The problem of gathering together assignment
statements for processing by this method is many
faceted. What is desired is a rearrangement of the
program where simple assignment statements, simple
subexpressions, and simple expressions generated by
the compiler, like address calculation, have been
brought together at several collection points. To
rearrange code in this manner requires an extensive
analysis of the· overall program to determine what
subexpressions and statements can be moved, and
how far.
This analysis is carried out at the intermediate
language level. The collection points are determined
to be at the beginning of blocks, subexpressions are
moved as physically high up in the code as possible,
except that they are not moved past a block head
unless they can be moved to the head of an outer
block. The method produces a number of bonuses.
Calculations inside loops tend to be moved outside
when logically permissible. Thus, it is profitable to
move nonsimple subexpressions also. Further, duplicate
subexpressions can easily be eliminated because they
tend to gather at the same point. Finally, for each
block a record is made of what variables are nondynamic within that block. Thus, in pass 2, any
expressions generated using these variables can be
added to the collection of subexpressions at the beginning of the appropriate block. At the head of this
block, a transfer tQ the end of the block is compiled,
and when all code in the body of the block has been
generated, the complete collection of assignment
statements is compiled followed by a transfer back to
the beginning of the block. More details of this type
of analysis are given by Budnik.l1
SUMMARY
Designing and implementing a language and its compiler for ILLIAC IV presents a number of problems
not encountered with procedure oriented languages
for sequential machines. In the design of the language
these problems have been met, primarily through the
use of sets as indexes and the introduction of language
elements for explicit denotation of simultaneous operations. Experience has shown that the resulting notation is as easy to learn as that of conventional
languages and in most instances it is more concise.
The task of efficiently compiling a language such as
TRANQUIL for the ILLIAC IV is more difficult than
compiling for conventional machines, simply because
the standard compiling techniques are inadequate,
thus requiring new compilation algorithms to be
68
Spring Joint Computer Conference, 1969
invented. These techniques will undoubtedly be
refined as further experience is gained with the use of
ILLIAC IV and parallel languages. However, the
completion of the major paris of the TRANQUIL
compiler has already demonstrated that reasonably
efficient object code can be generated for a large class
of array-type problems which have been programmed
in TRANQUIL.
Several features of TRANQUIL have been omitted
from this paper, notably input/output statements and
procedures. Execution time input/output will be
from/to the ILLIAC IV disk (secondary storage)
in blocks of data. Most of these data transfers will be
implicitly specified in TRANQUIL programs. However,
some explicit specification of unformatted data transfers win be provided. The provision of additional
software to iacilitate format specified transfer of data
between external peripherals (tertiary storage) and
the ILLIAC IV disk is planned. The specification of
procedure declarations, and their use in a parallel
environment, is under investig(8.tion. Additional features
being considered for later incorporation into the TRANQUIL compiler include overlayable code segments,
quadrant configuration independent code, and more
specialized data structures and mapping functions.
Although aspects of the language and its compiler
are still being developed, it has been demon8trated
that TRANQUIL is a highly satisfactory and useful
complement to the ILLIAC IV hardware system design.
ACKNOWLEDGMEKTS
The research reported in this paper was supported in
part by th.e Depa...~ment of Computer Science; University of Illinois at Urbana-Champaign, and in part by
the Advanced Research Projects Agency as administered
by the Rome Air Development Center, under Contract
No. USAF 30(602)4144.
APPENDIX A: A SANIPLE TRANQUIL PROGRAM
BEGIN
REAL SKEWED ARRAY A, B[I:75, 1:75];
INCSET JJ;
MONOSET lI(l) [27, 6], KK(l) [75, 75];
INTEGER 1,.1, K;
II +- [2, 10, 13, 15, 21, 24];
.JJ +- [2, 4, ... , 74];
FOR (I) SEQ (II) DO
BEGIN FOR (.1) SIM (.JJ) DO
KK +- SET (J: A[I, J] < BfJ, I));
REFERENCES
1 G BARNES R BROWN M KATO D KUCK
D SLOTNICK R STOKES
'Phe ILLIAC IV computer
IEEE Transactions on computers Vol C-17 746-757 August
1968
2 D J KUCK
ILLIAC IV software and applications programming
IEEE Transactions on computers Vol C-17 August 1968
758-770
.
3 M B WELLS
Aspects of language design for combinatorial computing
IEEE Transactions on computers Vol EC-13 431-438
August 1964
4 K E IVERSON
A. programming language
John Wiley New York 1962
5 R S NORTHCOTE
The structure and use of a compiler-compiler system
Proc 3rd Australian computer conference 1966
6 F L DEREMER
On the generation of parsers for BNF grarn·mars:
an algorithm
Proc S J C C 1969
7 A J BEALS
The generation of a deterministic parsing algorithm
Report No 304 Dept of Computer Science
University of Illinois at Urbana 1969
8 H R G TROUT
.1 BNF like language for the description of
syntax directed compilers
Report No 300 Dept of Computer Science
University of Illinois at. Urbana 1969
9 Y MURAO}(A
Storage allocation algorithms in the TRANQUIL compiler
Report No 297 Dept of Computer Science
University of Illinois at Urbana 1969
10 R B WILHELMSON
Control statement syntax and semantics of a language jor
parallel processors
Report No 298 Department of Computer Science
University of Illinois at Urbana 1969
11 P P BUDNIK
TRANQUIL arithmetic
Report No 296 Dept of Computer Science
University of Illinois at Urbana 1969
TRANQUIL
FOR (K) SL7tl (KK) DO
A[I, K]
~
A[I
+ 1, K] + B[I, K + 1]
END;
FOR (I, K) SIM (II X KK) DO
A[I, K] ~ A[I + 1, K]
ElfD
+ B[I, K + 1]
APPENDIX B: A SPECIFICATION OF THE SYNTAX OF TRANQUIL
A brief description of the syntax metalanguage is given in APPENDIX C.
B.1
Program
(PROGRA?\I) :: = (BLOCK)
(BLOCK) :: = BEGIN list [ (DECLARATION) ffo;]
list (STATE:\lENT) separator ffo ;
[ffo;)
END;
(STATEl\IENT) :: = (NONE?\IPTY STATElVIENT) ! < );
(NONE1UPTY STATEl\IE~T) :: = [( * I) : ]*
[(CONTROL STATEl\1ENT) I
GO TO (DESIGNATIONAL EXPRESSION) I
BEGIN (NONE:\JPTY STATEl\lENT) [ffo; (STATE~VrENT )]* END I
(BLOCK) I,
(IF CLAUSE) (STATEMENT) [ELSE (STATE2'1ENT )]& I
(ASSIGN1'1ENT STATEl\1ENT )];
B.2
Declarations
(DECLARATION) ::= (VARIABLE DECLARATION) I
(ARRAY DECLARATION) I
(PEl\I RESERVE DECLARATION) I
(PE::\I ASSIGN:\fENT DECLARATION)
(SET DECLARATION) I
(SWITCH DECLARATION) I
(LABEL DECLARATION);
I
B.2.1 Variable Declarations
(VARIABLE DECLARATION) ::= (ATTRIBUTE)
[COJIPLEX]& list (*1)
separator, ;
(ATTRIBUTE) :: = BOOLEAN I REAL I REALS I REALD I INTEGER
Il'{TEGERS
I IA"'TEGERL I BYTE8 I BYTE16 ;
I
B.2.2 Array Declarations
(ARRAY DECLARATION) :: = [(ATTRIBUTE )]& [(l\lAPPI~G FUNCTION )]&
ARRAY (ARRAY LIST) I [(ATTRIBUTE )]& ARRAY
( (PEl\ r AREA) ) (ARRAY LIST);
(:\fAPPING FUNCTION) :: = STRAIGHT I SKEW/ED I SKElVED PACKED I CHECKEH:
(ARRAY LIST) :: = list [list (*1) separator, (BOUND LIST)]
separator, ;
(BOUND LIST) :: = ffo[[list [[ * I ** I ffo I ffo ffo ]&
(ARITHl\IETIC EXPRESSION) :
separator,
I list [( * I ** I $ I $
$
(ARITH~VrETIC
]&
(ARITHl\IETIC EXPRESSION)] separator,] ffo 1;
(PEl''! AREA) :: = (*1);
EXPRERRION)1
69
70
Spring Joint Computer Conference, 1969
B .2.3 P EM Reserve Declarations
(PEM RESERVE DECLARATION) :: = PEAMEMORY (PElVI AREA NAIVIE)
~ [(UNSIGNED INTEGER), (UNSIGNED INTEGER) ~ ];
(PE~1 AREA NA~,1E) :: = (*1);
(UNSIGN""ED INTEGER) :: = (* N);
B.2.4 P BM Assignment Declarations
(PEM ASSIGNMENT DECLARATION) :: =
PEJ.l1 [(PEM ASSIGNMENT CONSTRUCT)
BEGIlv list (PElVI ASSIGNl\lENT CONSTRUCT)
separator; END];
(PEl\1 ASSIGNl\;IENT CONSTRUCT) :: =
(PEM ASSIGNlVIENT STATElVIENT)
(SET ASSIGNMENT STATEl'lENT) I (PEl\l FOR STATEMENT);
(PEIVI ASSIGNlVIENT STATEl\tlENT) :: = (* I)
~ [[ (UNSIGNED INTEGER) (* I)],
[(UNSIGNED INTEGER) (* I)] ~] f - (* I)
~ [list (ARITH1\lETIC EXPRESSION) separator, ;i)$];
(PElV! FOR STATEMENT) :: =
FOR ( (SET VARIABLE LIST» 8I;.1{
(SET NAME LIST» DO
[(PEM ASSIGNlVIENT CONSTRUCT)
BEGIN list (PEIVI ASSIGNl\IENT CONSTRUCT)
separator; END];
I
I
I
I
I
B.2.5 Set Declarations
(SET DECLARATION) :: = [INCSET \ AMONOSET I GENSET \ PATSET1list
(SET SEG::\IENT) separator,;
(SET SEGl\tlENT) :: = list (* I) separator,
[( (* N »]& [~[list [(ARITH~'lETIC EXPRESSION)
[: (ARITHMETIC EXPRESSION) ]&]
separator, ~]]&;
B.2.6 Label and Switch Declarations
(LABEL DECLARATION) :: = LA.BEL list (*I) separator,;
(SWITCH DECLARATION) :: = SWITCH (*1) f - list
(DESIGNATIONAL EXPRESSION> separator,;
B.3.1 Control Statements
(CONTROL STATEl\tIENT) :: = FOR (SET VARIABLE LIST»
[SEQ I SI M] (SET N Ai\IE LIST» DO (STATEMENT) I
FOR (SET VARIABLE LIST» SEQ (SET NAl\iE LIST»
WHILE (BOOLEAN EXPRESSION) DO
(STATEMENT) \ (SIM BLOCK);
(SET VARIABLE LIST) :: = list (*1) separator,;
(SET NAlVIE LIST) :: = list [(*1) [~ *]&
I (SET DEFINITION TAIL)] separator [, I X];
(SIM BLOCK) :: = SIM BEGIN list (ASSIGN]\1ENT STATEMENT)
separator ~; [~ ;]& END;
B.3.2 Set Definitions
(SET DEFINITION TAIL) :: = ~ [(LIST SET) ~]
(CO~lPARISON SET);
(LIST SET) :: = (ELEMENT) [, (ELEl\lENT ), ... , (ELElVIENT)
, (ELE:\lENT)]* I ();
(ELElVIENT> :: = ~ [list (.A.R1TH~fETIC EXPRESSION) separatorj .~]
I
I
I
TRANQUIL
71
(ARITHMETIC EXPRESSION)
[( (ARITHMETIC EXPRESSION»]&;
(CO.l\1PARISON SET) :: = SET $ [lisi (*1) separator,:
(BOOLEAN EXPRESSION) $];
BA
DesignationaZ Expressions
(DESIGNATIONAL EXPRESSION) :: = (SII\1PLE DESIGNATIONAL EXPRESSION)
(IF CLAUSE) (SIMPLE DESIGNATIONAL EXPRESSION)
ELSE (DESIGNATIONAL EXPRESSION);
/QTl\tfPTTi'
\ .._a........ ~ .L.u.:..o
nTi'QT~l\.TArpTl\l\.T AT lJIXDDlJIQQTr\1\T \ •• _
.L.J~u~'-.X ... ,.n..J...J..\J..l'll.n...u.L:.j
.J.. .J..".L:.jIJIJ.J..\J.l..'11 / " -
IITYJ~'OTn1\.T" 'T'ITr\1I.T" T
~ \.LI.L:.jO~U.l.."t1""1.~~V.l.."t1""1..l.J
I
..." lJ II
r.1"V"-nTYr.'tSST"""T" \,
~Ar.n.~
~v
(SWITCH IDENTIFIER) $ [(ARITHMETIC EXPRESSION) $] I
(LABEL IDENTIFIER);
(SWITCH IDENTIFIER) :: = (*1);
(LABEL IDENTIFIER) :: = (*I);
IF Clauses
(IF CLAUSE) :: = IF [(CONTROL HEAD )]& [ANY I ALL]&
(BOOLEAN" EXPRESSION) THEN I
IFSET (BOOLEAN EXPRESSION) THEN;
(CONTROL HEAD) :: = FOR (SET VARIABLE LIST» SLl1 (SET NAlVIE LIST»;
B.6
A ssignment Statements
(ASSIGNl\1ENT STATEl\1ENT) :: =
(BOOLEAN ASSIGNl\IENT STATEMENT) I
(ARITHMETIC ASSIGNMENT STATEMENT)
(SET ASSIGN~IENT STATEMENT);
I
B.6.1 Boolean Assignment Statements
(BOOLEAN ASSIGNMENT STATEMENT) :: = list [(*I)~]
(BOOLEAN EXPRESSION);
(BOOLEAN EXPRESSION) :: = (SIMPLE BOOLEA.1~) I (IF CLAUSE)
(SIMPLE BOOLEAN) ELSE (SIl\1PLE BOOLEAN");
I SINIPLE BOOLEAN) :: = (BOOLEAN FACTOR) [[OR I I.ltlP I EQV]
(BOOLEAN FACTOR )]*;
(BOOLEAN FACTOR) :: = (BOOLEAN SECONDARY)
[AND (BOOLEAN SECONDARY)]*;
(BOOLEAN SECONDARY) :: = (BOOLEAN PRIMARY) I NOT (BOOLEAN PRIMARY);
(BOOLEAN PRIl\fARY) :: = TRUE I FALSE I (*1) I (RELATION) I
(BOOLEAN EXPRESSION»;
(RELATION) :: = (ARITHMETIC EXPRESSION) ELT (SET EXPRESSION) I
(ARITHl\1ETIC EXPRESSION) (RELATIONAL OPERATOR)
(ARITH.l\fETIC EXPRESSION) I (SET EXPRESSION)
[= \ EQL \ ~ I NEQ] (SET EXPRESSION);
(RELATIONAL OPERATOR) :: = L88 I LED I = I GED I nTR I VF]D I ~ ( I
$ ) I _( I ) I ~ I EQL;
,
r ·
I
-
-.r
I
I
-- - -.....
I
-- -
--
I
- - -
~
i
,,-
,
I
B.6.2 Arithmetic Assignment Statements
(ARITHMETIC ASSIGN.l\IENT STATEMENT) :: = list [(*1)
[ $ [(SUBSCRIPT LIST) $]]& ~]
(ARITHl\1ETIC EXPRESSION);
(ARITHl\1ETIC EXPRESSION) :: = (GLOBAL PRI:\1ARY) I (IF CLAUSE)
(ARITH BOOL EXPRESSION) ELSE (ARITH BOOL EXPRESSION)
(ARITH BOOL EXPRESSION);
(GLOBAL PRIMARY) :: = [FOR (SET VARIABLE LIST» SIM
(SET NAlWE LIST »]& [SUM \ PROD IGOR \ GAND I
.ilfAX \.ilfIN] (ARITHMETIC EXPRESSION)];
I
72
Spring Joint Computer Conference, 1969
(ARITH BOOL EXPRESSION) :: = (ARITH BOOL L\1PLICATION)
[EQU (ARITH BOOL Il\1PLICATION )]*;
(ARITH BOOL LVIPLICATION) :: = (ARITH BOOL FACTOR)
[[lVOR I H'EOR I WIAfP I WEQVl (ARITH BOOL FACTOR )}*;
(ARITH BOOL FACTOR) ::= (ARITH BOOL SECONDARY)
[WAND (ARITH BOOL SECONDARY)]*;
(ARITH BOOL SECONDARY) :: = (SIMPLE ARITHMETIC EXPRESSION)
[WNOT (SIMPLE ARITHMETIC EXPRESSION)]*;
(SIMPLE ARITHMETIC EXPRESSION) :: = [ + I - ]& (TERM)
[[ + I - ] (TERM)] *;
(TERM) :: = (FACTOR) [[ X I / I DIy] (FACTOR )]*j
(FACTOR) :: = (PRIMARY) [ # * (PRlMARY)]*;
(PRINIARY) :: = (*I) (1; [(SUBSCRIPT LIST) ~]]& I
({ARITHMETIC EXPRESSION»
(MODFUN)
(FUNCTION DESIGNATOR) «ARITHMETIC EXPRESSION» j
(SUBSCRIPT LIST) :: = list [(ARITHMETIC EXPRESSION) I
(SET EXPRESSION) I ()] separatur,;
(MODFUN) :: = MOD «ARITHMETIC EXPRESSION),
(ARITHMETIC EXPRESSION»;
(FUNCTION DESIGNATOR) :: = ABS \ SIGN I SQRT I TRANS I SIN I COS I
I
I
I
ARCTAN LN EXP
I
I ENTlER;
B.6.3 Set Assignment Statements
(SET ASSIGNMENT STATEMENT) :: = list [(*1) ~]
(SET EXPRESSION);
(SET EXPRESSION) :: = (SIMPLE SET) I (IF CLAUSE) (SIMPLE SET)
ELSE (SIMPLE SET);
(SIMPLE SET) :: = (SET PAIR) [(SET PAIR)}* I
REVERSE (SET PAIR);
(SET PAIR) :: = (SET UNION) [PAIR (SET UNION)]*;
(SET UNION) :: = (SET INTERSECTION) [[UNION I DELETE I SMD I
CONCAT] (SET INTERSECTION )]*;
(SET INTERSECTION) :: = (SET FACTOR) [INTERSECT (SET FACTOR )]*;
(SET FACTOR) :: = (SET OFFSET) [COMPLEMENT {SET OFFSET)]*;
(SET OFFSET) :: = (SET PRIMARY) I ({SET PRIMARY) [+ I -]
(ARITH1vlETIC EXPRESSION»);
(SET PRIMARY) :: = (SET IDENTIFIER) I «SET EXPRESSION» I
CSHIFT ({SET EXPRESSION), (ARITHMETIC EXPRESSION»
(SET DEFINITION TAIL);
(SET IDENTIFillR) :: = (*1);
APPENDIX C: A METALANGUAGE FOR SPECIFYING SYNTAX
The TRANQUIL syntax in Appendix B is specified in a form of BNF which is extended as follows: 8
1. Kleene star:
(A)* = ()
I (A) I (A)(A) I .. ,
where () represents the empty symbol
2. Brooker and Morris' question mark (here &):
(A) & = () I (A)
3, List Facilities
list (A) = (A) (A)*
list (A) separat07' (B) = (A) [ (B) (A)] *
I
TRANQUIL
73
4. Brackets
(T) :: = [(A) I (B) I (C)] (D)
is equivalent to
(T) :: = (R) (D)
(R) :: = (A) (B) (C)
5. Metacharacters:
A sharp (#) must precede each of the following characters when they belong to syntactic definitions:
I
# , [, ],
I
*, ;, (, ).
In the syntax (*1) is used to designate an identifier and (*N) is used to designate a number. Further, the special
words in the language are italicized.
SN AP - An experiment in natural
laHt;uage programmi~
by MICHAEL P. BARNETT
H. W. Wilson Company
New York, New York
and
WILLIAM M. RUHSAM
Radio Corporation of America
Cherry Hill. New Jersey
INTRODUCTION
Computers are being used to a rapidly increasing extent,
to manipulate and to generate materially, mechanically.
(1) Many applications simply require items of information to be selected from a file of fixed format, heavily
abbreviated records, and expanded into statements
that are self-explanatory, and used perhaps in individual communications or incorporated in computer
typeset compendia. At the other end of the spectrum
are the interrelated challenges of mechanical indexing. abstracting, and translation. The burgeoning
applications of computers to publishing, education,
library work and information services in most major
branches of science and scholarhsip are leading to a
host of text processing and generating problems that
span these limits of complexity.
Many of the programming problems of mechanical
text processing also arise in other kinds of symbol
man 1pulation, such as the compilation of computer
programs, and the simplification of mathematical
expressions. Several programming languages, such as
COMIT and SNOBOL have b,een developed over the
years for mechanical symbol manipUlation, and used
to process text. FORTRAN, supplemented by some
simple assembly language subroutines, has been applied
to non-numeric problems quite extensively. ALGOL
and COBOL also have been used this way. Several
features of PL/1 will facilitate its use in processing
text. A number of languages and processors have been
developed for special kinds of text processing problems,
such as mechanical editing.
SNAP is a procedural language for nonscientists to
use. A SNAP procedure consists of a sequence of statements that have the appearance of simple English
sentences. The primary rationale of SNAP is that
mechanical text processing requires a language that
many nonscientists will be willing to learn, and which
they will find easy to use. Since such people deal primarily with English sentences in their daily work, a programming language that is a stylized subset of English
should seem to them more "natural" than one that is
symbolic. This rationale is not negated by the fact
that nonscientists are using symbolic languages effectively. Many scientists once learned to write in assembly language, but the number of people programming scientific problems was greatly increased by
FORTRAN.
Several SNAP constructions are quite like COBOL.
SNAP is designed like BASIC, to enable a beginner
to get useful results after learning very little; and to
proceed by incremental learning efforts to deal with
problems of increasing complexity. In its primary
emphasis on string handling, however, SNAP is different; and in the details of the instruction set, and how
the basic instructions are expressed, and in the proposed
use of statements that invoke subroutines, to allow
multitudinous language extensions. SNAP has some
novel features.
A prototype processor for the basic SNAP language,
that is SNAP without the subroutine capability, was
implemented in a compatible subset of FORTRAN
IV and now runs on several models of computers.
75 ---------------------------------
76
Spring Joint Computer Conference, 1969
The language and the prototype processor are used
in a graduate course on Computing and Librarianship
at.Columbia University. An early account of the SNAP
proj ect presented the language in a tabular form.
(2) SNAP is used as a vehicle to develop basic programming concepts in·a recent college text. (3) The implementation of the prototype processor is being reported too. (4) A more advanced processor, that will
allow invoking statements and a range of definitional
capabilities, is under development.
PRINT "TESTING, TESTING". EXECUTE.
or a little more adventurously, by typing
CALL "STILL TESTING" THE MESSAGE.
PRINT THE MESSAGE. EXECUTE.
The computer can be instructed to print output that
is longer than the input, ready to be cut into two line
display labels for the Mesopotamian Merchants Mart
at the Roman Coliseum, by typing as follows:
Programming in MICROSNAP
SNAP statements deal primarily with strings and
quantities. A string can be given a name by a SNAP
statement such as
CALL "YOU CANNOT ERR OR l\fAKE A
BLOOMER \VITH THE \V ARES OF ANCIENT
SUMER" THE TAG.
This statement in a SNAP procedure makes THE
TAG connote YOU CANNOT ERR .. until another
statement that redefines THE TAG is executed. In
general, a CALL statement in SNAP (that is used to
give names, not to invoke subroutines) consists of (1)
the verb CALL, (2) an expression (for example a quotation) that specifies the string which is being given a
name, (3) the name, and (4) a period. The forms that
are allowed for the expression (2) are described in a
later section.
SNAP places almost no restrictions on the choice of
words that can be used as names. Extensive restrictions
on the choice of names would seriously restrict the ease
with which a "natural" programming language could
be learned and used) and one objective of the SNAP
syntax is to permit meta-words within names. How this
may be done is discussed later. For the moment, we
just prescribe that a name is a nonblank sequence of
letters, digits, spaces, hyphens and apostrophes. Leading and trailing spaces are ignored, so are redundant.
internal spaces (i.e., any space that follows a space).
An article (A, AN, THE) at the beginning of a name is
optional (and in fact, ignored, to good advantage-see
later).
A string can be printed by a SNAP statement that
consists of (1) the verb PRINT, (2) a quotation, or a
name that an earlier CALL statement gave to a string,
or any of the other forms of string expressions that. are
to be described in a later section and (3) a period. The
one word statement EXECUTE is used to end a procedure, and to make the processor start executing it, so
that the SNAP conventions which have been described
so far can be demonstrated by typing.
CALL "YOU CANNOT ERR OU 1-1AKE A
BLOOMEH WITH THE WARES OF ANCIENT
SUMER" THE TAG. PRINT "CHARIOTS OF
DISTINCTION". PRINT THE T}:LG. PRINT
"INLAID GAMING BOARDS FOR PORCH
AND PATIO." PRINT THE TAG. PRINT
"DRINKING MUGS FOR THE LONGEST
THIRST" PRINT THE TAG. EXECUTE.
The production of display labels that combine a
common slogan, or class identification with indivlidual
identifications is a very simple and versatile "plot
mechanism" for developing examples and exercises that
relate to the interests of students in different disciplines.
Others include
1. The production of sets of letters that consist of
different selections of form paragraphs.
2. The production of programs for several performances of the same play or opera or other
artistic work on different occasions, with perhaps
some variation of case.
a. The production of a handbill that lists the events
for an entire season in which a few different
works are repeated many times.
4. The production of messages in large letters made
of X's (GO DOG GO, keeps the burden of font
design to a minimum), panoramic vistas of
seagulls and palm trees on desert islands, processions of stylized animals, etc., printed along
the length of the output stationery.
More are given in reference 3. The diversjty of applications that can be handled with a minimal knowledge
of SNAP has just been stressed because is does seem
important to enable students of a nontechnical bent to
overcome their initial apprehension of the computer
by getting results before being overwhelmed by grammati-cal rules. Once this potential barrier is crossed,
most seem able to assimilate programming grammar
with ease. The kinds of examples cited here can, of
SNAP
course, be handled with very little grammatical knowledge in many other languages.
Some more verbs that deal with strings
Input statements: The contents of a card, (or its image
on magnetic tape, for off-line card input) is immitted
by a SNAP statement such as
READ A BIOGRAPHICAL RECORD.
that consists of (i) the verb READ, (ii) the name that
the user wishes to give to the string that is read, and
(iii) a period. The corresponding instructions that begin
with the verbs REQUEST and FETCH immit an
input record from the console on which the user signed
on (in jnstailations where SNAP is used on line), and
from all other input media respectively. In the latter
case, the device (and the block format for magnetjc
tape input) is specified by a statement that begins
with the word SELECT, and which remains in force
until another SELECT statement that pertains to
input is executed. The input commands are being
extended to interface with operating system commands,
to access files on backing storage conveniently. The
REQUEST command alerts the console worker to type
a record that is ended by pressing the line feed key;
the SNAP processor stores the string under the name
that is given in the command, and goes on to the next
statement jn sequence. There are further SNAP statements to instruct the processor to give certain characters a typographic control interpretation or to use them
literally, and to retain trailing spaces in an input record,
or to discard them. The latter provision is quite helpful
in processes that embed an input item of variable
length within a fixed text framework (e.g., a name in
a form letter). An input record that consists of several
items is deconcatenated by methods that are described
later. The name that the input string is given by an
input statement may have been used before, but does
not need to have been.
Output statements: These consist of a verb, slieh as
PRINT, followed by an expression that specifies the
string to be recorded. This expression is, most simply,
a quotation, or a name that was defined by an earlier
statement in the prdcedure. Other forms are described
later. The verb is PRINT, PUNCH, PERFORATE,
TYPE and WRITE for the line printer, card punch,
paper tape punch, console and all other media respectively. Instructions that begin with the word SELECT
are used to control output on other media in a way that
parallels their use for ihput. The SNAP conventions
include provisions for representing case shifts, special
characters and font changes in a more limited character
77
set; an appropriate code conversion table can be put
into the processor to record output on a device that
has an extended typographic capability. A line printer
with upper and lower case characters has been driven
this way; so has a Flexowriter; and output has been
recorded on a magnetic tape that then served as input
to the composition programs of the RCA Videocomp
electronic typesetting machine.
String synthesis and alteration statements: The CALL
statement in general has the form
CALL b a.
where b denotes a string expression (i.e., an expression
that displays or represents a string) and a denotes the
name that this string is given by the statement. CALL
statements are not recursive, that is the expression b
must not make direct or indirect use of the name a
(the APPEND statement mitigates this-see below).
The definition that a CALL statement provides moreover is dynamic, that is, if the interpretation of the
expression b changes after the CALL statement is
executed, then the interpretation of the name a automatically changes to correspond. The COpy statement,
of the form COpy b AND CALL IT a. however constructs a copy, in core, of the string that b represents,
and gives the name a to this copy. Subsequent changes
in the interpretation of b do not affect the interpretation
of a.
The APPEND statement has the form
APPEND b TO a.
It gives the name a to the result of concatenating the
string represented by b to the string known previously
as a.
The OVERWRITE statement has the forms
OVERWRITE b ON THE m-th AND (SUBSE-
-L, . . . . . . . . . . . . . .
{)TTV1\T'T"
p"RV0VnV1\T'T".\ 0ll A "R A 0'T"V"RQ {)H'
.... ,...a..,
~'-"..,L...I
.£...&. .............................. ~ ........ _
..
...L ....... 4'--'..&. ........ ..&. ............
......, .....
a.
Here m-th denotes an ordinal adjective of the kinds
such as 3-RD, and UMPTEEN-TH which are discussed
later. A single character can be overwritten by a
shorter form of the statement.
OVERWRITE b ON THE m-th CHARACTER
OFa.
The DELETE statement, which elides characters,
takes the forms
78
Spring Joint Computer Conference, 1969
DELETE THE (m-th, m-th THROUGH n-th,
m-th AND PRECEDENT, m-th AND
SUBSEQUENT CHARACTER(S) OF a.
The string name a in an APPEND, DELETE or
OVERWRITE statement must have been given to a
string by a COpy or an input statement previously
(and more recently than by any CALL instruction).
Expressions that purport to represent strings but which
are inconsistent or invalid are considered to represent
null strings.
Storage allocation: A SNAP procedure can be written
without consideration of the lengths of the strings that
are involved, subject to the total core storage capacity
of the computer. The prototype processor allows 16K
bytes in a 128 K byte RCA Spectra or IBM 360 computer, for strings and internal representations of proeedures that are co-resident.
Procedures are condensed appreciably in their internal representation (in "SNAPIC" code), so that for
many problems there is ample room for all the strings
involved, without recourse to paging tactics; and these
can be adopted, using backing storage, when need
occurs.
Strings that are defined by CALL statements are
represented internally by codes within the actual representations of the statements; but strings which are
immitted by input statements, or constructed by COPY,
APPEND) DELETE and OVERWRITE statements
are stored separately in a" string bank." When a COpy
or an input statement is executed, that assigns a string
to a particular name for the first time in the current
operation of a procedure, this string is stored sequentially in the unused portion of the string bank. When
the string that is known by a part.icu lar name is changed.,
the space that it occupies is used for the new string,
and chained to a disjoint portion of the string bank
if it is inadequate. Since sequentially stored material
can be processed more rapidly than disjoint material
in many circumstances, SNAP includes an instruction
of the form
RESERVE SPACE FOR n CHARACTERS IN a.
where n stands for a positive integer, and a for a string
name, that may have been used before, but need not
have been. This reserves a continuous portion of the
string bank, that is n characters long, for strings called
a. It does not preclude longer strings receiving this
name-they are simply chained. The statement may
be advantageous when the strings that are given the
name a vary in length during a procedure, and it is
possible to anticipate a value which this length is. un-
likely to exceed, or to impose a limit on this length.
Storage allocation thus is permitted to the user, but is
not imposed on him.
Instructions that deal with integers
A statement such as
SET I TO 7.
that consists of (1) the verb SET, (2) a mnemonic,
word or phrase that the user chooses for a particular
quantity, (3) the preposition TO, (4) an integer, and
(5) a period, has the dual effect of giving the status of
a quantity name to the word(s) or mnemonic that
appears between SET and TO; and assigning the value
of the integer (item (4)) to this name, until further
statements change it. More generally, the item (4)
may be either
(i) an integer
(ii) a quantity name that was introduced' by an
earlier SET statement,
(iii) a length expression such as THE LENGTH
OF b, where b stands for an expression that
represents a string (expressions for lengths of
lists are discussed later)
(iv) an arithmetic expression of the form
THE f OF
(v)
~
AND
~
where f denotes one of the words SUM, DIFFER~NCE, PRODUCT, QUOTIENT, REMAINDER, CEILING, GREATER, LESSER; el denotes an integer or a name that was
introduced by an earlier SET statement, and
so does ~. A name can be used. more than once
in a SET statement. An article (A, AN, THE)
is optional at the beginning of a quantity name
and it is ignored when it is included. Invalidity is infectious, that is a quantity defined in
terms of an tnvalid quantity is invalid.
a string expression that represents a string
which is a decimal integer, with perhaps re-.·
dundant leading zeroes, a sign, and leading
and trailing spaces.
Defining lists of strings and quantities
A list of strings can be defined by a statement such
as CALL "SUNDAY, MONDAY, TUESDAY,
WEDNESDAY, THURSDAY, FRIDAY, SATURDAY" THE DAY LIST. This permits subscripted
names, such as THE 1-ST DAY and THE 5-TH DAY
to be used for strings, in any of the ways that unsubscripted string names (e.g., THE TAG used e.arlier)
SNAP
can be used. A list element thus can be redefined individually, by CALL, COPY, APPEND, DELETE
and OVERWRITE statements. It can be recorded
by an output statement, and used in expressions that
define further strings. A quantity name that has been
defined in any of the ways that were described earlier
can be used as a symbolic ordinal, by adding -TH,
so that if N and UMPTEEN are quantity names, THE
N-TH DAY and THE UMPTEEM-TH DAY are
acceptable as subscripted string names.
In general, a CALL statement. of t.he form
CALL "Sl, S2, ...
Sk."
THE g LIST.
gives the status of a generic string name to the word
or phrase that is denoted by g, and permits expressions
of the form THE j-th g to be used as subscripted string
names where j-th denotes a numerical ordinal (e.g.,
I-ST, 2-ND, 73-RD) or a symbolic ordihal (e.g.,
N-TH.) A subscripted string name is interpreted as a
null string if the ordinal is invalid, or if its value is
inappropriate. A comma is forced in a list element by
a preceding asterisk, and individual elements are defined
to be null by adjacent delimit.ers (commas and/or
quote marks.)
A generic string name also can be introduced by
input statements of the form
(READ, REQUEST, FETCH) (A, AN, THE)
g LIST.
79
are adjacent for elements that are null. Trailing null
elements and their commas however are suppressed.
Trailing null elements also are ignored in statements
of the form
SET k TO THE LENGTH OF THE g LIST.
A further statement, however, of the form
SET k TO THE REGISTERED LENGTH
OF THE g LIST.
that includes trailing null elements in the Jist, as it
was defined most recently, will be provided for programmed storage control.
A list of numbers nl, n2, ... , nk can be defined by a
statement of the form
SET THE h LIST TO.nl, 112, ... , nk.
This allows expressions of the form THE j-th h
(where j-th denotes a numerical ordinal, or a symbolic
ordinal derived from an unsubscripted quantity name)
to be used as subscripted quantity names, in any of
the contexts allowed for unsubscripted quantity names,
except symbolic ordinals. RESERVE statements and
LENGTH expressions for lists of numbers parallel
those for list of strings.
Expressions that represent strings
This immits a record, and treats commas as separators between list elements (except when forced by a
preceding asterisk). A generic string name also can be
introduced by a stat.ement. of the form
RESERVE SPACE FOR k STRINGS IN THE
g LIST.
where k denotes a positive integer. The same name
can be given to lists of different length, on different
occasions in the execution of a procedure, and the
processor accommodates these changes automatically
by chaining. The RESERVE statement may be used
to take advantage of knowledge of a limit that is likely,
or which can be imposed.
An entire list can be recorded in the output by a
statement of the form
(PRINT, PUNCH, WRITE,
TYPE) THE g LIST.
PERFORATE,
Successive elements are separated by commas, which
A string expression, that is an expression which
displays or represents a string, may take any of the
following forms in a SNAP statement.
1. A quotation, that is bounded by quote marks.
Within a quotation, /, $, 1, >, and < signify
forced line break, forced page break, case reversal, upper case and lower case respectively.
An asterisk is typed before one of these characters; or a quote mark, to force its literal use
within a quotation. Two asterisks are typed
to represent a single literal asterisk. An =
symbol together with the character that follows
represents a special character. When a quotation continues from one input card (line) to
the next, one space is included between the last
non-blank character on the first card, and the
first character on the next, except when the
former character is a hyphen, in which case it is
elided and the space is not included.
2. An unsubscripted string name, that was introduced by a CALL, COPY, input or RESERVE
80
Spring Joint Computer Conference, 1969
statement, at an earlier point in the procedure,
both as written and as executed.
:t A subscripted string name that contains (i)
a numerical ordinal, or a symbolic ordinal derived from an unsubscripted quantity name
that was defined previously; and (ii) a generic
string name that was introduced by a CALL,
input or RESERVE statement which ends
with the word LIST, at an earlier point in the
procedure.
-t An integer that is positive, or negative, or zero.
Leading zeroes, a plus sign, and spaces before
and after the integer in the expression are elided.
This is because the integer is first stored as a
quantity, and then converted back to a Rtring
representation. The statement PRINT 007,
thus makes the computer print 7 in the first
t.ype position. The statement PRIXT "007,"
however makes the computer print 007 in type
positiolls 1 to 3, since 007 is stored as a string
because of the encompassing quote marks.
5. An unsubscripted quantity name that was
introduced by an earlier SET statement. This
is interpreted, in a context that requires a string
expression, as the string of characters that represents the value of the quantity, without any
leading spaces, or redundant zeroes, or a sign
when it is positive.
n. A subscripted quantity name that contains a
generic quantity name which was introduced
by an earlier SET ... LIST ... or RESERVE
statement. This is treated in the same way as (5).
7. An extract expression of the form
THE k-th CHARACTER OF a.
or
label. This label may be cited m control statements
of the form
CREPE.AT, CONTINUE) C\VITH, FROIVl) g.
where g denotes the label. The verbs REPEAT and
CONTINUE are used respectively when g is earlier
and later in the written procedure, for external appearances; but they are synonymous as far as the
SNAP processor is concerned. The statements
REPEAT FROM THE (BEGINNING, BEGI~NIXG OF THE PROCEDURE).
send control back to the first statement of a procedure,
'\vhich does not Ileed to be labelled. The one ,"\Tord statement
TERMINATE.
returns control to the operating system.
Two forms of conditional statement are used:
IF u v, OTHERWISE w.
IF u v.
The letters u, v and \" here denote the condition,
the succet)s action, and the fail action respectively.
The success action consists of one or more clauses,
that could stand by themselves as unconditional SNAP
sentences. The clauses are separated by commas, when
there are several, and the word AND allowed between
a comma and the first word of a clause. The success
clause, when there is only one, and the last success
clause, when there are several~ may be of the (REPEAT, CONTINUE) (FROM, WITH) kind described
above. Alternatively, it may be
THE k-th THROFGH j-th CHARACTERS
OFa.
where k-th stands for a numerical ordinal, or
a symbolic ordinal t hat contains a previously
defined unsubscripted quantity name; and
j-th does too, and a denotes a string name.
R. A concatenated string expression, that consists
of two or more items of the kinds described above,
joined by the word THEN, to connote COIl=
catenation of the strings that they represent,
within the Nlt-ire string that the expression
represents.
(' ontrol and conditional statements
A SNAP statement may be preceded by a bracketed
CONTIXCE WITH THE XEXT
SEXTE~CE
This is implied when the success action does not
specify a transfer of control.
The fail action may be constructed in just the same
ways as the success action, except that
CONTINUE AS FOLLOWS
is used as the final (or only) clause to take the next
sentence in sequence. It is implied when the fail action
does not specify a transfer of control, and as the entire
fail action in the short form IF u v.
SNAP allows the following forms of condition clause
at present:
SNAP
1. THE I~PUT IS EXHAUSTED
2. £1 IS (GREATER THAN, GREATER THAN
OR EQUAL TO, EQUAL TO, LESS THAN
OR EQUAL TO, LESS THAN, UNEQUAL
TO)~
3.
4.
(IS, ARE)· {THE SAME AS} S2
IS THE SAME AS THE m-th AND (PRECEDENT, SUBSEQUENT) CHARACTERS
OF S2
5. THE m-th AND (PRECEDENT, SUBSEQUENT) CHARACTERS OF S1 ARE THE
SAME AS S2.
S1
S1
and ~ denote quantity expressions. S1 and S2 denote
simple string expressions of the kinds (1) to (7) listed
previously. m denotes a numerical or a symbolic ordinal
that contains· a previously defined unsubscripted quantity name.
PRINT
THE
M-TH
MO~TH.
81
PRINT
"1969/" .
IF K IS EQUAL TO 365 TERMINATE,
OTHERWISE CONTINUE AS FOLLOWS.
INCREASE K BY 1. IF J IS EQUAL TO
THE M-TH LIMIT INCREASE M BY 1,
AND SET J TOl, OTHER WISE INCREASE
J BY 1. IF N IS EQUAL TO 7 SET N TO 1,
OTHERWISE INCREASE N BY 1. REPEAT
FROM THE PRINT A PAGE ACTION.
EXECUTE.
£1
Some more examples
The account of S~AP in the last few sections covers
almost all the features of the basic language. Several
of these may be illustrated by the production of a
simple calendar of the form
WEDNESDAY
1
JANUARY
1969
THURSDAY
2
JANUARY
This example is quite useful as an illustration of
the computers ability to print much more than the
user types, by repeating items in different combination.
It can be extended and modified in numerous ways,
with minimal knowledge of SNAP, which is useful
for teaching pruposes.
Another useful example, whose logic is a trifle more
elaborate, reads a classification scheme from a deck
of cards, such as
VERTEBRATA, (MAMMALIA, (PRIMATES,
(ANTHROPOIDEA,
(SIMIIDEA, CERCOPITHECIDAE, CEBIDAE, H APALIDAE),
LEMUROIDEA, (LEMURIDAE, LORISIDAE,
TARSIIDAE,
CHYROMIDAE», CHIROPTERA, (MICROCHIROPTERA, (VESPERTILIONIDAE, RHINOLOPHIDAE, PHYLLOSTOMATIDAE),
MEGACHIROPTERA,
(P
TEROPODIDAE», INSECTIVORA, ((ERINCEIDAE, TALPIDAE, SORICIDAE, MAC-
1969
IIDAE,
DAE»)
DIDODONTIDAE,
URANOSCOPI-
A SNAP procedure to print this is as follows.
CALL "JANUARY, FEBRUARY, wiARCH,
APRIL, MAY, JUNE, JULY, ArGUST, SEPTEMBER, OCTOBER, NOVEMBER. DECEMBER" THE MONTH LIST.
SET THE LIMIT LIST TO 31, 28, 31, 30,
30, 31, 31, 30, 31, 30, 31.
CALL "SUNDAY, MONDAY, TUESDAY,
WEDNESDAY, THL'"RSDAY, FRIDAY, SATGRDAY" THE DAY LIST.
SET M TO 1. SET N TO 4. SET K TO 1. SET
J TO 1.
(PRINT A PAGE ACTION) PRINT THE
N-TH DAY. PRINT" "THEN J.
that is strung out to save card space, with brackets
indicating subordination, and prints it in a hierarchically indented format, that is
VERTEBRATA
MAMMALIA
PRIMATES
ANTHROPOIDEA
SIMIIDAE
CERCOPITHECIDAE
LEMUROIDEA
CHIROPTERA
tor the zoological scheme just cited. The procedure is
82
Spring Joint Computer Conference, 1969
ACTER OF THE BACKGROUND THEN
THE CARRYOVER THEN THE I-TH
THROUGH K-TH CHARACTER OF THE
INPUT RECORD.
TERMINATE. EXECUTE.
as follows
CALL" " THE BACKGROUND
SET P TO 1. SET Q TO 1.
CALL THE NULL STRING THE CARRYOVER.
(INPUT TEST)
SET J TO O. SET I TO O. SET K TO O.
IF THE INPUT IS EXHAUSTED CONTINUE
WITH THE LAST ITEM ACTION, OTHERWISE CONTINUE AS FOLLOWS.
READ AN INPUT RECORD,
(CHARACTER TEST)
INCREASE J BY 1. CALL THE J-TH CHARACTER OF THE INPUT RECORD THE
KEY.
IF THE KEY IS "("CONTINUE WITH THE
DESCENT, OTHERWISE CONTINUE AS
FOLLOWS.
IF THE KEY IS "," CONTINUE WITH THE
OUTPUT ACTION, OTHERWISE CONTINUE AS FOLLOWS.
IF THE KEY IS 'C)"~ CONTINUE WITH THE
ASCENT, OTHERWISE CONTINUE AS
FOLLOWS.
IF THE KEY IS" " CONTINUE WITH THE
LAST ITEM: ACTION~ OTHERWISE CONTINUE AS FOLLOWS. SET K TO J. CONTINUE WITH THE END CARD TEST.
(DESCENT) INCREASE P BY 1. INCREASE
I BY 1. SET Q TO P.
CONTINUE WITH THE END CARD TEST.
(OUTPUT ACTION) PRINT THE I-ST
THROUGH Q-TH CHARACTERS OF THE
BACKGROUND THEN THE CARRYOVER
THEN THE I-TH THROUGH K-TH CHARACTERS OF THE INPUT RECORD.
SET X TO J. INCREASE X BY 1. SET I TO
X. SET K TO J. SET Q TO P.
CALL THE NULL STRING THE CARRYOVER. CONTINUE WITH THE END CARD
TEST.
(ASCENT) DECREASE P BY 1.
(END CARD TEST)
IF J IS LESS THAN 80 REPEAT FROM THE
CHARACTER TEST, OTHERWISE CONTINUE AS FOLLOvVS. .
COpy THE I-TH THROUGH K-TH CHARACTER OF THE INPUT RECORD AND
CALL IT THE CARRYOVER. REPEAT
FROM THE INPUT TEST.
(LAST ITEM ACTION)
PRINT THE I-ST THROUGH Q-TH CHAR-
The procedure can be shortened slightly by omitting OTHERWISE CONTINUE AS FOLLOWS
from several IF statements. Hundreds of other examples
of SNAP procedures are given in reference 3.
The prototype SN AP processor
The SNAP language was defined almost completely
in late 1966. The processor was implemented in stages,
in part because there seemed good :re.asons t.o demonstrate a working subset, and incremental progress, as
quickly as possible, and in part because of uncertainty
in the potential of the language, and in some of the
details that might be needed. A processor that dealt
with CALL and PRINT statements was developed
first; input, COPY and unconditional transfer of control
statements were added next; then arithmetic operations and conditional statements; and then the further
string instructions, and the statements that deal with
lists. The prototype processor is written almost entirely
in FORTRAN IV. Implementation was started using
a time shared PDP 6 computer. After a few months
the processor was transferred to an RCA Spectra
70-45, and to the IBM 7094 at the Columbia University
Computing Center, where class exercises were run for
a semester using the interim version, while implementation was extended on the Spectra. Work on the prototype was ended recently. It is operating at present
on several Spectra computers, and on the IBM 36075/50 system at Columbia University; and a somewhat earlier version compiled and run on a UNIVAC
1108.
The prototype processor consists of (1) a small control section, (2) the translator, and (3) the interpr'eter.
The translator immits a SNAP procedure, and forms
a numerical repersentation (in "SNAPIC" code) in
the "procedure table". The interpreter then executes
the processes that the SNAPIC representation specify.
The control section simply calls the translator and the
interpreter, and returns control to the operating system
when appropriate.
The SNAPIC representation maps a vebral SNAP
procedure fairly closely. Integers in different numerical
ranges are used for command words, delimiters and
precedence codes tor different kinds of expression,
and pointers to tables that contain, or point to, objects
of interest. An unsubscripted string name in the direct.
SNAP
object of a SNAP statement in SNAPIC is represented
by a pointer to the "string directory". The corresponding entry in this directory points to a definition
of the name in the procedure table, or to the origin
of the string in the string bank, depending on whether
a CALL or a COpy or input statement that ends
with the name was executed more recently. A quantity
name is represented by a pointer to the "quantity
hank" in which actual numerical values are stored.
A subscripted string name is represented by the ordinaj
(subscript), and a pointer to the string list directory
which points in turn to the entry for the first element
of the list, in the subscripted string djrectory. This
contains pointers that identify the actual strings which
are elements of a list, in the same way that string directory elements identify the strings that are known
by unsubscripted names. Pointers to successive elements
of a list are stored consecutively in the subscripted
string directory whenever possible; chaining is used
when necessary. A numerical ordinal is represented
by its numerical part, and a symbolic ordinal is represented by the negative of the appropriate pointer to
the quantity bank. A subscripted quantity name is
represented by the ordinal, and a pointer to the quantity
list directory, which points in turn to the origin of the
list in the subscripted quantity bank, that contains
the actual values of the elements.
The translator was written in an ad hoc fashion.
The initial, and incremental capabiHties were needed,
and obtained, in less time than could be spared to
implement a reasonably powerful syntactic analyzer.
An analyzer will be used in the translator of the advanced system that is being designed, and additional
instructions will be provided to permit users to apply
it to data strings at object time.
The control section, translator and processor occupy
56K, 45K and 48K bytes respectively, of which the last
two can be overlayed, in the link edited version that
runs on the Spectra 70-45. As an indication of the length
of SNAPIC representation, the two procedures in the
preceding section require just under 600 and 700 bytes
respectively.
SNAP as a teaching vehicle
Progranuning in SNAP can be taught to non-scientists by introducing the basic constructions, and showing some of their uses, in the following sequence.
(1) MICROSNAP: This subset of SNAP consists
of (i) PRINT and (ii) CALL statements in which
strings are displayed as quotations, or referenced by
unsubscripted names, and (iii) EXECUTE statements,
to start execution. Some exercises for which MICROSNAP suffices were described earlier in this paper.
(2) MINISNAP: This subset of SNAP consists
of the elements of MICROSNAP and the word THEN.
It extends the variety of display labels, form letters,
programs for the performing arts and for athletic and
sporting events, catalog and greeting cards, and other
materials whose mechanized production can be introduced by MICROSNAP, to allow different items to
be joined on a line. This has an obvious benefit, for
example in the production of form letters.
The addition of the word THEN, moreover, allows
the introduction of several relatively general ideas.
The production of most hierarchically structured materials (such as a set of catalog cards in which a journal
name is repeated throughout while the details of the
issue are repeated with infrequent change, and the
details of the individual papers are repeated for just
a few cards each; or the verbalizations of a long sequence
of year numbers) can use hierarchical naring in a variety of ways, particularly when full use is made of the
"implied redefinition" characteristic of the CALL
statement. Constructing the shortest procedure that
is possible for an application, to reduce keyboard
work to a minimum, introduces the idea of optimization, in a way that the students can readily appreciate,
and which has practical importance when a large volume
of material is processed.
The problem of deciding which pieces of the output
should be given names during its synthesis, and defining
these names most concisely, usiRg just CALL, THEN,
quotations and other names, provides a challenge to
the ingenuity of ~he student, after negligible grammatical instruction, that many non-scientists find novel
and intriguing. Such examples, moreover, give the
student an opportunity to develop an intellectual process, which he can then analyze, and reduce to an algoritlun , with the prospect of mechanizing this
. after
.
learning more progranuning granunar. An Incentlve
is provided to consider fonnal descriptions of the structure of strings, which are amenable to simple algebraic manipulations, of, potential relevance to the design of large files of data, and to some topics in stylistics, and to learn a little about the elementary uses of
graphs.
Some simple combinatorial examples, such as the
production of fifteen menus for table d'hote luncheons,
that combine one of four appetizers, fish, meat and
dessert dishes in all possible ways, can be handled by
procedures that are shorter than the output they produce, and which can be generated by procedures that
are even shorter still. Such examples help make the
student conscious almost from the outset of the course,
that procedures can be written to generate procedures,
to advantage.
84
Spring Joint Computer Conference, 1969
programming rhetoric and applications. Containing
Some mechanized aspects of teaching also can be
these requires a subprocedure capability, such as the
broached, using NIINISNAP. Thus, given an output
one considered next.
device with a reasonable typographic capability, the
tactics that can be used to print. personalized form letters can be applied to the production of a set of texts,
Scanning and invocation
that present MINISNAP (or anything e]se) to reader
groups of different professional interests (e.g., middle
SNAP is not the first programming language to be put
XVth century armorial bearings, later XVth century
into use without a subroutine capability, but with the
armorial bearings, 4.2 mev nuclear physics, 4.25 mev
hope that one would be added later. Plans for an
nuclear physics), by substituting examples and exercises
extended SNAP processor are well advanced at the time
of specialized interest in a common explanatory frameof writing, that will permit subprocedures to be written
work. Another educational topic that may merit exin SNAP, and invoked by statements that increase the
ploration is the mechanical production of a large number
"naturalness n of the language considerably. Quite
of exercises (from a relatively short prescription)
extensive experimentation probably is needed with a
that require the use of different combinations of eleworking system, in working environments, to d~termine
~ent90ry programming constructions, or mathematical
t1- - --e1-.L!v- L _~.c.L
..J L
..J
£
L
..J'-Cj.'
"lie r lC:LlJl t:: ut::l1eUlJS anu uazarus 01 tue uluerent paths
manipulations, or equivalent operational units in other
along which the syntax of invoking statements can be
subjects. It is possible that some students might develop
developed. The extended processor is being designed to
their "intuitions" for an activity which involves selectfacilitate such experiments, by using a syntax driven
ing and manipUlating words or symbols, by working
translator to produce a canonical representation in
large numbers of exercises that could be generated this
extended SNAPIC, for the interpreter to execute.
way, with a saving of human effort, and perhaps anaOne line of exploratiop-, that seems to be particularly
lyzed and criticized mechanically. The problem of
interesting, would co,ntinue to restrict the contexts in
generating exercises for SNAP starts to approach an
whi~h new names for strings, and quantities, and lists,
interesting level of complexity by the time all the posare mtroduced in procedures and subprocedures. Basic
sibilities of ~1INISNAP are considered. It becomes
SNAP requires these to be introduced by CALL, COPY,
interesting when the READ instruction is added, which
input, RESERVE and SET statements at points which
comes next in the progression that is being discussed.
precede their earliest use, in the order in which the
(3) MID/SNAP: The addition of the READ
procedure is written, to define or alter other strings and
statement and REPEAT FROM THE BEGINNING
quantities. It is possible therefore to scan a CALL
to the elements of MIKISKAP permits the separation
statement from left to right alternately for (i) simple
of procedures and data, and some very elementary data
string expressions of the forms (1) to (7) given earlier
driven procedure generating procedures. Adding extract
and (ii) the word THEN, and to treat the balance of th~
expressions permits the deconcatenation of input
sentence that remains when THEN is not found as the
records, and the expansion of fixed field records that
name that the statement confers on a string (or on 90 list
omit characters (e.g., decimal points, units of measureof strings). This name is added to the name table if it
ment, century digits) which are implicit in the record
has been used before. The tactic can be elaborated for
design, to include these in the output. It is convenient to
example to allow names that are substrings of o~her
introduce IF statements that compare strings and
names. Examples can be constructed to confuse the
statement labels next, then the COpy statement and
tactic, probably no matter how much it is elaborated
then arithmetic. By this stage, additiollal con;trucbut the objective of natural language programming is t~
tions, and applications are accepted as more or less
deal with statements that look" natural" rather than
expected matters of detail. MIDISNAP, that contains
bizarre. The preposition TO can be allowed in the names
the elements which have just been mentioned, is
of quantities (and strings) by using similar tactics in a
adequate for a considerable range of text generating
right to left scan of SET statements.
problems, that use fixed field files on punched cards
The tactic can be extended fairly simply to procedures
I\. or
·.j.h t1h e a dd"ItlOn of SELECT and FETCH
Wil!l
that contain invoking statements of the following kinds:
magnetic media); and may well be a convenient subse~
of SNAP for an elementary course in mechanized text
1. The statement begins with a word that is neither
processing and programming concepts, for implementaone of the basic verbs of SNAP nor IF; its only
tion on relatively small computers.
a.rguments are previously defined names, quota(4) Basic 8N AP: The further SNAP constructions
tIOns and numbers; the framework in which these
that deal with strings and lists open the floodgates of
are embedded identifies the subprocedure; no
SNAP
continuous piece of this framework is used as a
name in the procedure.
2. The statement begins _with a basic verb of
SNAP, and contains one or more function
expressions, in contexts in which the representation of a string or quantity is appropriate. Each
function expression consists of an opening word
or phrase that is characteristic of the function,
followed by one or more arguments, of the kinds
mentioned in the preceding paragraph, in alternation with further words, phrases and/or punctuation that completes the framework which
identifies the function. It is convenient \to allow
either an argument or part of the framework to
come last, and to require a comma as the last
character in the latter instance. No continuous
part of the framework may be a name that is
used in the procedure, or a number, and nesting
is prohibited.
3. The statement consists of a clause of the form (1)
above, a comma, and a further clause such as
FORMI~G X, Y,/AND Z CONCURRENTLY,
that in general consists of a participle ending in
IKG, one or more names that need not have been
used previously, separated by commas and
possibly AND; and a final word (e.g., THEREBY, ACCORDINGL Y) to round off the
sentence.
Although these conventions are very simple, they
cover quite a range of" natural" expressions. The form
(1) goes beyond allowing the user a free choice of one
word verbs, which often would be insufficient. A verb
can be qualified immediately, or at the end of a sentence
adverbially or in other ways. Examples of such invoking
statements are:
SE~D
A ~IE~IBERSHIP CARD TO "GRENDEL .JONES" AT "THE BEACH HUT".
SEN"D AN OVERDCE RE~1INDER TO
"DR. FArST" AT "SA~S" SO"CCI/BRILLIG
DRIYE".
ANXOCXCE "THE CHASED AND
THE PCHS(,ER" TO "THE TRASH CAX/75
DREARY LANE" IX S(,GGESTIVE TERMS.
AKNOCNCE "THE ILLIBERAL LIBERATION" TO "THE PAPER BACK EGGHEAD/93 FARM YARD" IN INTELLECTUAL
UKDERTONES.
which would invoke four separate subprocedures,
characterized by the frameworks left by omittIng the
quotations.
85
The proposed conventions also allow free use of
prepositions (except THEN, which is best left out) in
the invoking framework which is a great aid to naturalness. By allowing the generic name of the elements of a
list as an argument, the definition of superlative
adjectives (as in THE SHORTEST ITEM) is
introduced .
The form (1) invoking statement suggested above
can be used when a subprocedure does not create any
entities for which names do not yet exist in the invoking
procedure. Form (2) is useful when one new name must
be introduced, and form (3) when several are needed.
A simple convent jon for heading sub procedures is to
begin with a statement of the form PROCEDURE TO
followed by the invoking skeleton in which dummy
arguments are embedded. These arguments then can be
listed in a statement that begins THE ARGUMENTS
ARE .. (or THE ARGUMENT IS .. ). Function subprocedures can be headed PROCEDURE FOR .. ING ..
where .. ING denotes an arbitrary participle (e.g.,
FORMING, FI~DING) and the further dots stand
for the function expression with embedded dummy
arguments. Some further provisions also will be made
for input output, and for user defined conditions.
Introducing the indicative
SNAP, as it has been described so far, consists almost
entirely of imperatjve mood statements. The extended
language that is now planned will also include several
kinds of indicative mood statements, that will allow
statements such as:
(i) THE NAMES OF STRINGS INCLUDE
THE S"CRNAME, THE PRENAME, AND
THE ADDRESS.
(ii) THE PRESIDENTIAL RECORD CONTAINS THE STJRNA~IE~ THE GIVEN
NA:NIE, AND THE DATE OF BIRTH;
I~ CHARACTER POSrrIO~S 3 TO 12, 13
TO 25, A~D 26 TO 33, RESPECTIVELY
(iii) THE TOWN DATUM LIST CONSISTS OF
THE TOWN NAME, THE INCORPORATION DATE, THE POPULATION, THE
ALTITUDE, THE MAYOR, THE MAJOR
INDUSTRY, THE LARGEST PARK, AND
THE :YIAIN MUSEUM.
(iv) THE OB.JECTS INCLUDE THE PRESIDENT, AND THE VICE-PRESIDENT.
(v) THE PRESIDENT IS DESCRIBED BY
THE PRESIDENTIAL RECORD.
(vi) THE VICE-PRESIDENT IS DESCRIBED
BY THE VICE-PRESIDENTIAL RECORD.
86
Spring Joint Computer Conference, 1969
(vii) THE PRESIDENT IS DESCRIBED BY A
BIOGRAPHICAL RECORD.
(viii) THE VICE-PR~SIDENT IS DESCRIBED
BY A BIOGRAPHICAL RECORD.
(ix) A BIOGRAPHICAL RECORD CONTAINS
THE SURNAME, THE GIVEN NAME,
AND THE DATE OF BIRTH; IN CHARACTER POSITIONS 3 TO 12, 13 TO 25,
AND 26 TO 33, RESPECTIVELY.
The sentences (i)-(iii) are, in effect, verbalized fonus of
type declaration, format statement and equivalence
statemen.t. Sentence (iv) is a type declaration that
makes THE PRESIDENT and THE VICE-PRESIDENT the names of objects, which sentences (v)
and (vi) relate (by a convention that governs the use
of IS DESCRIBED BY) to two strings called THE
PRESIDENTIAL RECORD and THE VICE-PRESIDENTIAL RECORD. Statements analogous to
(ii) could then be used to describe the internal structure
of these strings. Statements (vii) and (viii) take a
slightly different tack, using a generic string name. By
convention these statements would permit the expressions 'rHE BIOGRAPHICAL RECORD OF
THE PRESIDENT and THE BIOGRAPHICAL
RECORD OF THE VICE-PRESIDENT to be used
as string names, for example in input statements; and
in conjunction with sentence (ix) would propagate
this association, to allow the use of expressions such
as THE SURNAME OF THE PRESIDENT to be
interpreted correctly. Further simple sentences, tha~
contain the verb HAS, can be used within the framework of some more simple conventions to introduce
the names of obj ects that are attributes of other obj ects,
and described by strings that thereby become. indirect
attributes of the latter objects.
Syntactic definitions are of considerable importance,
and in this regard the kind of meta-syntactic language,
and method of representing the result of a syntactic
analysis that were developed in the author's laboratory
at M.I.T.Ii.6 some years ago seem a useful basis for further work.
M~ny further kinds of definitional device can be
postulated that seem potent~lly useful. For example,
class inclusional schemes are given an added dimension
by the simple tactic which js illustrated by the following sequence of statements, that relat.e t.o a file concerning animals in a zoo.
IN THIS PROCEDURE:
THE KINDS OF CATEGORY INCLUDE SUBKINGDOl\fS, ORDERS, CLASSES (SINGU-
LAR-CLASS), FAMILIES (SINGULAR-FAMILY), AND SPECIES (SINGULAR-SPECIES).
THE KINDS OF OBJECT INCLUDE ANIMALS.
THE SUB-KINGDOMS OF ANIMALS ARE
VERTEBRATES, AND INVERTEBRATES.
THE ORDERS OF VERTEBRATES ARE
MAMMALS, BIRDS, REPTILES, AMPHIBIA (SINGULAR-AMPHIBIAN), AND FISH
THE SPECIES OF APES ARE GORILLAS,
CHIl\1PANZEES, AND ORANG-UTANS.
AN ANIMAL IS DESCRIBED BY A RESIDENT RECORD.
A RESIDENT RECORD CONTAINS THE
SPECIES, THE DATE OF ACQUISITION,. ..
(LOOP START) READ A RESIDENT RECORD. IF THE ANIMAL IS A VERTEBRATE
PRINT THE ORDER ....
The example has, amongst other things, an element
of metonymy. The word SPECIES appears as a kind of
category, that includes GORILLAS, CHIMPANZEES
etc., and also as t.he name of a substring of a RESIDENT RECORD. These two uses will be associated:
so that when necessary, the contents of the SPECIES
field of a RESIDENT RECORD may be compared
with the instances of SPECIES in the class inclusional
statements. This will make it possible to use the latter
words in the data, and to interpret st.atements such as
the IF statement that ends the excerpt.
ACKNOvVLEDGlViENTS
The work reported in this paper was done in the
Graphic Systems Applied Research Lahoratory, RCA
Laboratories, Princeton, N.J., with which the authors
were associated.
REFERENCES
1 Annual reviews of information science
John Wiley and Son 1968
2 M P BARNETT W M RUHSAM
A natural language programming system for mechanical text
processing
IEEE Transactions on Engineering Writing and Speech
Vol EW8-11 No 2 August 196845
3 M P BARNETT
Computer programming in English
Harcourt Brace and World New York Spring 1969
SNAP
4 W M RUHSAM
M P BARNETT
To be published
5 M P BARNETT R P FUTRELLE
Syntactic analysis by digital computer
CAe M Vol 5 1962515
6 M P BARNETT M J BAILEY
The 8hadow V 8y8tem
Unpublished work
87
The compiled macro assembler
by WARD DOUGLAS MAURER
U'YLiversity of California
Berkeley, California
INTRODUCTION
same way. The text of a macro definition is copied into
memory, after various minor transformations such as
the removal of blanks. In some assemblers, the information contained in a macro may be further compressed, but in an interpreted macro assembler the
compression is done in an essentially recoverable way
if it is done at all. When the macro is used, this text
is read from memory in what may be called an interpretive fashion-although there is no separate interpreter, the entire assembler itself serving as the macro
interpreter.
In a compiled macro assembler, all pseudo-operations-macros as well as others-have their corresponding subroutines of the assembler. At the start of each
assembly there exists a fixed collection of such subroutines. However, when a macro is defined, a new subroutine is formed. This subroutine is compiled (hence
the name, compiled macro assembler) from "source
text" consisting of the original macro definition. The
writing of a compiled macro assembler consists in the
mechanization of the process of deducing, from the
form of a given macro definition, how a use of this
macro would be treated within the assembler if it
were a pseudo-operation rather than a macro.
As an illustration of the concept of macro compilation, an actual co~piled macro assembler was constructed by the author and his students. * This assembler
is written to run on the CDC 6400. The input language
is a modified form of IBM 360 assembly language;
the output from the assembler is a listing of the IBM
360 code generated, and a deck of binary cards which
will execute on the 360 when appropriate control carda
are added.
This paper describes an advance in the art of writing
assemblers. It embodies an idea which has been suggested at least twice, but never actually implemented.
In a compiled macro assembler, ordinary source
language statements .are processed in the usual way,
but macros are processed in a novel way. The advantage of the compiled macro assembler is the speed
with which it processes macros. An actual compiled
macro assembler has been written by the author and
his students, and the speed with which it processes
macros, as distinguished from ordinary statements,
has been rigorously tested.
The bagic concept of the compiled macro assembler
We review, first of all, the operation of an ordinary
assembler, which we will refer to, in what follows, as
an interpreted macro assembler. (The words "compiled"
and "interpreted" are presumed to modify the noun
"macro," not the noun "assembler.") Each pseudooperation code in the assembly language recognized
by a given assembler corresponds to a subroutine of
that assembler. This subroutine is called whenever the
given pseudo-operation is encountered within the source
text. The collection of all of these subroutines, for a
given assembler, is a fixed collection, and on a large
computer this collection of subroutines is normally
contained in core at all times. On a small computer,
the subroutine which corresponds to a given pseudooperation may have to be brought in from disk when
the pseudo-operation is encountered; however, the
total collection of subroutines corresponding to pseudooperations remains fixed.
A macro is, in one sense, very much like a pseudooperation. However, in an interpreted macro assembler,
the occurrence of a macro does not set aside a special
subroutine of the assembler for the use of that macro
alone. Instead, all macro definitions are treated in the
------------------------------------------------~-----------------
* The students included Donald Alpert, Steven Anderson, 1
Robert Ankerlin, Thomas Baumbach, David Brown, Dennis
Griswold,2 Bing Joe, Richard Kayfes,a David Ladd, Kenneth
Lew,4 William Nielsen,' Ralph Olstad, Paul Samson, and'Edmond
Van Doren.'
89
90
Spring Joint Computer Conference, 1969
Feasibility of macro compilation
The following paragraphs are devoted to certain
feasibility considerations which the author and his
students discovered in the course of writing this assembler. These points should be thoroughly understood
by anyone intending to write such an assembler in the
future.
Substitution of parameters
There are two common methods of handling macro
parameters in an assembler. These are known as
string stwstitution and value Sltbstitution. Either may
be used in a compiled macro assembler. In addition,
if value substitution is used, compilation may be carried
out completely; whereas if string substitution is used,
it is necessarv to include both compiled and interpreted
macro facilities, and it may be necessary for a compiled
subroutine to call the interpretive facility.
For the sake of completeness, we now describe these
two methods in general terms. In value substitution,
each actual parameter in a macro usage is evaluated.
This value is substituted within the macro text whenever the corresponding formal parameter is encountered. In string substitution, the character string which
comprises a given actual parameter in a macro usage
is copied into memory when the macro usage is encountered. If the assembler is an interpreted macro
assembler, the source of input characters to it is now
diverted to the location of the macro text in memory.
When a parameter is encountered, the source of input
characters is re-diverted to the location of the character string giving the corresponding actual parameter.
String substitution is more general than value
substitution because the sequence of input characters
passes freely between the characters of the macro
and the characters of actual parameters. Thus syntactic units may exist partially within the macro text
and partially within the parameter. One important
use of this facility is the appending of prefixes or suffixes to an actual parameter to form symbols. If a macro
is called with actual parameter DM, for example,
the macro may then create symbols DMA, DMB,
DMl, TEMPDM, and the like, and use them in an
arbitrary fashion. Such symbols, of course, become
global, and may be referenced throughout the text.
In a value substitution assembler, this facility is not
possible; but in many value substitution assemblers
a symbol defined in a macro cannot be used outside
the macro unless it is specially declared to be global.
Thus the. same symbol may be used over and over
again, so long as it is always used inside a macro and
only once inside each distinct usage of that macro.
String substitution has been used in most assemblers
which have appeared in published work, such as Halpern's XPOP,7 Strachey's general purpose macro
gen ~rator,8 and Mooers' TRAC.9,lo Value SUbstitution,
however, because it is simpler, has been used in many
actual, working assemblers. Among these are the F AP
assembler for the IBM 7094, the SLEUTH II assembler
for the UNIVAC 1107, and an assembler for the
UNIVAC III, all of which were written by Ferguson,
who, so far as we know, hlS published only one account of his work.ll
Let us now consider the substitution of parameters
in a compiled macro assembler. If value substitution
is used, there is no problem. Suppose that a parameter
usage is found within a macro definition. Corresponding
to this usage in the compiled subroutine, there is a
call to a subroutine which retrieves the value of the
corresponding actual parameter. (That is, the compiled subroutine, which is produced by the macro
compilation process, calls a fixed, special assembler
subroutine, whose function it is to retrieve parameter
values.)
If string substitution is used, we make a distinction
between a parameter which occurs in an expression
in the variable field, and one which occurs by itself
in the variable field. (Most actual parameters are
of the latter kind, because most people write relatively
simple macros.) If a parameter occurs by itself, th~re
is no difference, for this parameter, between stnng
and value substitution, and it may be handled as described above. If a parameter occurs in an expression,
however, it is generally impossible to han~le it in
a compiled manner. The text of the expressIOn must
be included with the compiled subroutine, and, at the
appropriate point, this subroutine ~alls ~ ~ed, s~ecial
asgornhlol" I;,mhw\11t.1TlO whose functlon It IS to Interpreti;;i;& e;~l~~tev·;~ch strings. As in the case of an
interpreted macro assembler, this "subroutine" consists, from the logical point of view, of the entire assembler itself.
First and second pass compilation
The compilation process, as applied to a macro,
must take place twice-once in the first pass and once
in the second pass.
There are many reasons for this; the following is
perhaps the simplest. Suppose that the definition
of a macro involves a symbol which is not defined
until after the macro is defined. Then, when the macro
is first encountered, complete compilation cannot
take place, since the value of the sym hoI is not kn~wn
at that time. Therefore the macro must be compIled
in the second pass. But it must also be compiled in
The Compiled Macro Assembler
the first pass, since the length of the generated code
is not known, and different uses of the same macro
may result in different lengths of generated code. *
The main function of the subroutine which is compiled
in the first pass, in fact, is to determine this length;
at the same time, any global symbols defined within
the macro are placed in the symbol table along with
their addresses.
It might appear at first sight that this problem
could be avoided by defining all sylllbois used in a
macro before the macro is defined. However, this is
not feasible in general. A macro may contain a call
to an error routine which is at the end of the program,
or, in general, which follows another usage of the macro.
It is, in 'general, true that all symbols occurring within
a macro definition which affect the length of the generated code must be defined before the macro is defined.
By somewhat devious methods this may be improved
slightly to read "before the macro is first used."
Saving a compiled subroutine
One of the theoretical advantages in compiling
macros is that the resulting compiled code can, in
theory, be output to cards, in the same way that output
from a FORTRAN compiler can be output to cards.
These binary cards may then take the place of the original macro definition.
We have found that compiled subroutines can,
in fact, be saved in most cases. There is one case, however, that creates several difficulties. Suppose that a
macro definition contains a symbol which is used but
not defined. Presumably such a symbol would be defined in the body of the assembly language text. (In
our experience, most macros do not have this characteristic; but some do, and in any event it would be
unwise to exclude it.) The definition of the given symbol in the program in which it is defined is not, however, necessarily the same as its definition in the program in which the binary cards are used. It is this
latter definition, in fact, which should apply. Therefore, a distinction must be made when, compiling
a macro between symbols defined in the macro
and symbols defined outside it. There are further
difficulties concerned with optimization of the compiled
code. If the value of a symbol is known at compilation
time, it may be combined with others in an expression,
* The SLEUTH II assembler embodies an interesting exception
to this. If a given macro always generates the same amount of
code, this amount may be specified when the macro is defined.
Presumably this feature could be implemented in a compiled
~cro assembler, removing the necessity for compiling such
macros on the first pass. However, as we shall see later. such a
macro probably should not be compiled anyway.
91
and the value of the result used within the compiled
code. If code is being compiled for later use, however,
such combination cannot be made. This means that
either the resulting compiled code must calculate
values of expressions which would not be necessary ,
if the macro were being compiled in that assembly,
or the process of loading the binary cards must effectively incorporate some of the compilation process.
Only the second pass compilation need be saved
on cards. '\X/hen this is loaded during the first pass of
another assembly, it is loaded in a special way which
causes it to act like a first pass compilation.
Compiled macros and conditional and iterative
assembly
Conditional statements in assembly language may be
compiled; so may iteration statements. In fact, compilation of these statements is the primary justification
for compiled macro assembly. A conditional statement
in the definition of a macro may be replaced by a conditional transfer in the compiled subroutine; it is no longer
necessary to read a number of characters without
processing them if the condition is not fulfilled. An
iterative (duplication) statement may be replaced by
a loop in the compiled code; it is no longer necessary to
interpret the iterated statements repeatedly.
A macro which is to be used only once, and which
contains no conditional or iterative statements, should
not, in fact, be compiled. This is a special case of a
general statement which may be made about interpretation/compilation situations: compilation is faster
than interpretation only if no recycling takes place.
If every statement in a program is to be executed at
most once, it is cheaper to interpret each statement
once than to compile it (which itself involves interpreting each statement once) and then to execute it.
The time saving that results from compiling is due to
the fact that if a statement is to be execut~d several
times, it will be interpreted several times if the program
containing it is interpreted, but only once if that program is com piled.
A macro without conditional or iterative statements
may be speeded up on compilation if it is to be used
several times, but an intelligent judgment should be
made in each such case.
Timing tests of the compiled macro assembler
In order to verify the premise that compiling macros
improves the efficiency of macro usage processing,
a controlled experiment was performed on the compiled
macro assembler written by the author and his students, with the standard IBM 360 F level assembler
serving as the control.
92
Spring Joint Computer Conference, 1969
Timing comparisons of systems designed in different
ways to do the same job has proved to be one of the
most frustrating tasks in the computing world today.
For ahnost every comparison which has been performed,
a perfectly valid argument may be advanced which
nullifies its conclusion. Usually this argument takes
the form that the observed differences in timing were
caused by something other than the differences in the
initial conditions. The use of a controlled experiment,
a technique borrowed from classical scientific method,
is precisely the way in which the effects of such irrelevant factors may be eliminated. In the present situation, the following were the factors which introduced
differences in timing comparable to, and sometimes
exceeding, the claimed improvements in efficiency:
1. Th.e time taken to process a macro was smaller
than the time taken to read a carde
2. The time taken to process a macro was smaller
than the time taken to print a line.
3. The total time taken to process a job differed
depending on when the job was submitted;
in fact, it sometimes happened that when the
computer was asked to perform the same job
twice in a row (by submitting an input deck
consisting of two identical copies of a job deck)
the job times differed by a factor exceeding 1.5.
4. The IBM 360 F level assembler as used at the
computer center at which the test was made
is slower than the Compiled Macro Assembler,
by a factor which may exceed 10.
5. The IBM 360 F level assembler is not used at
its own greatest efficiency by the computer
center at which the test was made.
The controlled experiment was set up in the following
way....A... macro, RPD3, which generates code to calculate the value of a real polynomial of degree less than
or equal to 3, was written for both the Compiled Macro
Assembler and the IBM 360 F level assembler. The
macro was called, in either assembler, by the line
RPD3
X,A,B,C,D
where X, A, B, C, and D represent addresses in memory
and A + BX + CX2 + DX 3 is the polynomial to be
evaluated. The algorithm always uses the fastest computational method; if all of the coefficients are nonzero, then A + X*(B + X*(C + X*D)) is calculated,
but if any of the coefficients are zero, a smaller amount
of calculation is performed. If all the coefficients are
zero, the result register is loaded with zero. Otherwise,
the total number of instructions generated is equal
to the total number of non-zero coefficients plus the
degree of the largest such coefficient.
A deck was now made up, containing 200 calls to
this macro with various parameters. This deck was
assembled to obtain a printout of the code it generated.
A second deck was now made up which consisted precisely of this generated code. Assembly of these two
decks, then, should produce identical results· in different ways-with and without macro usage processing.
To counteract the effect of factor (1) above, a second
macro, called NIL, was written, which does nothing.
The text of NIL was added to the first deck, and exactly
enough usages of NIL were added to the first deck to
equalize the number of cards in the two decks. To be
absolutely precise, there. were now four decks, because
all of the above was done twice, once for each assembler.
To counteract the effect of factor (2) above, all assemblies, on both assemblers, were run with a "no
list" option during the timing test, after it had been
ascertained that they generated correct code. The use
of this option insures that no printing will occur during
the second pass of assembly. To counteract the effect
of factor (3) above, each of these four decks was reproduced several times, and the resulting copies of
each deck were run as a connected series of jobs.
The results of the timing test were as follows. For
the IBM 360 assembler, the runs without macro calling
took 3 min. 21.94 sec" 3 min. 39.92 sec., 4 min. 25.87
sec., and 3 min. 29.00 sec. The runs with macro calling
took 9 min. 33.90 sec., 7 min. 52.06 sec., and 7 min. 56.28
sec. Even with the large experimental error, it is clear
that this assembler is taking over twice as long to
process an assembly with macros as without macros.
For the Compiled Macro Assembler, the runs without
macro calling took 16.433 seconds and 16.428 seconds;
the runs with macro calling took 16.458 seconds, and
16.538 seconds. Thus there is no appreciable difference,
in the compiled macro assembler, between assembly
of macros and assembly of the identical code without
macros.
The presentation of the results in this form counter~
acts factors (4) and (5) above. In particular, anyavoidable inefficiencies which affected the timing of one of
the IBM 360 runs would also have affected the timing
of the other. We also note that factors (1) and (2) do
not, as has been claimed, remove entirely the timing
advantage of compijing macros, since on a time-shared
computer the time taken to process a macro will usually
not be smaller than the time taken to read a card image
from a file. It is also true that time-sharing systems
increase the viability of assembly language coding as
opposed to coding in a higher-level language, since debugging languages (such as DDT and FAPDBG) are
much more amenable to machine language than they
are to higher level language coding.
The Compiled :Macro Assembler
ACKNOWLEDGMENTS
The author is grateful for the progrrunming help of
the students mentioned in the first footnote to this
paper. This research was parti311y supported by
National Science FOlUldatjQn Grant G-J43 and Joint
Services Electro~cs Program Grant AFOSR-68-1488.
REFERENCES
l
~ AND.~J:>"S9N
Master's report University of Ca1ifornil\ Berkeley J3D.uary
1968
2 D GRISWOLD
Object deck output from a compiled macro assembler
Master's report Univ of Californ.i8 Berkeley September 1967
3 R KAYFES
Decimal arithmetic in a compiled macro assembler
Master's report Univof California. Berkeley June 1967
4KMLEW
N on-decimal arithmetic in a compiled macro assembler
Master's report University of Califoria Berkeley June 1967
5 W C NIELSEN
93
Subsystem implementation of a compiled macro assembler
Master's report University of California Berkeley June 1967
6 E D VAN DOREN
The literal facility and end card implementation of a
compiled macro assembler
Master's report Univ of California Berkeley September 1967
7 M HALPERN
XPOP: a meta-Janguage without meta-physics
Proc F J C C 1964
8 C STRACHEY
.4 general purpose macro generator
Computer Journal October 1965
9 C MOOERS
TRAC, a procedure-descrWing language for the
reactive typewriter
Communications of the Assoc for Computing Machinery
March 1966
10 C MOOERS
T RA C, a text-handling language
Proc 20th ~ational ACM Conference 1965
11 D FERGUSO~
Evolution of the meta-assembly program
Communications of the Assoc for Computing Machinery
March 1966
Some logical and numerical aspects
of pattern recognition and
artificial intelligence
by W. CLARK NAYLOR
IBM Corporation
Rochester, Minnesota
INTRODUCTION
Artificial Intelligence has received the attentions and
contributions of workers in many varied disciplines
.. and of many varied interests. As a result there has
arisen a large and diverse body of research literature
in the field. The task of sorting out and comparing
some threads of continuity through this rich and variegated tapestry presents a. tempting prospect.
In this article we define and compare two contrasting
pattern recognition approaches. We trace their divergent paths of development from their common origin
and em.phasize their complementary nature. Finally,
we propose their eventual reconciliation and suggest
some potentially fruitful lines of development.
Threads oj continuity
In 1961 Hawkinsl examined the state-of-the-art of
self-organizing machines and traced some historical
developments from early brain models to later computer
implementations. This report builds on Hawkins'
historical review, emphasizing two separate lines of
development and extending them into more recent
pattern recognition efforts.
Figure 1 displays two lines of relevant publications
by author. At the origin of the lines we indicate the
neuron. Section A (below) discusses some of what is
known and postulated about the behavior of natural
neurons. Section B follows the line of development
indicated along the horizontal axis of Figure 1, and
emphasizes the logical aspects of pattern recognition.
In Section C we follow a line of development displayed
along the vertical axis and emphasize the numerical
aspects of pattern recognition. In Section D we discuss
some of the problems of dealing with both aspects of
the pattern classification problem at once.
1
I
I
:I
I
;I
•e
it
z
LOIiCII Aspects
.,
Figure I-Diverging complementary lines of pattern recognition
development
A. Natural neurons
In nature, an organism interacts with its environment
to enhance its chances for survival and propagation.
The more an organism. is capable of rapid, complex,
adaptive behavior, the more effective its interaction can
be. In the animal world special sensors, effectors, and
associated nervous systems have developed to achieve
this rapid, complex behavior. And although the complexity of the nervous systems varies greatly from the
lowest to the highest animals, the properties and behavior of the basic nerve cell, the neuron, remain
amazingly constant.
-------------------------------------- 95-----------------------------------------
96
Spring Joint Computer
Conference, 1969
The neuron is a cell specialized for conducting electrical signals. It is the cell of which ail nervous systems
are constructed. In vertebrates, bushy dendrites extend from the cell body to receive afferent excitation
and conduct it to the axon. The axoIi, on receiving
sufficient excitation) "fire's" and conducts a spike
pulse along its length to the axonal branches. There
the excitation is communicated across various synaptic
junctions to succeeding dendrItes, and so on. After
firing, the cell enters a refractory state during which
it rests and recharges its membranes in preparation
for the next firing. Some neurons can repeat this cycle
hundreds of times a second,
Many neuron configurations exist. Neurons may
have long axons, very short axons, several axons, or
no apparent 3.Xons at all. They may have many dendrites or no descernible dendrites. Dendrites and axons
may be virtually indistinguishable. Likewise, many
varieties of synapses exist. Some transmit electrically,
some transmit chemically. Some transmit axon-toaxon and Some transmit dendrite-to-dendrite. Probably
the most interesting are the synapses between axonal
branches and soma or dendrites, typical in vertebrate
brain cells.
B. Logical development
A network ofaxons, each capable of a binary all-ornone response, is strongly suggestive of switching
theory and logic, and much of the work in pattern
recognition and artificial intelligence is based on this
observation.
Rashevsky3 in 1938 was perhaps the first to postulate
that nets of such binary axons could perform certain
decision and memory functions. lVIcCulloch and Pitts4
in 1943 formalized these concepts and showed that
the behavior of such nets could be described in terms
of Boolean algebra. Later, Lettvin, Maturana, McCulloch, and Pitts5 in 1959, and Verzeano and Negishi6
in 1960, were able to experimentally substantiate some
of these ideas.
In 1959, Unger7 described a pattern recognition program in which he used the logical structure of a binary
tree to separate an alphabet of 36 alphanumeric characters. In 1961, Kochen8 described a concept formation
program which could adaptively derive its own Boolean
sum of products from its experience with the data.
And, in 1967, l\1insky9 considered general machines
composed of McCulloch-Pitts neurons. He established
several universal bases for building finite automata,
and showed that a very simple "refractory cell" formed
such a base.
c.
Numerical development
While the logical development exploits the logical
ability of the axon behavior, it greatly oversimplifies
or largely ignores the role of the synapse.
In 1949, Hebb lO suggested that perhaps the synapse
provided the site for permanent memory. He postulated that the ability of the axonal branches and the
dendrites to form graded potentials, and the ability
of the synapse to differentially attenuate and integrate
the influence of many impinging signals, might somehow
-change as a function of learning. In 1958, Rosenblatt ll
incorporated these and other ideas into a model he
called the Perceptron. At about the same time, Widrow12
began experiments with similar analog models he called
Adalines. Many workers 13- 21 showed the ability of these
models to implem~nt linear decision surfaces, and the
ability of certain training procedures to converge to
feasible surfaces. In 1963, Rosen22 employed quadratic
programming to obtain optimal decision surfaces for
both linear and quadratic models. In 1964, Mangasarian23 obtained optimal decision surfaces using linear
programming. Based on a Bayesian statistical approach,
Specht,24 in 1967, derived optimal decision surfaces
for general nth order polynomials.
D. Combined logical and numerical aspects
In his critical review of Artificial Intelligence work,
Dreyfus29 addressed himself primarily to workers
specializing in logical methods. In criticizing the assumptions of Newell, Shaw, and Simons30 he said "they
do not even consider the possibility that the brain
might process information in an entirely different
way than a computer-that information might, for
example, be processed globally the way a resistor analogue solves the problem of the minimal path through
a network." In the present context, this and other
similar comments in his paper seem to be suggestions
for more careful consideration of numerical, as well
as logical, methods.
While it appears that some workers have been applying logical tools to geometrical tasks, it also appears
that other workers have been applying geometrical
tools to logical tasks. For example, in the layered machines mentioned in Nilsson,25 it is necessary for the
first layer of linear decision surfaces to completely
partition the input space. Succeeding layers of linear
decision surfaceR then operate on the output of previous layers and so on. However, when the input space
has been completely partitioned, it has been mapped
without confliet onto the vertices of a hypercube.
When this haR been accomplished, only a problem in
Boolean logic remains, and it seems a little wasteful
L.ogical and Numerical Aspects of Pattern Recognition and Artificial Intelligence
to use additional layers of linear decision surfaces for
this task. Moreover, no general training procedures
for such machines have yet been found.
While those workers mentioned in Section B have had
success in dealing with the logical aspects of the pattern recognition problem, and- those workers in Section
C have had success in dealing with the numerical aspects, few workers have been successful in dealing with
both aspects at once. However, some recent approaches
appear very promising in this direction. In 1965, C asey26
described a program for reducing the dimensionality
of sets of patterns. This would appear to be a good
first step toward discovering the structure of a problem.
Ball and Hall's program27 to automatically cluster
sets of patterns can be viewed as a process for finding
logical structures of imbedded numerical decision surfa-ces. The most clear-cut example in this direction
is the 1968 program of Mangasarian. 28 This program
iteratively builds a ternary tree of linear decision surfaces. Each surface is designed to be the optimum
for its level on the tree, and the tree is indefinitely
expandable.
The complementary nature of logic and
geometry in pattern recognition
We would like to argue in the following sections that
the two divergent lines of development pursued in the
previous sections are not alternate approaches to the
same problem but rather complementary approaches
to that problem. That is, that a general approach
must involve both aspects and that an approach emphasizing only one aspect must be somehow incomplete.
This argument must be based on efficiency rather than
ultimate effectiveness since either approach may be
employed to eventually obtain a very good approximation to the desired result.
A. Set theory and pattern recognition
If we view pattern recognition in a set theoretic framework, the roles played by the two ordering relations,
set membership, E, and set inclusion, ( , are very
significant. If we are dealing with sets (or .patterns)
of real vectors, we see that we have two distinct algebras involved.
Among the sets themselves, we have the algebra of
set combination or logic. Among the members of the
sets, we have the algebra of real numbers, arithmetic
or geometry. * The difference in emphasis evident in
* In some examples of pattern recognition we may have other
relations holding among set members (for example, grammatical
relations in language translation). If the algebra among set
members happens to be Boolean logic, then this whole distinction
may disappear.·
97
the logical and numerical developments amounts to
a difference in emphasis on the roles of the two algebras
involved. Thus, in the logical development, the ultimate classes are composed of complex combinations
of sets with very simple membership criteria. The
algebra of set combination (viz logic) is strongly emphasized, while that holding among set members (viz
geometry or arithmetic) is largely ignored. On the other
hand, in the numerical development the ultimate
classes have no apparent constituent sets and the criteria of set membership must bear the whole burden
of the classification task. Thus the algebra holding
among the set members (viz arithmetic or geometry)
is strongly emphasized while the algebra among the
sets is largely ignored.
B. Example
The complementary nature of the logical and numerical approaches may be likened to the complementary nature of Fourier and polynomial series. The
Fourier series may be used to approximate a straight
line, and the polynomial may be used to approximate a
sine curve, but it is an unnatural and wasteful way to use
the series. Similarly, logic may do the job of geometry
or geometry may do the job of logic, but it is wasteful
not to put each technique to its natural uSe. A ~imple
example will illustrate that sets which are sllnpiy, and
naturally described in terms of logical combiiiliiibhs
of numerically defined constituent sets ~y 00 very
difficult to describe by logic or geometry alone. Con':'
sider the sets of rectangles defined as follows:
Circumference less than 20 units
Area less than 9 units
Area more than 4 units
Vertical side no shorter than 1/2 the horizontal
side
E: Horizontal side no shorter than 1/2 the vertical
side
F: «B"C)v(IY'E»)vA
A:
B:
C:
D:
The set F mErimple enough. Try to describe it by
geometry or logic alone! Figure 2 is a sketch of set F.
c.
A proposed response surface
The idea of the complementary nature of logic and
and geometry is simple enough. Is it possible to quantify
it and illustrate it graphically? Consider the following
proposed axes:
X. Average number of members per component
set
98
Spring Joint Computer Conference, 1969
t
I
\
\
I
i
.a
..
it
a.
j
E
E
't;
.iE
.....
i
.!
..
z· •
10
Length of horizontal side
AVll'lge !IIm"r of .. t.ts per class
Figure 3-8uggestive sketch of proposed response surface
Figure 2-The set F
Y. Average number of component
tern class
Z.
sets
per pat-
Percentage of correct recognitions achieved
If we classify various pattern recognition programs
as (X, Y) points and plot Z(X, Y) for each program,
what sort of graph would result? Obviously one contour
must be Z(O, Y) = Z(X, 0) = O. If we further assume
Z to be continuous and monotonic then contours such
as those of Figure 3 will result. Figure 4, showing the
relative paths of logical and numerical developments
on such a surface; illustrates graphically the relative
performances of logical and numerical methods.
j
i
i
j
i
D
Some optimality criteria
Having divided the pattern recognition methods into
logical and numerical classes, we will find it useful
and interesting to fw"iher subdivide the numerical
class according to the optimality criteria used.
In numerical analysis, if we are trying to obtain the
best fit of a line to a set of points, we generate an error
vector and attempt to minimize some norm of the vector. The P=norm of a vector y = (Yl, Y2 ... ,Yn) given
by:
is the norm most commonly used for this purpose.
Av..... !limber of .. bIets ..... ella
•
Figure 4-8uggestive sketch of various development paths
The values of P commonly used are P = 1, P = 2
and P = 00. For P = 1, we minimize the average
error. For P = 2, we minimize the SlIm. of squares
error. For P = 00- we minimize the maximum error
(Chebyschev criterion).
In pattern recognition we have a very similar situation. For any separating surface we generate a vector
of separation distances and attempt to maximize the
overall separation. In analogy with the one norm, we
may attempt to maximize the average separation; in
Logical and Numerical Aspects of Pattern Recognition and Artificial Intelligence
analogy with the Chebyschev 00 norm, we may attempt
to maximize the minimum separation; or in analogy
with intermediate norms we may similarly choose a
whole spectrum of optimality criteria.
It is instructive to consider the sensitivity and stability of methods employing the two criteria on the extremes of this spectrum. On the one hand, a method to
maximize the minmum separation will seek out the few
"worst-case" points and work on them first. Such a
worst-case method will be a local, differentiative method; it will be very sensitive to local details, but very
prone to over-react to noise. On the other hand, an
average-case method will be a global, integrative method. It will tend to be relatively insensitive to noise, but
also insensitive to local detail.
An example will illustrate this noise and detail sensitivity. Consider the sets and separating plane of Figure
Separating Plane
99
5. The plane satisfies worst-case, average-case and intuitive criteria for a good separating plane.
Consider the sets and planes of Figure 6. Here set A
has been augmented by A2. As long as the minimum
difference between points in Band A2 is larger than the
minimum difference betweenB and AI, A2 will have no
effect on the placement of plane 1, the worst-case plane.
The A2 information is essentially redundant. However,
plane 2, the average-case plane, will move around and
and react to set A2 as set A2 moves. It may even violate
one of the sets. Intuitively we would probably choose
plane 1.
Consider the sets of planes of Figure 7. Here Sets A
and B have been augmented by noise patterns. Since
these noise patterns affect the minimum distance between the sets, the worst-case plane, plane 1, will
react, while the average-case plane, plane· 2, does
not. Here we would probably intuitively choose plane 2.
Again we can tie these items to physiological considerations. Several averaging and differentiating neuronnets have been observed in nature6 •7-particularly in
optic nerves. Apparently their actions are carefully
balanced to insure sharp resolution together with noise
Figure 5-Sets and separating plane
Plane 1 - Worst Case
~~
o
Plane 1 - Worst Case
Figure 6-Multimodal sets and separating planes
Ji'igure 7-8ets and separating planes with noise
100
Spring Joint Computer Conference, 1969
worst-case geometrical methods. Finally, for future development, we have suggested a pattern recognition
model encompassing the capabilities of all these methods.
ACKNOWLEDGMENTS
Figure 8-Proposed pattern recognition structure
(shown for binary tree as an example)
insensitivity. In pattern recognition we will similarly
be forced to achieve a balance in the use of average and
worst-case methods.
Proposed model for future development
From the considerations of this report, it seems clear
that a general pattern recognition device will have to
perform numeric calculations carefully balanced between global integrative techniques and local differencing techniques. The results of these calculations will
then be combined logically to determine the result of the
entire device. It also seems clear that natural nervous
systems will provide an existence proof and guide in the
construction of feasible pattern recognition models.
Figure 8 represents a possible logical-nu..rnerical net.
At each node a numeric calculation is performed and an
exiting branch is chosen. The overall branching network
of nodes provides the logical structure (although a logical tree is shown for simplicity, any complex logical
structure is intended).
SUMMARY
Pascal once said that there are two kinds of mathematical minds-logicians and mathematicians. We have
indicated that there are two kinds of pattern recognition
programs, logical ones and geometrical ones. In this
report we have traced the historical development of
these two distinct approaches. We have related them to
two functIOns of natural nerve nets and to the two
algebras of set theory. By these associations we have
argued for the complementary nature of the roles
played by these two aspects. In addition we have dis..
tinguished and compared the roles of average-case and
Work leading to this report was carried out in the Computer Science Department of the University of Wisconsin and the Recognition Systems Development
Department of IBM Rochester, Minnesota. The author
is indebted to many people for their help and encouragement during this work: Drs. L. Uhr, J. B. Rosen, and
O. L. Mangasarian at the University of Wisconsin for
many stimulating and enlightening discussionS; A.
Hamburgen, D. R. Andrews, P. H. Howard, and M. J.
Kimmel of the Recognition Systems Development
Department at IBM for their continued encouragement
and support; and C. D. Cullum of IBM Yorktown for
his helpful ideas.
REFERENCES
1 J K HAWKINS
Self-organizing systems-A review and commentary
Proc of Institute of Radio Engineers January 1961
2 T H BULLOCK A G HORRIDGE
Structure and function in the nervous systems of invertebrates
W H Freeman and Company N ew York N Y 1965
3 N RASHEVSKY
M athernatical biophysics
University of Chicago Press Chicago III 1938
4 W S McCULLOCH W H PITTS
A logical calculus of the ideas immanent in nervous activity
Bulletin of Mathematics Biophysics Vol 115 1953
5 J Y LETTVIN H R MATURANA
W S McCULLOCH W H PITI'S
What the frog's eye tells the frog's brain
rroc of Institute of Radio Engineers Vol 47
November 1959 1940-1951
6 M VERZEANO K NEGISHI
Neuronal activity in cortical and thalamic networks
J Gen Physiol Vol 43 supply July 1960 177-195
7 S HUNGER
Pattern detection and recogll.ition
Proc of Instittite of Radio Engineers October 1959
8 M KOCHEN
An experimental program for the selection of
disjunctive hypothesis
Proc Western J C C Vol 19 571-578 May 1961
9 M MINSKY
Computation: Finite and infinite machines
Prentice Hall Englewood Cliffs New Jersey 1967
10 D 0 HEBB
Organization of behavior
John Wiley and Sons Inc New York N Y 1949
11 F ROSENBLATT
The perceptron-A theory of statistical separability in
cognitive systems
Cornell Aeronatuical Lab Buffalo New York Report ~o
VG-1l96-Gl January 1958
Logical and Numerical Aspects of Pattern Recognition and Artificial Intelligence
I ~ B WIDRO""
M E HOFF
A.daptive switching circui's
Stanford Electronics Lab Stanford California Technical
Report No 1553-1 June 1960
13 F ROSENBLATT
On the convergence of reinforcenwnt procedures in
simple perceptrons
Cornell Aeronautical Lab Report No VG-1196-G4
February 1960
14 R D JOSEPH
Contributions to perceptrnn theory
Cornell Aeronautical Lab Report No VG-1l96-G7 Buffalo
NY June 1960
15 H D BLOCK
The perceptron: A model for brain functioning-I
Reviews of Modern Physics Vol 34 123-135 January 1962
16 A CHARNES
On some fundamental theorems of perceptron theory and
their geometry
Computer and Information Sciences Spartan Books
Washington D C 1964
17 A B J NOVIKOFF
On convergence proofs for perceptrons
Stanford Research Institute Report Nom 3438(00)
January 1963
18 R C SINGLETON
A test for linear separability as applied to self-organizing
systems-1962
Spartan Books 503-524 Washington D C 1962
19 W C RIDGEWAY
A n adaptive logic system with generalizing properties
Stanford Electronics Lab Technical Report No 1556-1
Stanford University Stanford California April 1962
20 T S MOTZKIN I J SCHOENBERG
The relaxation method for linear inequalities
Canadian Journal of Mathematics Vol 6 No 3 393-404 1954
21 S AGMON
The relaxation. method for linear inequalities
Canadian Journal of Mathematics Vol 6 No 3 383-3921954
22 J B ROSEN
Pattern separation by convex programming
Journal of Mathematical Analysis and Applications
Vol 10 No 1 February 1965
23 0 L MANGASARIAN
Linear and nonlinear separation of patterns by linear
programming
Operations Research Vol 13 Xo 3 May 1965
24 D F SPECHT
Generation of polynomial di.'~cri'l1dno.nt fu.'f!~hons for
pattern recognition
Stanford Electronics Lab Technical Report No 6764-5
Stanford University Stanford California May 1966
101
25 N NILSSON
Learning machines
McGraw-Hill Inc Ne:w York X Y 1965
26 R G CASEY
Linear reduction of di1Jwnsionality in pattern recognition
IBM Research Report R C-1431 Yorktown Heights N Y
March 19 1965
27 G H BALL D J HALL
ISODATA, an iterative method of multivariate analysis and
pattern classification
Proc of International Communications Conference
Philadelphia June 1966
28 0 L MANGASARIAN
M uUi-surface method of pattern separation
(to be published)
29 H L DREYFUS
Alchemy and artificial intelligence
The RAND Corporation Santa Monica California
December 1965
30 A NEWELL H H SIMON
Computer simulation oj human thinking
Science Vol 134 2011-2017 December 22 1961
31 I P PAVLOV
Conditioned reflexes
Oxford University Press New York N Y 1927
32 D A SCHOLL A M UTTLEY
Pattern discrimination and the visual cortex
Nature 387-388 February 28 1953
33 W A CLARK B G FARLEY
Generalizations oj pattern recognition in a
selJ-organizing system
Proc W J C C 86-91 1955
34 S BAKERS
Techniques of adaptive decision tnaking
General Electric Company Electronics Laboratory
Technical Information Series R65ELS-12 Syracuse
New York October 1965
35 G L ~AGY
Prospects in hyperspace: Stale of the art in pattern
recognition
IBM Research Paper RC-I869 IBM Watson Research
Center Yorktown Heights New York June 1967
36 M D CANON C D CULLUM
The determination oj optimum separating hyperplanes I.
A finite step procedure
IBM Research Report RC-2023 IBM Watson Research
Center Yorktown Heights New York June 1967
37 L UHR
Pattern recognition
John \Viley 8,ild SoilS IIle ~ew York l~ Y 1966
38 G S SEBESTYEN
Decision-making processes in pattern recognition
Macmillan Company New York N Y 1962
A model of visual organization
for the game of GO
by ALBERT L. ZOBRIST
University of Wisconsin
Madison. Wisconsin
INTRODUCTION"
No successful GO-playing program has appeared in the
literature, although Remus! used GO as the subject of
a machine learning study, and Thorp and Walden2 have
considered some of its mathematical aspects. Another
auihor 3 considered GO to be. somewhat mysterious,
making it a challenge to those interested in automating
it. Apparently the game was described as being mysterious to indicate that people were able to play it without
knowing how they were able to play so well. More study
of this complex game may reward us with new insight
into human perceptual and problem solving abilities as
well as foster the development of new techniques for
artificial intelligence. This report describes a program
which plays GO. The program uses an information
processing model to produce perceptual features which
are seen by human GO players, and is capable of several
responses to the recognition of significant configurations
of these perceptual features.
A brief description of GO
The rules of GO are deceptively simple. The two
players alternate in placing black and white stones on
+.1-.£11
" ..... v
;n+A...."o
... i-;",n", "'.;
.&..L.... uv.LI.;:n.... '-'u.Lv.l.~ V~
n
U
10
vA
~1J
10
"""~~ Q+"",,,~ ",f +\..." ~,,~~
~lJ 6J.~U..
UUV.l.J.CO V.1 \lJ.J'Ci OQ.111t:;
which are connected by row or column adjacency
fonn a chain. Diagonal adjacency is llot ~yffici~llt to
connect a chain. The empty intersections which are
adjacent to a chain are its breathing spaces. When a
chain has no breathing spaces, it is captured by the
opponent, and the captured men are removed from the
board. A player may place his stones anywhere on the
board with two exceptions: (1) he may not form a chain
with no breathing spaces unless he is capturing, and (2)
he may not capture one stone which has just captured
one of his stones on the previous turn. A player may
choose to pass at any turn. The game is over when both
00101'
of the players pass in sequence. A player's score is the
sum of territories surrounded by his color plus the
number of opponent's stones captured.
Some of the basic consequences of these rules are
illustrated by the right side of Figure 1. White can
always capture the top black chain, but cannot capture
the bottom black chain, if black moves Figure 1 properly.
If black moves at either of T2 or T3 then white cannot
occupy all of the breathing spaces of the black arIllY
without committing self-capture. This is because the
black army would have two separate eyes. The ability to
form two eyes is what determines whether an army is
safe or not. White will score 16 points in the upper right,
and black will score four points in the lower right corner.
If white moves RIO, then black may not respond Rll,
but must move elsewhere on the next turn. This prevents cyclic capture.
The rules scarcely describe how GO is actually played.
Interested readers are advised to seek a demonstration
from someone who plays GO, or to read one of the
OOginner's books. 4 ,1i The situations in the left hand
corners of Figure 1 are representative of real play. Although the stones are not connected into long chains,
they threaten to form chains which will surrQund
+~-!+,,_. ~l,,_~ +\...~ ~,, __ ~~ ~_~
..... ~ ..."'" ",.fl ~\...'"' h"'n ..~
lJCllIIJVI'y
<:IoIVlle
lJllC \JVIllCI.:> <:IollU
V.l
Efficient play· requires that as much territory be
s~~tQhed out with ~ few §to:p.e~ ~ possible. Throu~h."
out the rest of this p~pef' !ilyen aggregat~ 0,1 stq:qes
which threaten to inv9.d.e or surround territory will be
called armie8.
CU5~
UUlV
....~~ .......
The problem of complexity
GO is considered more difficult than chess by many
people who know both games.1i Numerical measures of
the complexity of checkers, chess, and GO tend to SUp'"
port this belief. The number of paths down the move
103
Spring Joint Computer Conference, 1969
104
ABCDEFGHJKLMNOPQRST
19
19
18
17
16
15
14
13
12
II
10
9
8
7
6
5
I I
I I I I I
!
!
!
I
I
I8
I
7
16
15
14
13
I
12
II
10
9
a
7
'-
~
I
i
I
ods which correspond to the development of strategies.
Time will tell whether a successful GO playing program
can be written using such methods.
-
4
4
3
2
3
2
I
I
ABCDEFGHJKLMNOPQRST
Figure }-An illustration of GO
tree has been estimated at 1()40 for checkers6 and 10120
for chess. 7 A rough estimate for the number of paths
down the move tree for GO is 361! or 10761 • By this
reasoning, GO played on a 6 X 6 board would be comparable to checkers in complexity, and GO on a 9 X 9
board would be comparable to chess.
A slightly better extimate of the true complexity of
these games may be obtained. For checkers, suppose
that a choice of three reasonable moves occurs approximately 20 times per game. Then 320 is a crude estimate
of the number of checker games which might occur
in ordinary play. Good chess players usually. consider
less than five move choices, hence 560 estimates the
number of reasonables chess games. A typical GO game
lasts about 300 moves and a choice of 10 reasonable
moves occurs at least 100 times, thus there are at
least 10100 GO games which could occur in hlL.'lln play.
Such calculations, however crude they may be, are
important to anyone interested in the automation of
these games. The complexity of GO may hinder attempts to program it with the methods developed for
chess and checkers. 6 ,7,8,9 The move t.ree for GO is ex':'
ceedingly deep and bushy, hence any form of heuristic
search can explore only a relatively small portion of the
complete tree. An alternative approach might be to
concentrate upon extremely powerful methods of evaluation of the board situation, thus enabling better play
with a more restricted search. Another possibility might
be to have the lookahead be directed. by pruning meth-
The visual natu1'e of GO
The recognition and discrimination of meaningful
perceptual stimuli presupposes the active formation
of stable perceptual elements to be recognized and
discriminated. A person lacking this process would
combine all sorts of stimuli into meaningless groupS.10
The choice of a move in GO usually involves the recognition of configurations which are meaningful to the
player. This raises the question as to whether certain
basic perceptual processes are necessary for the comprehension of a GO board. The following examples
might suggest that the answer is yes.
First, consider the spontaneous grouping of stones of
the same color which occurs during visualization of a
GO board. The stones are organized into distinct
groups, clusters, or armies even though they may be
sparsely scattered about or somewhat intermingled.
Grouping is usually the result of proximity of stones of
the same color or the predominance of stones of one
color in an area, but can be affected by other characteristics of the total board situation. For example, stones
which fall into a line are likely to be grouped. Kohlerll
and others have found grouping to be a basic perceptuai
.phenomenon. Yet the recognition and discrimination
of groups or armies is necessary for competent GO play.
Closely related in grouping is segmentation, which
is also discussed in Kohler. The area subtended by the
board is divided into black and white territories, each
of which maintains its own integrity in the visual field.
These segments are a measure of the territory which is
controlled by either side, hence are an important
factor in the assessment of a GO board.
Another example is the formation of "spheres of
influence" about a stone or group of stones. Influence
is not an inherent property of stones, but appears to be
induced in them by our processess of perception. Yet
they are a crude measure of the potential of a stone or
army of stones for controlling territory on the board.
The spontaneous image' formed by the visualization
of a GO board appears to be a complicated assemblage
of perceptual units and subunits. For example, the
st.ones themselves have their own perceptual identity
while at the same time they are parts of chains or
groups of stones. The phenomena discussed above
show that some of these perceptual processes may be
very important to the ability of GO players to comprehend this complex game.
It is not within the scope of this report to discuss
flLt1:her the psychological nature of these perceptual
Model of Visual Organization for Game of GO
mechanisms, or to speculate upon the physiological
basis for them. Let us adopt the term visual organization
to mean the formation of such stable perceptual elements as have just been discussed, and let the resulting
"mental picture" be called the internal representation.
Given that a player "sees" a fairly stable and uniform internal representation, it follows that familiar
and meaningful configurations may be recognized in
terms of it. The result of visual organization is to
classify a tremendous number of possible board situations into a much smaller number of recognizable or·
familiar board situations. Thus a player can respond to
a board position he has never encountered, because it
has been mapped into a familiar internal representation.
This report will describe a simulation model for
visual organization. It will use transformations which
create information corresponding to the perceptual
features discussed above, storIng them in a computer
internal representation.
A heuristic for visual organization
We now examine the problem of modeling the basic
visual organization of the GO board. A reasonable goal
would be to determine the segmentation of the board,
the domains of influence of the stones, and the armies
of stones, storing that information in a computer
internal representation. Before building the computer
model, it is of interest to consider physical processes
which give some measure of the influence of physical
bodies.
There are many candidates in the physical sciences
for the process we desire. For example, white stones
could be electrons, and black stones could be protons.
Contiguous areas of positive or negative potential
could determine the segmentation of the board, and the
value of the potential would measure the influence of
the stones. Of course, the solution would be discretized
to the points of the GO board, and the potential at an
unoccupied point could determine how well protected
that point is by black or by white.
For another candidate, let the GO board be made
of blotter paper and simultaneously place a drop of
oil under each black stone and a drop of water under
each white stone. Contiguous areas of oil or water would
determine the armies and the segmentation of the
board. Since the oil and water would spread evenly,
the concentration would not indicate the influence
of the stones or even their location.
Other possibilities might involve electrical networks
or heat conduction, etc. These physical models are
considered because they are well defined and easily
calculated, whereas the visual process we are attempting
105
to model is ill defined. Let us consider in more detail
the first two examples given above. In the center of
Figure 1, the electric charge analogy woul~ give the
black stone at J10 some weight to the right of the wall
of white stones, whereas oil from the black stone ~ould
never get past the wall of water spreading from the
\V hite stones. Perceptually speaking, the black stone
has no influence to the right of the white stones. The
oil and water analogy could not differentiate between
the two situations in the right hand corners of Figure 1,
whereas the electric charge analogy would show four
strongly surrounded squares in the lower corner. Thus
the oil and water analogy does not reflect our perception
of this situation. The finite difference method used by
the program was chosen with both of these models in
mind, and has the good features of both.
It is assumed that a game is in progress and the board
position is stored. The position is transferred to a 19X 19
integer matrix by placing 50 for each black stone,
-50 for each white stone, and 0 elsewhere. Then each
point which is positive sends out a + 1 to each of its
four neighors, and each negative point sends out a
-1 to each of its neighbors. These numbers are accumulated as this procedure is repeated four times. Figure 2,
which is taken from the game listed at the end of this
report, illustrates the results of the visual organization
heuristic. The negative integers are indicated by an
underline.
Segmentation can be assessed by determining the
contiguous areas of positive or negative integers. The
dashed lines in Figure 2 indicate the resulting segments.
The stones which lie in a segment may be considered
to be a group or army. The integer values at a point
give a measure of the degree of influence exerted by
the stones nearby. The influence of stones of the same
color may reinforce one another, whereas the fields
from opposing stones seem to repel and cancel one another. Inspection of Figure 2 should convince us that
at least a crude resemblance to perceptual processes
has been obtained. The array of Integers from the
visual organization heuristic contains, at least implicitly, information corresponding to an internal representation. This heuristic, together with a routine which
is capable of creating an explicit computer internal
representation of the resulting information, will be
part of a model of visual organization. The specific
details of the entire GO-playing program will now be
given.
The program
The program is written in ALGOL for the Burroughs
B5500 computer. Interaction is provided by remote
teletypes. Each move requires 5 to 8 seconds of central
Spring Joint Computer Conference, 1969
106
I
ABC 0 E F G HIJ K L M N 0 P
I
19
18
17
16
15
14
13
I9
I8
i7
I6
I5
I4
I3
I
,f--
1'-= "\
_
r ~- ~- ~-
:
!
~ ~. J
J
~-
('J
("r.J
--
I
(' ',J
I
II
10
i
'\
1
!
! ('
\. J
9
8
'\:
I
1. ~- -h
6
I
I
!
5
4
..~
,r: ~-J;;I I
~-.
J
~r 1--
h
"t\ r
i
10
9
! r. J
8
! i
7
I ,,~- ~-~
6
I
5
-.~-
,
"'~- F--
rho'
I ,!
3
2
'-=
Part I
2
-~,
;
Part I realizes a model of visual organization for
GO, producing an analogue of a human player's perception of the board. Part II is not an attempt at simulation, but a coliection of heuristics which mayor may
not resemble cognitive processes,
Q R S T
J
4
3
2
I
I
ABCOEFGHJKLMNOPQRST
~ ~ ~ £ 2 ~
~ ~ 12 11 11
l 2.lSl ~ !Q 21
l ~ 1Q 2 0 4,6
Z ~ ~ 0 ? 56 ?
~ ki 2 3 6 1 22
o
1 7 1 6 5 5 5 7 10 59 12 57
~ 50 12 10 10 9 9 10 62 16 63 61
22 !!:£ 56 13 62 12 11 12 14 63 14 11
57 56 64 12 12 12 62 13 64 64 14 59
6 6 5 8 9 9 11 12 63 15 13 10
~ 21 1 3 6 8 8 11 14 64 63 11
Z i 1. 7 54 52 14 U 11. .l 4 10 8 10 12 63 65 16 59
& 0 ,11 6 ~ U 62!Q ~ 7 58 5 12 63 16 65 56 4
1 4 10 62 6 ~ 11lQ Z 1 2 0!!:Z 49 66 57 50 .5Q ~
2 5 9 12 1 ~ lQ 2 £ 1 ~ Z g 48 42 42 .5Q Q.5. 12
1 4 8 12 54 22 11. 11 ~ £ ~ lQ g 14 ~ 50 42 51. 60
2 5 9 11 5 ~ U 62!Q ~ 10 62 12 g .a 51 ~ 1.l 11
1 3 7 61 4 ~ 12 lQ ~ Z ~ lQ 11 11 52 50 .51UZ .51
l J tr 8 3 ~ 11. lQ..1. j, §. ~ 1Q 1.1 ~.57 58 57 53
So 11 II 54 1 ~ g 10 ~ Z Z 2. lQ 62 Z 2 58 1 4
!l
.§. 4 1 11 1.£ lQ lQ lQ ~ ~ ~ lQ 12 .l §..5.l 1
1 !
This part of the program consists of a set of computations which transform the board position into a
computer internal representation. The internal representation contains an analog of important perceptual
features of the board position. This information is
stored in seven 19X 19 integer arrays in an explicit
fashion. That is, the integer values are a direct measure of the features they represent.
For example, consider the features of perceptual
grouping and segmentation which have been determined by the visual organization heuristic. It would
not be easy to reference this information in the array
shown in Figure 2. Another process must create an
array which gives a direct measure of the size of the
segments and the groups of stones.
Figure 3 illustrates the results of the processes which
sz.
r"
i
--- --
~-
I
I
--_. -- -~
-~--
•~:
I
a
~~2~.l62112lQ6210§.§.~106211111
ZU
! 2
u. .s& §J 1&
~ 2
2 1
~ §. ~ lQ ~
!t:
1
!t:
.l
!t:
!t:
1.J± ~ 10 2 Z
~ Q ~ ~ .l .l
603
603
603
603
603
603 I
i
!t:
1 ~
Figure 2-Results of the visual organization heuristic
prooessor time or about 5 to 20 seconds of real time,
depending upon the number of users being serviced by
the system. The machine code occupies 6300 words
of core memory and 5400 more words are required for
storage arrays. The program has two distinct parts.
Part I has a coordinated set of procedures, including
the visual organization heuristic, which operate on the
board position to produce a computer internal representation. Part II has a set of procedures which use
the internal representation to calculate a move.
603
603
603
704
704
704
r------------704
704
704
I
I
603
603
603 JI
____________
704
704
704
704
704
704
704
704
704
704
704
704-
501
501
704
704
704
704
I 704
704
704
704
---------,
501
501
I
I
I
I
Figure a-Internal representation of grouping and segmentation
Model of Visual Organization for Game of GO
calculate perceptual grouping and segmentation. These
processes act upon the array of integers produced
by the visual organization heuristic to produce an array
of integers which are a part of the internal representation. One of these numbers (e.g., 603) may De interpreted as follows: the hundreds indicate the size of
the segment which covers that point (600 is a mediumsized segment) and the ones indicate the number of
stones which lie in that segment (there are 03 black
stones hence 600 + 03 = 603). 500 indicates a small
segment with less than 10 empty intersections, and
700 indicates a large segment with more than 25 empty
intersections. If no segment covers an intersection,
then 0 is stored in the corresponding cell of the array.
The empty intersections in a segment are counted as
they are a better measure of the safety of the army
of stones in a segment. The information is compressed
by having the size and the number of stones in the
same array for purposes of efficiency only.
The array shown in Figure 3 is typical of the seven
arrays which constitute the computer internal representation. Numerical values correspond in an explicit
fashion to feature which we have considered to be
formed by visual organization.
The second array gives a numerical measure of the
influence of the black and white stones. It is an exact
copy of the array of integers shown in Figure 2.
The third array measures the number of breathing
spaces in a chain. This array is illustrated in Figure 4.
The fourth array measures the number of stones in
a chain. This array is calculated in the same fashion
as the third array.
The other three arrays of the internal representation
contain integers which indicate the color of stones,
the color of segments, and the number of stones of
each color which are adjacent or diagonal to the points
of the board.
Part II
The second part of the program uses the recognition
of "familiar" configurations in the computer internal
representation as the basis of its calculations. The
mechanics of this recognition process will be described
first.
Figure 5 illustrates a configuration which the program is able to recognize. At point A, there is a black
stone which has only one breathing space left. Point
B is an empty intersection. Point C has a black stone
which may be part of a safe army of men. Note that
the geometric arrangement of this 3-tuple is as important as the three features. The program contains
a prototype of this configuration which we shall call
a template.
107
'"
,,,
"
o
"
"
o o
o
o
o o
o
o
o
o
o
2
5
5
o
6
I
o
o
o
6
6
o
o
o
o o
o
o
Figure 4-Intemal r'epre..<;entation of hreathing spaces
108
Spring Joint Computer Conference, 1969
I
I
1'1"\
... ~
'101'
I"!I.
"-
I
I
.....
""A
I
"""c
..oil
'II
B
f
I
Figure 5-Illustration of a :,;ignificant configuration
A template consists of an n-tuple of references to the
internal representation together with a specification
of the geometric arrangment of the elements of the
n-tuple. Thus the template for our situation ABC is:
(0,0)
(1,0)
(1,1)
black stone, 1 breathing space
empty intersection
safe black stone.
The pairs of numbers are the relative coordinates of
the references. The references themselves must be
translated into a numerical form which can be used
to process the internal representation, for example:
safe black stone = 601 thru 900 in array 1 and
1 thru 1 in array 7.
That is, a point satisfies the reference "safe black
stone" if the value of that point in array 1 of the internal representation lies between 601 and 900 inclusive
and the value in array seven equals 1. A 1 in array seven
tells us that we have a black stone on that point, and
a 601 to 900 tells us that we have at least a mediumsized segment.
The program has the ability to scan such templates
to all positions, all rotations, and all reflections of the
board, thus recognizing the configuration- ABC wherever it occurs. If the template is carefully specified, then
configuration ABC can be quite a general occurrence.
For example, Point A could be connected to a chain
of stones with 1 breathing space left. Allowing this
would give the template more generality.
The present program has 8;) templates capable of
recognizing a wide variety of configurations. A template
that matches implies either a move or a heuristic
lookahead procedure. In fact, there are two types of
templates for these two purposes.
The first type of template specifies a weight of implication and a pair of relative coordinates for the
move which is implied. For example, the template for
configuration ABC described above would specify
(1,0)
500
which means that a weight of 500 is assigned to the
point B in Figure 5. These weights are stored in a
special 19 X 19 array reserved for this purpose. Several
templates may imply the same move in which case
the weights are summed in this array. The highest
sum of weights indicated the best move. Bad moves
and illegal moves usually have a negative weight.
One more example of this type of template will be
given:
(0,0)
(1,0)
(0,0)
white segment
black segment
weight 40.
This template implies a move with weight 40 at the
interface between opposing segments. A weight of 40
is relatively small, hence it will merely give a tendency
towards moving in these areas. This template is very
general; it can match as many as 100 times in a single
scan of the board. It gives a slight tendency to move
between opposing armies which. helps the program's
play.
There are 65 templates which imply moves in the
manner just described, the other 20 templates imply
a heuristic lookahead. The difference between these
two types of templates is that instead of a weight
being placed in the weight array, an x is-placed in a
19 X 19 array as an indication of the template match.
The x's are a mark to indicate that a move tree search
should be performed in the local area about the x. All
of the templates are applied before the search is begun.
Figure 6 illustrates a configuration which would be
matched by some of the 20 templates, and the location
of the x's placed by those templates.
The array which contains the x's is used as a mask
to determine the extent of the search and the depth
is fixed at two moves for each side. The search is actually
performed twice, once for ·white moving first, and once
for black moving first. At the end of these searches,
it is noted whether either side can force a capture by
moving first. This information tells the program whether a move is necessary to cause or avoid a capture.
Model of Visual Organization for Game of GO
,~
,
'4
I't\
....
I't\
"
,"
"I'
'"
,II
.... ,
ji'
.......
1"
....
,~
.. II.
...
I't\
....
109
,~
~,
"'~
'1'
'\11
jl'
"
"
"
"
J"''''
~~
"
~.,
J""
J"'''-
"
,~
i'"
"
1"
....
Figure 6-Creation of a mask for lookahead
For example, if black can capture whether he moves
first or not, then it is unnecessary for him to move.
The decision to move is recorded by placing a weight
of 4000 in the array already discussed in connection
with the first type of template.
In many cases a depth of two moves is not sufficient
to determine whether capture takes place or not. The
most common instance of this is known as the "ladder
attack" which is illustrated in Figure 7. These situations are characterized by the repeated occurrence
of moves which force the opponent to reply or to be captured. In such cases, the search procedure continues
to a depth of up to 100 moves to see whether capture
finally takes place. No branching takes place during
this extension of the look ahead.
When all of the templates have been applied and
the heuristic search procedure is through, the program
simply chooses the move which corresponds to the
highest sum of weights in the array of weights. If the
maximum weight is below 100 then the program passes.
This completes the description of the program except
for a few minor details of operation. Three seconds
are used for the creation of the internal representation
and two seconds are used by the template matching
procedure. The heuristic search takes from .1 to 4
seconds. A challenger has the option of moving first
or second, and can also give the program a handicap
of any number of stones on the board. The program
is not able to haggle over the final score as GO players
Figure 7-Illustration of the "ladder attack"
often do, hence a referee may be required to supervise
the scoring.
RESULTS
The program now has a record of two wins and two
losses against human opponents. The opponents can
best be described as intelligent adults who know how
to play GO, have played from two to twenty games
but have not studied the game. The program appears
to have reached the bottom rung of the ladder of human
GO players. Interested readers are urged to get a GO
110
Spring Joint Computer Conference, 1969
board and play through the game listed at the end of
this report.
The first type of template, those which imply moves,
are responsible for about 80 percent of the moves made
by the program. These templates give the program fairly
good positional play, especially in the first part of the
game.
The remaining templates, together with the lookahead search, are valuable for avoidance of traps which
cause the loss of a stone or two. The opponent's play
is also restricted since he must play more carefully.
The loss of one stone can have a great effect upon the
outcome of the game. The program is able to play
without these templates, hence without the search,
but opponents soon learn to take advantage of this
weakness.
The program plays as if it can "see" such things as
the influence of stones, the segmentation of the board,
and the armies of black and white' stones. This alone
makes it a reasonable candidate as a model of visual
organization for the game of GO. It would be of interest
to test the model by performing standard psychological
experiments. For example, a drawing of a GO board
could be shown to a human subject with the instructions to segment the board with dashed lines. The
results could be compared with the segmentation given
by the program. Further work may show how i...llportant perceptual mechanisms are to the ability of humans
to play GO.
APPENDIX: A GAME BETWEEN THE
PROGRAM AND MR G. COWAN
The following game, played between the program and
lVIr. George Cowan, demonstrates that the program
has reached at least the bottom rung of the ladder of
human GO players. Mr. Cowan is an undergraduate
at the University of Wisconsin, and had five games
experience at the time of the contest. The even-numbered moves are by the program (white). Moves which
resulted in a capture are indicated by asterisks. The
comments are by Professor Paul Purdom, a good GO
player, who has shown patient interest in the various
GO-playing efforts at Wisconsin.
1.
D 3
Q3
3.
E 9
D17
5.
Q16
H12
too early for such a move
7.
F15
R15
too close to opponent
016
M 8
9.
11.
R14
H 8
shouldn't give up the corner
13.
lVI12
C 5
D5
F12
15.
D 7
17.
J17
still important moves rernail1il1g in the corner
19.
M17
R 8
21.
R 5
S 4
23.
Dll
K 3
25.
Q11
G 5
27.
Q15
F 6
29.
K16
F17
31.
G16
G17
33.
H16
F 3
35.
E13
E 2
still ignoring upper left side
37.
Q 7
F 8
wasted move
S 7
J18
39.
Q
8
o
5
41.
R9
P
6
43.
R 7
8 8
45.
R6
8
9
47.
T8
T
9
49.
T
7*
810
51.
T10
RIO
53.
811
Q9
55.
TIl
*
Rll
57.
812
08
59.
8 6
P 7
61.
P
9
T6
63.
Q6
Q10
65.
P10
810
67.
a free gift from black
011
Q12
69.
R13
010
71.
PH
NH
73.
N10 a better move
R12
H17
75.
D2
J16
77.
P12
B 3
79.
B14
Q13*
81.
at last! C14 better
817
K17
83.
815
R16
85.
seems to ignore sacrifices
816
814
87.
R18
R17
89.
F 9
Q18
91.
819
818
93.
T17
R19*
95.
T14
T19*
97.
both players wasting moves
FI3
T13
99.
T15*
T16
101.
Model of Visual Organization for Game of GO
T18
103.
GI4
T16*
105.
JI4
JIO
107.
JII
J12
109.
K12
Kl1 better
N10
J13*
111.
wasted
o 9*
P 8
113.
K9
L14
115.
M14
L13
117.
M13 better
KI5
K9
119.
L15
MIO
121.
Mll
Lll
123.
N12*
N13
125.
Q 5
MI3
127.
M15
129.
013
N7
131.
N6
should connect N8 and cut stone
o7
133.
P 5
P14
Q4
135.
137.
LIO
M9
L9
KIO
139.
141.
L 8
L 7
143.
K8
J 8
145.
L12
K 7*
KI4
147.
E 5
149.
K13
H10
wasted
151.
N14
P13
153.
F16
E16
155.
E15
D15
157.
C16
C15
159.
E18
E 7
161.
E17
D18
163.
D16*
C17
165.
B17
CI8
167.
B18
FI8
169.
EI9
H18
171.
K18
GI9
173.
J19
FI9
the program would be much better if it could recognize
eye possibilities
175.
EI6
B19
177.
B16
H15
179.
E12
Fll
181.
EI4
B 7
183.
B 8
C 8
185.
B 9
R4
187.
C 9
S 5
189.
A 7
T 5*
191.
B 6
D6
193.
D 4
D8
C 7*
B 7
D9
EI0
Ell
FlO
G15
J15
F14
L 4
L 3
K2
M2
M4
L 2
K5
M 1
J 1
J 2
195.
197.
199.
201.
203.
205.
207.
209.
211.
213.
215.
217.
219.
221.
223.
225.
227.
229.
231.
111
C 6
E8
C 4
B 5
E 4
GI0
G9
H14
012
L 5
K4
M3
N3
N4
N2
J 5
K 6*
H2
J 3
It was agreed to stop the game at this point. The
resulting score was: Mr. Cowan ... 59, program ... 66,
a seven point victory for the program. Approximately
15 minutes of computer time was used, and the entire
contest took less than two hours of real time.
)
ACKNOWLEDGMENTS
This research was conducted with the support of NIH
grant MH 12266 and NSF grant GP 7069.
BIBLIOGRAPHY
1 H REMUS
Simulation of a learning machine for playing GO
Proc IFIP Congress 1962
2 E THORPE W WALDEN
A partial analysis of GO
The Computer Journal Yol 7 No 3 1964
3 I GOOD
The mystery of GO
New Scientist January 21 1965427
4 0 KORSCHELT ,
The t~ry and practice of GO
Tuttle Rutland Yt 1966
5 E LASKER
GO and GO-MOKO, the oriental board games
Dover New York 1960
6 A SAMUEL
Some studies of machine learning using the game of checkers
IBM Journal of Research and Development Vol 3 No 3
1959
7 A NEWELL
The chess machine
Proc Western J C C 1955
8 C SHANNON
Programming a digital computer for playing chess
112
Spring Joint Computer Conference, 1969
Philosophy Magazine March 1950
9 R GREENBLATT D EASTLAKE III
S CROCKER
The Greenblatt chess program
Proc F J C C 1967
10 P GREENE
Networks which realize a model for information
representation
Transactions of the University of Illinois Symposium on
Self-Organization 1961
11 W KOHLER
Gestalt psychology
Liveright New York 1947
Assembly of computers to command
and control a robot *
by LOUIS L. SUTRO
Massachusetts Institute of Technology
Cambridge, Massachusetts
and
WILLIAIH L. KIL:JJIER
Michigan State University
East Lansing, Michigan
INTRODUCTION
There is a growing consensus among predictors of
science that the world is about to witness the evolution
of 'what might be called a new species-the robot.
Whereas, animal evolution was a trial-and-error process,
robot evolution appears likely to be carefully contrived. Starting where animal evolution left off,
that is, with man, robot evolution promises to excel
man is some respects, and be excelled by him in
others.
To the computer profession, one challenge in this
progression is to develop computers for robots that
match those that have been found indispensable in
men. We are aided in this task by the description of
the human nervous system in computer terms by
physiologists such as Warren JicCulloch.
With his description before us, we have devised
working models of t\VO of the five principal computational domains which he identifies in the nervous
system of vertebrates, including man. Others are
devising working models of other domains. Implemented
in light, portable hardware and connected together,
these computers promise to provide intelligence for
a system that will sense its environment, move about
and perfonn useful tasks.
* The work reported here was supported in part by NASA
Office of Space Sciences and Applications, Bioscience Programs,
under Contract XSR 22-009-138, in part by XASA Electronic
R~arch Center under Grant NGR 22-009-140, in part by
AIr Force Office of Scientific Research under Grant AF-AFOSR1023-66, and in part by the U. S. Air Force, Wright-Patterson
B~se, through contract AF 33(615)-3885.
Who needs a robot? Everyone who would like help
with tiring chores. However, early models with large
arms and wide wheelbases cannot move around the
home or office. One need that has led to the development about to be described is exploration of the planet
lVlars. For this task, robot development is being pursued
not as an end in itself but as a framework within
which to develop an automatic visual subsystem.
A second need is for a computer to command a system
receiving several forms of input, such as sight, sound,
touch, and reports on its own movements. Here again
robot development provides the framework for the
computer development.
As well as can be detennined, l the surface of ~fars
is open country where a wide-wheelbase vehicle should
be at home. ::Hore to the point, the only exploration
there for a decade or more will have to be either by
a remote-controlled or an automatic vehicle. The
distance is such that a single bit of infonnatioll requires V5 minutes, on the average, for transmission
from Jlars to earth. '¥ith such a transmission delay,
remote control seems hardly practical. An automatic
vehicle or robot thus seems imperative.
While the surface of Jlars is colder than the surface
of the earth, there may be hot spots due to volcanic
or other sub-surface activity. All the moisture on
lVIars, according to our instruments, is in the form
of either gas or ice. The atmospheric pressure is too
low to hold it as water, but it might pass through the
water phase in these hot spots, lasting as water long
enough to make possible life as we know it. 2
To go to these hot spots, if indeed they exist, poke
113---------------------------------
114
Spring Joint Computer Conference, 1969
around them, pick up and examine samples seems
the best way of finding out what is there. Even if
there is no life on lVI ars , there are cliffs formed at
the edges of craters, that need to be examined for
their geology. The craters need to be climbed into
and out of. To go from one crater to another, crossing
must be made of the ravines called "canals".
Research and development
The robot design described here began as an effort
to design eyes for the artificial intelligence that Marvin
l\1insky and John McCarthy called our attention to, in
the fall of 1958. Persuaded that eyes for artificial intelligence could be achieved only by employing ideas
from anin.lal vision, one of us (Sutro) approached Dr.
lVlcCulloch for advice. The collaboration that ensued
led first to an analytical model of an animal retina that
recognizes objects, namely, the retina of a frog. 3 •4 It
led next to a proposal to NASA to develop means of
reducing, for transmission to earth, pictorial data
acquired in the search for evidence of both life and
geological changes on lVIars. Supported then by the
NASA Bioscience Programs, we undertook this in the
maIUler Dr. IHcCulloch and we thought best, namely,
to model animal vision in lightweight, low-power
hardware. Study of frog vision showed how recognition
of a simple shape (a bug) can be achieved in two levels
of computation, but it did not carry far enough the
data reduction we felt was required. ~ eeded, we felt,
was reduction of a stereo pair of im~ges on :Vlars
to a pair of line drawings with shading, as we primates
do. Geologists and biologists make line drawings with
shading to represent what they see. The lines portray
edges, angles and silhouettes. The shading conveys
the brightness of surfaces.
IVIan forms in his head a model of what he observes.
Formation of a line drawing with shadings is a stage
in the computation of this model. However, as Dr.
McCulloch points out, the vision of a primate cannot
be modeled by itself. Data flows not only inward from
the images, but outward from the brain to adjust
the filters, focus, convergence and direction of gaze
that select what will flow inward. For a visual system
employed in a single position on l\iars, these adjustments can be either preset or changed by commands
from earth, but when the system is required to move
about, the commands to adjust it can scarcely be
sent from earth. They have to be generated on site.
To develop a command computer one of us (Kilmer)
undertook to model the part of the vertebrate brain
that decides from information received through all
the senses what class of thing the animal will do from
moment to moment. This is the core of the animal's
reticular formation, extending through its brain stem
and the length of its spinal cord. Support for its development came first and continues from the Air Force
Office of Scientific Research, came then from NASA's
Electronic Research Center, and comes now from the
U.S. Air Force bionics programs.
Cameras and computers under development are
pictured in Figure 1. At the left is a binocular pair
of TV cameras of which sufficient study has been made
to indicate that each camera can be built to view the
world through both wide-and narrow-angle lenses.
Receiving the output of the camera is the visual
first stage computer which enhances contrast in an
image, as an animal retina does. Next to it are switching
filtering and comparison structures, we call the visual
second stage computers. A model of the environment
consists of relations formed in this second-stage
visual computer and stored in the visual part of the
relational computer. A line, which indicates sharp
change in luminance, is a relation of high spatial
frequencies. Shading, which indicates the difference in
luminance of areas, is a relation of low spatial frequencies. Each filter passes one band of frequencies
more than others. Commands to adjp.st filters, focus
and direction of gaze are shown a.8 arrows rising from
the command computer in Figure 1. Since these
commands '\-vill pass through structures not shown,
the arrows are not drawn directly to the cameras and
visual computers.
Note the dashed boxes. The present locator of
edges and shades, represented by a solid box, forms
a stereo pair of monocular line drawings. The dashed
box marked "binocular" represents computation now
op~rating separately to determine that pairs of points
in the left and right views are stereoscopic (stereo),
that is, representative of the same point in threedimensional space. Binocular, or range-finding, computation will be merged with the locator of edges and
shades.
At first, we called a vehicle designed to carry this
system "rover". As we came to conceive of it with
other senses, beside vision, and other effectors, beside
wheels, we renamed it "robot."
Biological computers
From his life-long study of the human nervous
system,S Dr. Warren McCulloch has concluded that
the essential features of its computations provide a
good basis for the design of a robot. Although as a
neurologist, psychologist and physiologist, he is
aware of the difficulties involved in embodying mental
functions in physical devices, he has nevert.heless
developed a simplified model of a vertebrate braL.'1.
Assembly of Computers to Command and Control a Robot
115
N contrast between adjoining
luminances, the filter will make the dark side of an
edge darker and the light side lighter, thus forming
Mach bands along the edges of the stone, the stick,
the hills and the crater.
The vertical lines in the displays of FigUle .5 are
due to the method by which the computer of Figure 7
acquired pictorial data. As the electron beam of the
camera scans each horizontal line of the raster, the
computer commands the reading of one luminance
** A stereoscope for viewing this illustration may be obtained
from Air Photo Supply, Yonkers, X.Y.
Assembly of Computers to Command and Control a Robot
121
Figure 5--Left-eye-view scope displays at level 1 (left) and level 4 (right) in the computation of the line drawings of
Figure 6
Figure 6-Line drawings formed at leveI7:Fine-lineleft-eye-view (left), coarse-line stereo pair (right). To see in stereo, look
through a stereoscope at the crater, glancing nearer occasionally at the edges of the rocks and hills
measurement. 10 Since the computer employs the same
conunand as long as it can, successive measurements
are on vertical lines. The unevermess in the spacing
of the lines is due .~ 0 nonlinearity in decoders of the
display.
Figure 6 (left) is the result of applying, at levels
5 and 6, an edge-detecting filter and· threshold, that
represent Hteep changes (gradient) in luminance by a
fine line. Figure 6 (right) is the result of applying a filter
and threshold that represent such changes by a wider
and, in this case, more continuous, line. 1t it; thus
possible to pick different features from a scene by
employing at level 5, different edge-detecting filters
and, at level 6, different thresholds. The filters employed
at level 5, in producing these illustrations, detected
the horizontality and verticality of edges separately,
but this information 'was not kept separate in making
the line drawings. For details see Appendix A.
When contrast is high in the scene, as in Figure
8 (left), first stage visual computation can be skipped.
Figure 8 (left) is a photograph of the TV monitor
(not the oscilloscope display as in Figure 5,· left)
when the scene was lighted from the back left, creating
higher contrast than was the case for Figure 5 (left).
Levels of computation 2 and 3 were omitted and a.
narrow-edge detecting filter was employed at level 5.
Thus, both contrast enhancement and. feature deteetiOIl can be va.ried, not only for the entire image, but
for each matrix within the image, under control of
either a remote human operator or a local conunand
computer. This position-by-positioll control of the
processing of the image, represented by the leftward
122
Spring Joint Computer Conference, 1969
LONG-PERS ISTENCE"-'
DISPLAY
t;~~
:
GRAY-SCALE
i'e
')!
Figure 7-Equipment for simulating light-weight, low-power hardware; (above) Camera-computer chain for simulating
visual computers, (below) binocular, or stereo, TV camera
arrows in Figure 1, separates our work from that at
JPL. It makes perception possible.
Line drawings, such as those in Figures 5, 6 and 8,
do not convey enough information for a scientist on
earth to judge what is being pictured. However, by
the addition of low-resolution luminance data to left
and right views, and presentation of the two views
stereoscopically, there may be enough information.
Figure 10 is an example of levels 5 and 6 COhlputation
alone on data received from the scene pictured in
Assembly of Computers to Command and Control a Robot
-
123
I
---f----~--~--~--~r-~--~
I
~----~---+--~~--~-
Figure 8-Formation of line drawing by levels 6 and 7
computation alone. Left-eye views of (left) image on TV
monitor before being digitized, and (right) negative of
scope display at level 8
Figure ll-Grid of scene luminance values superimposed on
Figure 10
Figure 9-Photograph of scene to be formed into line drawing
with shading
•
Figure 12-Painting "rith shades of gray prescribed by lines and
values of Figure 11
Figure 1(1--Computer-generated line representation of scene
Figure 9. Figure 11 shows coarse-resolution measurements of luminance on a scale from 0 to 7, which an
artist employed to paint in the swatches of gray in
Figure 12. When this reconstruction is perfonned by
computer, it will illustrate how the appearance of
a Martian scene can be reduced for transmission from
Mars to earth and then reconstructed on earth for
viewing there. The data reduction here is by a factor
of 30.
The stereo pair of views, shown being reduced in
Figures 5 and 6, was not taken with the mirrors illustrated in Figure 7 but by taking one at a time, moving
the camera between takes. This is simpler for a report.
Hardware version of t'isual first-stage computer
We designed the computation first so that it could
be implemented in light portable hardware; then we
124
Spring Joint Computer Conference, 1969
simulated this hardware in the computer of Figure 7
and achieved the results described above. The hardware
design, diagrammed in Figure 13, is inspired by the
layered structure of the animal retina and laterial
geniculate body of the thalamus. Since it is not practical
to represent in hardware the large number of cells of
these animal structures, only a cluster of cells of each
layer is represented and data are moved past the cluster
by shift registers.
A camera containing a single vidicon, that receives
left and right views from mirrors, is shown in preference
to two cameras because the fonner arrangement
ieads to much less uncertainty between the two optical
paths. 10
Ia Figure 13, left and right images of an object
such as a rock are projected by the optics onto the
face of the vidicon. Converted to digital fonn, the
signals enter shift registers (1) which move the images
past computing elements (2) and (3), which represent
clusters of living cells. The filter planned for level
2 is shown schematically at the upper left of Figure
13 and is given in detail in Appendix A. It consists
of a central weight strongly positive, immediately
peripheral negative weights and more peripheral
weakly positive weights.
The images are advanced from left to right in the
shift registers at the same rate that the tip of the
electron beam in the vidicon advances. As data reach
the right end of the top row, they are transferred to
the left end of the next lower row. In this illustration,
Figure 13-Diagram of hardware to perform contrast
enhancement
when the electron beam of the camera tube has swept
13 lines of the raster, the shift registers in the bank
are full. From then on, for each new position of the
electron beam, computations take pl91ce in the box
behind the shift registers, and one digital word is
discarded from the right end of the 13th row of shift
registers.
Figure 14 shows test hardware under construction
to perform levels 1, 2 and 3 computation, on five lines
of the raster. Each of the lower five panels contains
a shift register 6-bits deep. The registers shift the
data past the computing element in the top panel.
The medium-scale integrated circuits to be employed
here, together with their wiring, can be packed into
about 50 cu. in. With large-scale integrated circuits
the volulne could be lOcu. in. lO
Computation of range
To perform second-stage computation, either a
man or a robot needs a view from a second position.
We refer to the two views as "left" and "right" since
they are usually taken from the same horizontal
baseline. If the levels of robot computation pictured in
Figure 4 are for the left view, then either a second
series of levels is needed for the right view or the
levels need to be widened to accommodate both views.
We have taken the latter approach in the design of the
hardware.
Animals compute range from comparisons of left
and right images, at several levels of computation,
and from the angle between the axes of the two eyes,
Figure 14-Visual first-stage computer under construction. The
top panel is the computing element. The other five are
shift registers. Integrated circuits piug into the far side
Assembly of Computers to Command and Control a Robot
125
SUMS OF DIFFERENCES ARE STOIED
FOR WIDTH OF LIKfLY AREA;
SUM OF THE DIFFERENCES
BETWEEN CORRESPONDING
RESOLUTION ELEMENTS.
MTH EACH SUM OF DIFFERENCES ARE
STORED THE ADDRESSES ~ WINDOWS,
WttCH ARE EMPlOYED N cnwUTlNG RANGE.
MEASUREMENTS OF
LUMINANCES IN A
SCENE.
Figure I5-Comparison of left and right views to determine range
called the "convergence angle.' '11 The equipment
shown in Figure 7 has been programmed to automatically compute range by comparing areas, in the left
and right level 2 images, called "windows" (see Figure
15), To find a pair of windows that are vi~\ving the
same object, a window is first fixed on say, the left
view, according to some criterion such as the presence
of an edge; then a likely area is located in the other
view. Since this area contains as many potential
windows as resolution elements along the horizontal
axis, the problem is to determine which of these
windows corresponds to the one fixed in the left view.
The simplest way is to compare luminances in the
fixed window with corresponding luminances in the
likely area, determine the difference and use this as a
criterion to decide when a best match is obtained.
From the data of the best match, range is computed
by triangulation.
Employing this method, equipment shown in
Figure 7 automatically explores a likely area to determine the range of an object at 20 feet with an uncertainty
of 1.5 percent. To perform the comparison over
the entire likely area requires 16 seconds. The comparison will be performed over less area if the robot visually
follows around the edge of an object or visually explores
increasingly deep into the scene. In these latter
cases, the visual subsystem of the robot starts with
a known range and reaches out from it.
Perception
In the robot we plan, the command computer,
assisted by t~e relational computer, will determine
what is seen ,by setting filters and thresholds in all
stages of visual computation so as to match an iternallygenerated image with an incoming one. This "Keeping
up to date the internal organizing system, that represents the external world, by an internal matching
response to the current impact of the world upon the
receptive system" is. called "perception. m2 "In a sense,
the internal organizing system is continually making
fast-time predictions on what is going on out there and
what is likely to happen out there, and it takes anticipatory action to counter the small errors that might
threaten its overall stability."
A line drawing with shading, transmitted to earth
for a scientist to view, aids his perceptual process,
giving him clues about the presence of objects about
which he can then demand more information. Within
a robot, however, a line drawing with shading will
be the result of interaction between the relational
computer, setting filters and thresholds, and the
second stage visual computer where these filters and
thresholds are tried on incoming data. When equpiped
to perceive, a robot will make fast-time predictions,
possibly as detailed as the computer-generated image
of Figure 16. Our general purpose computer formed
Figure 16 from the equation of a cylinder, its diameter,
height and illumination. It appears that perception of
the cylinder could take place in the first and second
stages of visual computation if the filters there are
continually changed, as data are shifted past them,
to search for predicted luminances in each part of
an internally-generated image. 13
126
Spring Joint Computer Conference, 1969
Figure 16--Picture generated by computer preparatory to
experiments in perception
The concept of a command computer
The purpose of a command computer, in an animal
or robot, is to commit the entire system to one of
a dozen or so mutally exclusive modes of behavior.
An anim3J requires such a computer because it cannot
" fight," go to sleep, run a way, and make love all
at once. "14
Our study of a possible Mars robot indicates that it,
too, can only enjoy one mode of behavior at a time.
Possible modes of such a robot are:
1. Look and feel
2. Advance
3. Retr-eat
4. Right itself if overturned
5. Maintain itself
6. Chart its environment
7. Rest
Perform incompatible experiments as follows:
8 Experiment A
9. Experiment B
10. Experiment C
"Look and feel" is a separate mode from "advance"
because the robot must be stationary while either its
camera or its arm is employed.
By "chart its environment" we mean that the
robot, after advancing (or retreating) an appropriate
distance, will establish what a surveyor calls a "station," and mark it with a transponder. Having determined the distance from the previous station and
measured the angle between this and the second
previous station, the robot can form a triangle in its
memory to add to other triangles previously formed.
By building triangle upon triangle, the robot establishes
a grid with which it can determip.e how far it has
gone and in what direction. Through this grid it
can later pass, to return to points it has already visited.
Within each mode are the detaHed sequences we
call acts. Advance, for example, can be either slow,
fast, or by turning. These details can be developed
after the command computer has been designed to
choose among the above modes.
The command computer should be capable not only
of selecting the mode of behavior, in response to
inputs from the environment, and the other computers,
but of changing the way it responds to those inputs.
Ability to change the record of conditions under which
it selects a mode is called "plasticity" and is exemplified
by conditioning and habituation.
The first simulation of a command computer represented only its mode-selecting ability. It was called
S-RETIC where S stood for its ability to respond to
both its present internal state and its spatially structured input. IS The second simulation is called STCRETIC where T stands for its ability to be influenced
by temporal aspects of the environment and C for
conditioning and habituation. The properties of STCRETIC together ,vith several new features are now
being designed into special hardware to be called
H-RETIC.
The inputs to each of these RETICs represent
connections from such subsystems as the visual,
described in part above, and the contact, described
in part in a later section. The number of input channels
to the present RETICs is very much smaller than
win be required eventually from, say, the visual
subsystem of the robot. In fact, the number of input
channels, (1'1 to 1'42 in Figure 17) is only as many as
needed to demonstrate the principles of operation.
How an animal is commanded
In the core of the reticular formation of animals
(retic), the selection of a mode of behavior is made
by a matrix of fan-shaped cells embedded in regions
that are stacked like poker chips. The input processes
of each cell, its dendrites, give it both its fan-shaped and
its poker-chip-like thickness .. Its output is an axon
which traverses the long axis of the chip-like stack.
Each cell in general receives signals from several
parts of the brain, from many other reticular cells,
especially those in its own neighborhood, and from
several interoceptive and exteroceptive sensory -pathways. Collectively, these cells decide which mode of
behavior the animal will enter. In its sharpest form,
Assembly of Computers to Command and Control a Robot
127
SIMULATED INPUT
Figure 17-Simulation model of the command eomputer, S-RETIC, and threshold units (Ti) that determine convergence.
The Mi are logic modules; the Si are sensory systems; all Pi (only P7 shown) are modular mode-indicating output lines:
~ simulates a RETIC environment that engenders input signals (sight, sounds, etc.); T and Bare t.he
top and bottom boundaries of S-RETIC; asc and dsc are the ascending and descending
"nerve" bundles. For clarity, the connections that recur on all M modules are
shown only on :vI7
this assertion is only a hypothesis; but broadly speaking it is an evident biological fact.
The informational organization of retic is analogous
to a board of medical doctors who must decide upon
the treatment each of a series of patients must receive.
Suppose there are twelve doctors on the board each a
generalist, as well as a specialist in a different field of
medicine, and that they must select one of four possible
treatments. Their deliberations resemble the process
by which S-RETIC selects a mode of behavior.
Like the board of medical doctors, the command
computer (retic) must cOlnlnit its charge to a mode of
behavior which in most cases is a function of the
information that has played upon it only over the last
second or so (signals indicating mission are part of
this). It receives information that is vast in amount,
but highly correlated between input channels and arrives at one of a small number of mutually exclusive
modes of behavior in a dozen or so tinle steps, with
minimal equipment and maximal reliability. After
128
Spring Joint Computer Conference, 1969
a mode is decided upon, it must send oat control
directives to the other agencies in its charge to tum
them to their respective tasks. Finally, that part of
the command computer which at any given time has
the most crucial information has authority over the
mode of operation.
First simulation of a command computer, S-RETIC
Like retic, S-RETIC resembles a stack of poker
chips, but each chip is now a computer module, M i ,
and represents many retic cells (see Figure 17). Together the modules of S-RETIC decide on a mode of
behavior in response to data from an overall environment that is static while each decision is beLl1g made.
Note the word "overall". A major part of the environment of retic is the cerebral cortex where are stored
the plans and goals of the animal. Although S-RETIC
has only 42 binary input lines and chooses among
only four modes of behavior, it demonstrates principles
that can be applied on a much larger scale for a robot.
The 42 input lines, Ai, are connected from sensory
subsystems, Si, to modules, M i , in several-to-several,
but not all-to-all fashion. The outer box in Figure 17
represents a generator to simulate an environment
formed in response to the input, 1;. At tpjs stage of
design, all (j i and 'Y i lines carry binary signals. All of
the other lines into and out of modules carry numerical
estimates of probabilities.
Each of the 12 logic modules computes from its
input information the probability that each mode of
behavior is best for the robot. After this initial guess,
the modules communicate their decisions to each other
over the low capacity ascending and descending lines,
Then each module combines this information in a
nonlinear fashion with new information coming into
it to arrive at adjusted probabilities that each of the
four modes is best for the robot. The module, in tum,
conununicates this adjusted guess to the modules to
which it is connected above and below. The process
repeats until six or more modules find one mode of
behavior best for the robot with a probability greater
than 0.5. This threshold is sensed by threshold units
T in remote motor controls.
Each try at consensus, or convergence, is called a
cycle of operation. Fot" details see Appendix B.
S-RETIC is a computer program operated now as
part of the larger program described below. It always
converges to the desired mode of behavior in less
then 25 cycles, but 30 are allowed for it in a larger
time period called an "epoch" with the new model
described below.
Second simulation of a command computer, STC-RETIC
In the second simulation of' a command computer,
the already-operating S-RETIC was exp~:mded to provide interconnections between the a-parts of the
modules (w lines), short- and long-term memories
(STM and LTM) in each a-part and channels through
which the experimenter can reinforce each module.
In addition, the number of 'Y lines to each module was
increased to seven; the (j lines were increased to 13,
and the lnode of behavior of the robot (RM) was fed
back to each a-part.
The new model is called STC=RETIC 'where S
and T stand for a spatially and temporally changing
environment, C for conditioning and habituation.
"Vhere each module of S-RET! C has a transformation
network to form its initial guess, each module of
STC-RETIC draws its initial guess from its LTM.
During this and the ensuing epoch, it computes the
effects of reinforcements, given it by the operator,
and then adj usts its L TM accordingly. The result
is conditioning, habituation and other fon1lS of "plastic
behavior". For details see Appendix C. Given there
are examples of the Pavlovian conditioning of a
robot in a remote environment and the dropping
out of this conditioning, called habituation. Development is also presented there as a form of plastic behavior.
The next step is to design a computer to be both a
refinement of STC-RETIC and a more faithful reflection of the neurology of the core of the reticular
formation. H-RETIC as it will be called, where H
stands for hardware, will be organized much like the
STC;'RETIC with physically separate modules containing adaptive elements for memory.
Contact subsystem
Design of a sense of touch has progressed to the
point of planning a hand and arm to reach out and
press lightly against surf aces to the front and side
of the robot. Figure 18 shows the tactile hand with a
single finger. A grasping hand is also being designed
to be carried by a second arm.
As shown by Figure 18, the shoulder provides three
degrees of freedom: linear extension and rotations in
elevation and azimuth. All motions are polar-centric,
that is, centered on a common point, so that trl:msformation of coordinates can be as simple as possible.
It is planned to map the probings of the fingee
in a somatic first-stage computer, similar to the visual
first-stage computer described previously. The zaxis of that mapping will be depth rather than luminance. Sudden changes in depth will be detected
by lateral inhibition, as they are in animals. 8
Assembly of Computers to Command and Control a Robot
129
6. hunt for prey or fodder
7. explore" (or search)
8. urinate
9. defecate
10. groom
11. mate (or sex)
12. give birth or lay egg
13. mother the young (e.g., suckle, hatch, retrieve)
14. build or locate nest
15. innate forms of behavior unique to the species,
such as
migrate
hibernate
gnaw
hoard
WRI-ST AnnUDE
Figure IS-Degrees of freedom of the arm and hand
Command of the commander?
Since both visual and tactile computation can be
commanded to respond to some sizes and shapes
more strongly than others, we are led to ask: What
commands the command computer of an animal?
Dr. McCulloch's answer is revealing: "Nothing.
You can persuade or cajole the command computer,
but you cannot command it." His statement is supported by his diagram in Figure 2 where the influences
upon retic are represented by the many connections to
it. "There need to be connections from more than one
sense, preferably at least three," he continues. Other
influences upon retic are internal, such as the cerebral
cortex, where are stored models of the environment,
past and present, and future models in the form of
goals. These influences may be stronger than external
ones. Influences to a model of retic are represented by
theSiofFigure 17.
Modes, which the retic of a vertebrate animal
chooses among, are as follows. 16
1. sleep
2. eat
3. drink
4. fight
5. flee
A comparable list for a Mars robot is given in a
previous section.
We can imagine how a man'.:) retic selects among
his possible modes of behavior. Vision consists of
both the feed-inward of raw sensory data and the
feed-outward of signals to adjust filters to match
internally-generated images. Touch, hearing and
kinesthesia appear to operate in similar fashion.
Sensory inputs, therefore, of the kind represented
by the Si of Figure 13, represent information from
external and internal sensors and internal computers.
Consider the actions of a soldier on sentry duty
at an advanced post in enemy country .He is expected
to hold his filters to match the stimuli he has been
taught to expect from the enemy: the shape of his
face , the color of his unifOlm, his manner of fighting,
.
etc,17 If the soldier hears the snap of a breakmg
twig, turns toward the sound, and receives from i~s
direction images that match the projections of hIS
stored models, he may classify the sound and the
sight as "enemy." What the soldier does next depends
upon other models stored in his relational compute}·.
If circumstances appear to favor combat, the sentry
may fight (mode 4). If pircumstances appear overwhelmingly adverse, the'sentry may turn and run
(mode 5). Circumstances that cause his command
computer to select a mode are the number of the
enemy, its armament, etc., as these are recognized
by the process of generating projections and comparing
these at the filters with incoming images. Thus the
enemy can persuade or cajole the soldier's command
conputer.
Similarly, the Martian environment should be
able to persuade or cajole the command computer
of a Mars robot, in cooperation with very many
fewer relations than are required for a human being,
such as a sentry. As far as we know the Mars robot
will not have to contend with enemies and, therefore,
130
Spring Joint Computer Conference, 1969
,
_.c~_~_
..
./J"'';;';:':;':'
~
..
,
_
··:-,--------",,;.c~·
--
Figure 19-Proposed mobile data-acquiring element for a Mars landing
willllot have to fight 01' flee. Nor will it have to enter
any of the other modes which an animal has .to enter
in order to eat and reproduce.
The ten modes suggested in a previous dection are
very much reduced versions of the requirements
of an animal. Instead of the elaborate mode of behavior
to hunt, are the much simpler ones to advance, retreat,
and look-and-f'eel.
Stages in the development of a robot
The system we have just described can be achieved,
we believe, by such a process of designing, simUlating,
and testing as we have described for the development
of the separate computers.
A camera-computer chain of the kind described
previously can be packaged so as to be mobile. A
possible mobile camera-computer chain is shown in
Figure 19. To eliminate the need for its own power
supply and transmitter to earth, it is connected to
a Mars lander by a cable which it pays out from a
spool at its center. To permit it to look from side
to side without moving, its camera employs a rotating
prismatic mirror which reflects the light of the scene
through both left and right optical paths, to photocells which transduce luminances to voltages. The
voltage amplitudes, when converted to digital words,
then enter shift registers, to move past computing
elements in the manner described earlier. Vertical
scan is attained by turning the drum that holds the
camera.
In initial experiments, the visual first-stage computer
can be at the far end of the cable in the lander. When
a light-weight visual first-stage computer has been
completed, it can be placed within the mobile datagathering element.
The command computer will not be tied in initially,
the command being exercised by the earth operator.
W hen the command computer has reached the stage
of development where it can be tied in, it can be
built into a robot that is physically separate from
the lander, in a configuration such as that shown in
Figure 20. This design shows, for test purposes, a
stereo television camera mounted in gimbals on a
commercially-available tractor. The gimbal mounting
of the camera permits it to look forward, sideward,
up, down and backward. Besides the camera is the
arm described in an earlier section. The rubber tires
would be replaced for lVlars travel by wire-mesh tires.
Comparison tt'ith other robot projects
Perhaps because it is directed toward development of
the properties of the computers described in an earlier
section, ours is the o~ly robot proj ect with a binocular
TV camera as input, a visual second-stage computer
to employ thi'1:l binocular input for precision computation of range) and a command computer to receive
Assembly of Computers to Command and Control a Robot
131
attention to psychology, while other projects assign
reverse priority. We make an exhaustive search of the
literature on each animal "computer" we investigate
and attempt to create, within the constraints of
technology, a working model of the "computer".
Examples of such literature searches are given in
References 28, 4 and 16.
Once we have achieved a working model we proceed
to improve it and in doing so may excel nature. 'll e
are now reducing the appearance of a scene to stereograms that are much better than Figure 6, which had
resulted from out attempt to model animal vision.
CONCLUSION
Figure 20--Proposed experimental robot
simultaneous inputs from several senses and decide
what class of thing the robot should do.
However, the visual computers and the command
computer are still operating separately While in other
robot projects assemblies of computers and external
equipment are already operating together. Eyecomputer-arm-hand systems are in operation at
Project MAC," M.LT.ls and the Department of Computer Science at Stanford University.I9 A computerarm-hand system is in operation at the Department of
Mechanical Engineering, M.I.T.20 An eye-computervehicle system is in operation at Stanford Research
Institute (SRI).21 Out of the efforts of the projects have
come list processing langugaes 22 23 which we may use
in simulating a relational computer. Other contributions are speech recognition,19 the kinematics of
manipulators under computer control,24 the mapping of
the space in which a manipulator operat es 25 and
recognition of visual contiguity.26
Since we are all engaged in processing increasingly
large volumes of data, reward goes to the one who
discovers a method of extracting useful data. At Project MAC and Stanford the reward can take the form
of a doctor's degree; at SRI and our project, which are
more eq'.lipment oriented, the reward is to have either
the equipment or a simulation of it work. This reward is
also present at the two universities; and SRI and we
also d<;> theoretical work.
Aside from the amount of equipment in operation,
the greatest difference between our project and the
other three is in the way we use the life sciences. All of
us use this information since we are all trying to make
computers and other hardware do what until now,
only animals have done. However, we give primary
attentidn to anatomy and physiology, secondary
To some, the work reported here will appear to be
slavish imitation of the vertebrate" nervous system.
It appears to us, on the other hand, to be good engineering practice. When something does what you
want it to do and is already miniaturized; why not
copy it?
The copy is made only in principle. Visual computers
are time-shared elements, past which data is moved
by shift registers. The modules form larger portions
of the command computer than do cells in retic.
In fact, the modules and the cells are similar only in
their mathematics.
To quote Dr. McCulloch, "We use the word
'robot' in two ways. The first, and less important,
is as a machine that performs isolated functions of
a human being. The second, and more' important,
is as a description of life applicable to either living
things or machines. Such a description is indifferent
to whether the system is man-made or grown, whether
it is built of hardware or living cells. This is a central
theme of cybernetics: to use the same logic and mathematics to describe men and machines. Norbert
Wiener looked at control this way. We are looking
at both command and control. Thus, in the more
important sense, a robot is a prescription for a system
that until recently could be achieved only by the
growth of living cells but is becoming something we
can manufacture."
ACKNOWLEDGMENT
Because the physiological concepts presented here
came from Warren McCulloch it would have been
correct to list him as an author, but in doing so we
could not have identified his contributions. One who
helped us describe these contributions was Dr.
Jerome Y. Lettvin. The simulation of the visual
fum-stage computer is the work of James Bever who
began it, John Hatfield who devised the fonn of
132
Spring Joint Computer Conference, 1969
filter employed in level 5, and Jerome Lerman who
devised all of the filters presently employed. The two
aimulations of retic were carried out by Jay Blum.
REFERENCES
2
:~
4
5
t)
7
8
9
10
II
12
13
14
C M MICHAUX
Handbook of the physical properties of the planet Mat's
NASA 1967 for sale by the Superintendent of Documents
U S Government Printing Office Washington D C 20402
SPACE SCIENCE BOARD OF THE ;\IATIONAL
ACADEMY OF SCIENCES
Planetary exploration 1968-1975
2101 Constitution Avenue X \V Washington D C 20418
L L SUTRO
Information proces.~ing and data compression for exohiology
missions
R-545 Instnlmentation Laboratory MIT
Cambridge Massachusett~ ] 966
R MORENO-DIAZ
A.n analytical model of the group 2 ganglioi/, cell ill
the frog'.,: retina
Report. E-I858 Instnlmentation Lahorat.()r~· MIT
Cambridge MasRacuhsett~ 196fl
W S Mc CULLOCH
Embodiments of mind
MIT Press Cambridge Massachusetts 1965
D DENNY -BROWN
The cerebral control of movement
Chapter VI Charlel'l Thoma..;; Pllhlisher~ 1965
R H SELZER
The u~e of computers to improve biomedical image quality
Proc F J C C 1968
G VON BEKESY
Sensory inhibition
Princeton University Press Princeton )Iew Jerl'ey 1967
F RATLIFF
Mach bands: quantitative .<;tudie8 of neural 'netwurks 1:1/ the
retina
Holden-l)a~r Inc S3n }"f:!TIcisco ! 965
L L SUTRO C D SIGWART J D LEAVITT
D G TWEED
Instrumentation of camera-cornputer chains
Report. R-636 Inst.rumentation Laborat.ory MIT
Cambridge Massachusetts 1969
R GREGORY
Eye and hrain
World University Lihrary MeGraw-Hill New York 1966
50-60
W M BRODI~Y N LINDGREN
Human enhancement be yond the machine age
IEEE Spectrum Describing the work of Donald Me Kay
February 196889
L L SUTRO
Computer synthesis of images with shades and shadows
Report E-2250 Instrumentation Lahorat.ory M J T
Cambridge Massachusetts 1969
W L KILMER W S Me CULLOCH
The reticular formation command and contro,' system
Proc Symposium on Information Processing in the
Nervous System, State University of New York at
Ruffalo OC't.oher Hl68 (in pubieat,ion)
15 W L KILMER W S Mc CULLOCH J BLUM
L SUTRO
A model of life to select a mode of behavior
Report R--635 Instrumentation Laboratory MIT
Ca~bridge Massachusetts 1969 (in preparation)
16 W L KILMER W S Mc CULLOCH
The biology of the reticu.lar formation
Michigan State University Division of Engineering
Research Report. East Lansing Michigan (in preparation)
17 J D FRANK
The face of the enemy
Psychology Today November 1968 25
18 M L MINSKY S A PAPERT
Research on intelligent aut01nata status report I I
Project MAC MIT Cambridge IV!assachusetts 1967
19 .J Mc CARTHY L D EARNEST
D R REDDY P J VICENS
.1 computer with hands eyes and ears
Proc F J C C 196R
20 W R FERRELJj T B SHERIDAN
Snpervi.<;ory control of remote manipulation
IEEE Speet.rum Vol 4 No 10 October 1967 ~1-88
21 N J )IILSSON C A ROSEJN R RAPHAEL
G FORSEX L CHAITIN S WAHLSTROM
.4.pplication of intelligent automata to reconnai.'lsance
Stanford Research Inst.itute Menlo Park California 196R
22 E C BERKELEY D G BOBROW editor,;;
The programming language LISP
Information International 200 Sixt,h St,reet Cambridge
Massachusettts 1967
23 L G ROBERTS
}Ifachine perception of th1'ee-dirnen~i()nal solids
Optical and electro-optical information processing
MIT Press 1965
24 D L PIEPER
The kin,emalics of manipulators u.nder computer control
Computer Science Department Stanford University
Palo Alto California 1968
25 D E WHITNEY
State space models of remote manipulation tasks
Engineering Projects Laboratory Department of
l\IechanicaI Engineering ~! I T Cambridge !\1ass~chusett~
1968
26 A GUZMAN
So'me Mpects of pattern recognition by computer
MAC-TR.-37 Project MAC MIT Cambridge
MassachuseUs 1967
27 ILLUMINATING E~GINEERING SOCIETY
lE8 lighting ha,ndbook fourth edition
345 E 47th Street New York 1966 2--6
28 L SUTRO editor
Advanced Sensor and Control System Studies
1964 to September 1,96.5
Report R-519 Instrumentation Laborat.ory MIT
Cambridge Massachusetts 1966
APPE~DIX
A
Scaling
As indiC'R.ted earlier; 9.pplication of a filter such
aH
Assembly of Computers to Command and Control a Robot
G 2 ,vill produce matrices of luminances that are
"on scale", except when applied to spots and edges
of maximum contrast. By "on scale" we mean on
the scale of 0 to 63 that our digital-to-analog converter
can convert and our scope can display.
vVhen filter G 1 X 1/8 is convolved with all of
the submatrices of luminance -in a typical scene and
a histogram plotted of the convolution sums, the
result is Figure 21. The extremes are formed when
the center of the submatrix of luminances is 63 and
the surround is zero, or vice versa. By lopping off
extremely high and low values of the convolution
sum, as shown by cross hatching, the scale is contracted.
Added to the central luminance of the submatrix
in question, the convolution sum enhances contrast.
In the rare case where this addition forms a negative
sum, this sum is repJaced by zero. Filter G 1 X 1/8
is used in this example, rather than filter G 2, to demonstrate a symmetrical histogram. The 2 in the center
of filter G 2 leads to the unsymmetry.
133
Inputs (stimulus)
Layer of interacting
model cell units
Outputs (impulses),
Figure 22-Schema of the receptive layer and interacting layer,
with arrowheads indicating the direction of conduction of
impulses in an animal, amplitude of signals in a robot
Filters to enhance contrast
Luminance contrast is defined27 as
(AI)
Where Ll and L2 are the luminances of the background
and object, respectively. Such contrast is detennined
in animals and machines, not by a simple subtraction
and division as here, but by the convolution of a filter
with the luminances in the image.
In previous sections we considered the application
of a minimum-area filter to an image. Here we consider
filters of any size that may be useful. If each filter,
in a matrix of filters, has a sensitive central excitatory
re~ioll surrounded by a less sensitive inhibitory
region, possibly surrounded in turn by a still less-
-63
-31
o
31
sensitive excitatory region, the matrix may be represented by the schema of Figure 22.9 The pattern of
response is here detennined by the net effects produced
by overlapping, and possibly opposed, excitatory
and inhibitory influences. This interaction of influences may be expressed by a set of simultaneom;
equations, one for each filter.
Implied in the diagram of Figure 22 is 'n-iutual
inhibition which can be represented by Figure 23
if the recurrent lines are headed by circles, instead
of arrows, to represent inhibition. The effect of recurrent inhibition can be achieved either by such connections, by the non-recurrent filter shown in section
in Figure 24, or by two applications of the 7 X 7
filter shown in Figure 24. Jerome Lerman devised
this 7 X 7 filter which, when convolved with itself,
63
AJ NON-RECURRENT
Figure 21-Histogram of convolution sums formed by filter G1
,,-ith all of the sub-matrices of luminance in a typi('al seene
Figure
2;~-Interaction
8) RECURRENT
of cells A and 11
Spring Joint Computer Conference, 1969
134
n
excitatory and inhibitory effects in Figure 24 is to
continue the spatial filtering outward from the center
of influence. While this filter passes higher spatial
frequencies and rejects low, the frequencies to wr.ich
the vidicon responds are not very high, so it might
be called a "middle-pass filter."
Trf~DESIRED
.
\
ACTUAL
I
I
I
a
Filters to form a line drawing
I
\
I
\
-2
-1
To select points of high contrast that outline
objects and details, the second-stage visual computer
needs to take differences~ not only to detemline
contrast as in formula AI, but to determine if this
contrast exceeds a threshold.
Consider how these differences can be taken in
scanning across the five bands of luminance, in Figure
25. The contrast across the area is represented by
-2
-1
IA -
I
\
-I
.~ 13 RESOLUTION ELEMENTS
-1
-1
-I
-1
-1
-2
-2
-2
-1
-2
-1
-2
-1
-2
-1
-z
, , ,
, .. , -z
, , , -z
-1
-2
-2
-2
-z
-2
-1
-1
-1
-1
-1
-1
-1
-1
l
b
fZ
,
-1'
-1
*
-1
-1
Z
3 •
5 6 7 6
5 • 3
'IIW1I22M22JaW1O
;
10
•
W
2
.. -W
-6
-,
-6 -W
Z
6
z11
DI
where Av is the average of t.he five lumiAv
nances. The threshold, for reasons explained below,
is best expressed as the reciprocal of the inner difference
B-C multiplied by a constant. Employing these
differences, Jerome Lerman devised the following
criterion which the computer applies first in the
horizontal direction, then in the vertical.
T-I!
-6
,
10
3
.. -151 -1M -M -lt2 -M -194 -151
-6
]A
•
5
11 -W -1M -310 -212 -l5C -212 -310 -194 -W
Ja
5
!A-D!
6
22
.. -M -212 116 ... 116 -212 -198
-6
22
6
Av
7
M
-2 -lt2 -l5C ... C472 ... -154 -w.!
-Z
M
7
,
22
-6 -191 -212 116... 116 -212 -191
-6
22
6
5
11
-W -1M -310 -212 -154 -212 -310 -194 -U
11
5
•
U
.. -151 -1M -M -w.! -191 -194 -151 -6
U
•
l:
10
2
,
10
2
3
-6 -W
U
•
.
,
-2
]I
22 M
5
7
.. -iA
~
,
U
22
11
5
•
.I. ...
,
Z
If
IA-Dj
Av
iJ
Figure 24-(a) Dashed line, graph of cross-section of desired
filt.er; solid line, graph of cross-section of approximation shown
in (b) _ (b) Weights of the filter employed in enhancing the
contrast of Figure 5
produces the 13 X 13 filter below it. If each 7 X 7
filter sununed to zero, the center would be 8. By
summ.ing to 56 the filter enhances existing contrast.
The 13 X 13 filter also sums to 56. The computer
of Figure 7 applies the smaller filter twice since its
core memory will hold only seven lines at a time of
a digitized image, 2.56 positions wide with 6 bits per
position.
The purpose of the diminishing waves of alternately
(A2)
a dot is placed in the line drawing.
W
10
3
K
-IB -ci > 0,
K
-IB -cl
~O,
(A3)
no dot.
Figure 26 develops the reason for using the reciprocal
of the inner difference, times a constant, as thp
threshold. Curve a is a ramp of luminance. Curve
b is its derivative when Llx is the narrow span represented by the distance between 1 and -1 at the upper
right of curve b. Curve e is the derivat.ive of eurve
b when .6.x is larger. To reduce curve a to a dot, it
is evident that the threshold needs to be lowest
when the derivative is both as great as possible and
as peaked as possible. By plotting the reciprocal
as in curve d, the peak does not go to infinity, as it
could, and remains manageable. The threshold is a
fixed fraction k of this reciprocal.
Assembly of Computers to Command and Control a Robot
135
APPENDIXB
Operation of S-RETIe
B
A
c
D
Figure 25-Four bands, each of approximately uniform
luminance, about a band of luminance not lettered
(a)
L
~~~----+---------------------.
(b)
6L
7lX
x
10-1
FOR SMALL 6x
x
(C)
6L
6x
1000-1
Each set of lines Pi in Figure 17 (only P7 is marked)
indicates the ith module's degree of preference for
each of the four possible modes. Thus Pi is a probability vector. The ascending and descending lines
out of M i are branches of Pi which connect to other
modules.
As shown in Figure 27, each module has two parts.
Each a-part computes from the module's input
information the initial guess as to what mode of
behavior is best for the robot. The b-part computes
an adjusted guess from information received from
above, below and from the a-part. The a-part which
has five binary input variables and four probabilistic
variables, is a nonlinear transfomlation network.
The b-part receives 4-component probability vectors
po from above, pa from below and p' from the a-part.
The components of each vector are the relative
probabilities of each of the four possible modes of
behavior. The jth component of each pa, po or p
probability vector is the probability, computed by
the module of origin, that the command computer's
present 'Y input signal configuration calls for mode j.
The b-part abo receives a measure of the cycle-tocycle difference between 'Y inputs, called "'Y difference"
in Figure 27, and a measure, Q, of the strength of
convergence on the last mode commanded (shown
being formed in the lower right corner of Figure 17).
Consensus among the modules is achieved, aR
illustrated in Figure 17, by first detemlining in the
step function (s), if the jth component of the probabi1ity vector P from each module exceeds 0.5. If it
does, a 1 is passed on to the threshold element T j.
There, if 50 percent or more of the jth component
input connections are 1'8, mode j is commanded.
FOR LARGE 6x
x
(d)
6x
6L
r it ---f---+H+IINPUTS ';2 --+---'+++1FROII 'il~_~+1-
If_r"
~
r,. ___
FOR SMALL 6x
L....-_ _ _J..-_ _ _ _
---4~
_ _,,",-
,<--_~
X
~
~.I
Figure 26-Explanation of use of reciprocal of inner difference,
times a constant, as the threshold in determining whether
a dot shall be placed in line drawing. See text.
fo r description of steps
co.tfCTf0N5 TO lOWf. *llU.ES
Figure 27-Input and output connections to parts a and b of a
module in S-RETIC
136
Spring Joint Computer Conference, 1969
Note that each element T j in Figure 17 receives
10 inputs, a1though for -1larity in the drawing, connections are shown only to T 3. The threshold elements
T are part of the executive computer pictured in
Figure 2. Each T receives many inputs, decodes
them and executes a mode of behavior.
S-RETIC is described in more detail in Reference 15.
APPENDIXC
Operation of STC-RETIC
General
Figure 28 diag~ams the a-part of a module in
STC-RETIC. Signals from the senses (w's); from
modules above and below ('Y's), from the threshold
units that determine the mode (R~I) and from the
experimenter (RPC and RAC's) enter the short term
memory where they are held for two input epochs.
STC-RETIC converges on a mode in the same sequence described above for S-RETIC, except that
each initial guess is read from a long tenn memory
instead of being generated by a transformation network. Each initial gtiess is read out as a probability
vector to be used in the same way as p'i in S-RETIC
(Figure 27).
In the conditioning .process, the information as
to module inpuLs, module p', the converged-upon
mode and whether it was good or bad, is used to
modify the probabilities stored in long term memory.
In either conditioning STC-RETIC, allowing it
to habituate or in other ways encouraging it to acquire
temporally influenced patterns of behavior, the
operator of STC-RETIC not only provides the
external conditions (~, Fig. 17) to which it will
respond, but he takes the place of the parts of a
robot that would indicate that the input and response
conditions are punishing, neutral, or rewarding. He
introduces a negative reinforcement prior to convergence (RPC) to indicate that the external conditions
are themselves punishing, and a zero HPC to indicate
that they are neutral. Finally he introduces four other
numbers (HAC's) to indicate the reinforcement
effect on STC-RETIC of its selection of each of its
modes of behavior. An RA(\ is a "reinforcement to'
be applied after convergence if STC-RETIC converges
to mode i." It is used in conjunction with shortterm-memory informatjon in the module to specify
the corresponding modification to the module's
long term mem~ry. A negative value of RA(\:, called
"punishing," IS interpreted by STC-RETIC as
evidence for not converging on mode i the next time
the same 'Y's and w's are received. A positive value.
called" rewarding," is interpreted oppositely.
Examples of Pavlovian conditioning and
habituation in the robot
pi
Figure 28-The a-part of a .module in STC-RETIC
i
Pavlo\~ian COIlditioning is made possible both bjr
responses "wired into" the long-term memory of
each module of STe-H.ETle, and by 'Y's and w's
acquired during two epochs by the module's shortterm memory. For example, let us suppose that a
"wired-in" (unconditioned) response is (1) to command
l·etre.at. when t.he robot feels a horizontal edge with
nothing beyond it (a precipice ?), then (2) to be
rewarded (positive RAC) for saving the robot.
Let us suppose further that each time the robot
feels an edge, beyond which it feels nothing, it also
sees an edge, beyond which it sees nothing. The more
often the robot both feels and sees an edge, beyond
which it feels nothing, and then is rewarded for
retreating, the more firmly it becomes' conditioned
to back up at the sight, instead of just the feel, of
such an edge.
In STC-RETIC such conditioning is stored in
t.he long-term memory of each module, which contains
Assembly of Computers to Command and Control a Robot
a reduced record of the conditions under which it
has made decisions.
An example of habituation in a robot is the following.
Suppose a robot travels over the surface of iViars
and comes upon territory that is sharply striped in
light and dark. vVhen it ceases to behave as though
each stripe were a precipice, it will have become
habituated to the striped terrain. After a time, the
duration of which was pre-specified, it. will spontaneously recover the original response so that, if it
then moves into territory where such stripes are
shadows marking true hazards, it will not be harmed.
What have changed in both of these examples are
the long-term memories of modules.
Forms of robot behavior due to development
As explained above, the initial guess of the a-part
137
of each module is made by consulting its long term
memory. If there is no entry for the given values of
'Y and w, then a flat probability vector (all four components equal) is read out.
Changes in a long term memory, which starts from
flat probability vectors, are what we mean by development. STC-HETIC has room in the long term memory
of each module for 100 vectors, some of which are
fiat, others are preprogrammed to non-fiat values.
Some of the kind of development that is complete
in the retic of a mammal at birth may be best achieved
by STC-RETIC through experience in its environment.
Other forms of plastic behavior modeled by STCRETIC are: generalizatjon of and discrimination
among the conditions under which a mode response is
given, avoidance conditioning and extinction of
Pavlovian conditioning.
=::no~i~ _!lnrl .... t;l;~g ...;n~ n.r .ron .... l ......
nl--:,---- - - ..... "' ..........
..
T
LJ~"' '-'.I..I. u ........ «U.l.L]
universal tree circuits
by GIACOMO CIOFFI
Fondazione U. Bordoni
Rome, Italy
and
EUGENIO FIORILLO
I.B.M. Itaiia
Milano, Italy
INTRODUCTION
Cellular tree circuits
In the last few years the progress of integration techniques of more and more (;omplex digital circuits has led
to the development of a new branch of the switching
theory known as cellular logic. 1 Nevertheless the
integration of cellular circuits of a certain degree of
complexity is hampered at present by poor yield, that is
by the likelihood that one or more cells of the circuit
may turn out to be faulty. It is useful, therefore, to try
to use these circuits even when there are some faulty
cells. Generally speaking there are two possibilities:
A cellular tree circuit with n levels, An, is a circuit
having the structure shown in Figure 1, and can
implement any function of the n variables Xl, ... , x n •
The circuit is made up of 2n -1 cells, all equal (Figure
2), which implement the function
(a) to provide a certain degree of redundancy in the
circuit, so as to be able to replace the faulty cells with
spare cells;2
(b) to use, if possible, only the part of the circuit
functioning correctly.
with X =
The second way seems easier to carry out, since it
does not require interventions on the circuit already
realized.
Apart from the choice of either way, it is necessary
above all to carry out the diagnosis of the circuit in
order to determine what failures have taken place.
In the present paper these problems are studied in the
case of universal cellular tree circuits. 3 ,4 In the first part
. a minimal set of diagnostic tests is derived; in the
second part a criterion is set forth which, on the basis
of the results of the tests carried out, makes it possible
to find some functions that can be realized by the faulty
circuit.
i-I
Cji = C2j
-
Xi
+ Ci-I
2j+l Xi •
The 211 inputs (Xl, ... , Xn) * will be indicated briefly
n
L x2
i
i - 1•
The binary inputs co, ... , C2"-1
i=l
are for the specialization of the circuit; to be exact each
of the 2(2 n ) vectors C == (co, ... , C2"-1) corresponds to
one and only one function F(X1, ... , Xn). It is easy to
show 3 that, if vector X is applied to An, the output c~
coincides with the specialization bit Cx; therefore there
exists a one-to-one correspondence between the minterm
mj and the bit Cj (0 ~ j ~ 2n-1). A function
F(xt, ... , xn) is implemented on An giving the specialization bits corresponding to the minterms implicating the
function values equal to 1 and leaving the rest at O.
Tests to detect fauUs in an An
In view of the regularity and the simplicity of the
(*)
139
Xi
=
0 or 1
140
Spring Joint Computer Conference, 1969
Table 1
x
Co
C
C
1
2
C
c
3
...
~----~-;--------~--T--
0
,c •
•-------------------
Zn-~I_L---.--q-t-----t-.,~----t-.
--t-~---+-+t•
z,, _ _ _
.e;
"n ")
0
1
1
2
1
0
1
1
1
1
")
.)
1
1
1
0
1
2n_1
-"
1
1
1
1
1
1
0
c
1
1
.,
I
1
..................................
)n_2
1 1 1 1
0
1
12n-1
1 1 1
1
0
.. -
F(z, •..• z,,)
Figure l-..'3tructure of the universai ceBulaI' circuit (t.e.)
Figure 2-j-th cell on level i of the t.e.
interconnections, only faults within the cells are considered possible; this implies that, even when there are
faults, the output of each cell always remains a function
(possibly degenerate) of its three inputs exclusively. To
remain on a more general plane, it will be supposed that
a faulty cell can implement any of the remaining 255
functions of three variables.
This section describes a complete and minimal method
of detecting faults in a tree circuit; that is, it detects all
faults satisfying the above mentioned hypotheses and
consists in the minimal number of tests.
complementing all the specialization bits. They give
two sequences each of 2n ones at the output of a
correct t.c.
Let us consider the set of tests 0 j, 1 j, 0 t, 1 t applied to
a correctly functioning t.c. The signals at every point
of the circuit are shown in Table 2.
I t can be seen- that the four tests for the whole tree
correspond to the same tests carried out on the subtrees
and on the individual cells according to Table 3.
Let us take as an example a tree made up of only two
levels (Figure 3).
The tests are those shown in Table 4, in which it is
supposed that the circuit functions correctly.
I t is then possible to constru.ct Karnaugh's map of
the function implemented by each cell (Figure 4); for
the sake of clarity the maps have been arranged in the
same way as the respective cells.
This result can be easily extended to the case of an
n-level tree. On each level the squares of the maps are
Table 2
1 1
2 2
2
cOc,c2c)""c2D_2C2D_, c o c""c 2D -'_1 COC''',C 2D-2_
o
0 0 0 0 ... 0
0000 ... 0
1
0
0
0 0 ... 0
00 ... 0
0 0 ... 0
0" ... 0
~.
D-' D-'
1
... Co
c,
Co p
... 0
... 0
0
0
0
0
0·0·0·0·:::·0.. ·0 .... 0·0·:::·0.. ·.. ·0·0·:::·0...... ::: 0'"0''' '0"
~:'i
I I
.;o..II~. ~. ~. ~.:::. ~ ... ~ ....l"'"
~. ~.:::. ~ ...... ~. ~.:::. ~ ...... ::: ~ ... ~ ... ~. ~ ..
I'
Description of the tests
The test in which all terminals Co, •.• , C2n-l are
fixed at 0 and the inputs take on all possible values
X o, ••• , X 271 - 1 is called here "fixed 0 test" (0 / ), If the
tree circuit (t.c.) functions correctly, during the fixed
otest there is a sequence of 2n zeroes in the output.
The test described in Table 1 is called here "travelling
o test" (Ot). If the t.c. functions correctly, during this
test there is a sequence of 2n zeroes in the output.
The tests here called "fixed 1" and "travelling I"
(1 I and 1 t) are obtained from the OJ and 0 t tests by
1
X
2
-'j
1 , 1 ... 1
1
1
1 1 ... 1
'" 1
1
1
1 1 , 1 ... 1
1
1 ... ,
1 1 ••• 1
... 1
1
,1
! I'! ~ 1~ ::: ~ ~ ~ L:: ~
'I
I'
3 , 1 1 1 0 ... 1
·d··j........ · ........
1 1 1 ••• 1
1
0
i
0
!1 0
-"l 1
o
10 ... 1
oo . . .
1 0
'001100
... 0
0 0
0
2
0 ...
I'
g~ :::
~
01 ... 1
\' :::
Ig ~
... 0 1
II
~
I'
0
i······ .... " .. 'j" " 1 ' " ' ' ' ' +.... ;
ill
... 0 ...• •• j'1 00 1 0
1 1 '" 0
! 1 0 ... 0
... 1'
0
!1 !
1
~ ..............
11 0 0 0 ... 0
2D-~i 1 1 1 1 ... 0
2
1
I'
1 1 ... 0
1 1 ••• 0
... 0
1 0 ...
01
... 00
I'
I)
'1
0 ...
10
... 00
"'1"
0
0
.. '10
... \I
1
1
... 1
' 11
I'
~ ... ~.~.~.~.:::.~... ~ ..... ~.~.:::.~ ...... ~.~.:::.~ ...... ::: ~ ... ~ ..... ~ .. I
2 -2 0 0 0 ., : •• 1
2D_1 0 0 0 0 ... 0
0
1
i 0 0 ••• 1
I ()
0 ... 1
I·
0 0 '" 1
0 \I . . . 1
1
1
I
Diagrams and UtiHzation of Faulty Universal Tree Circuits
Table 3
,
,
1
1
COC1"'C2n-1_2C2n-1
x
°
iri':1
OfOf" •• Of
i:':, I
,
°
Of
'r 'r" "r
1r
°t'r"'r
'r
-,
2
2
Co ···C 2n- 2_,
Of"'Or
I'r"
"r
Table 4
...
...
...
°t""r
2
1r Ot ••• 'r
'r
2n -4
2 _3 'r'r···Ot
'r
2n_1 1r 1f" •• 1r
°t
3
~ri"
,
°
2
Or
n
Co
'r
'r
°t
'r
'r
' r ' .Ot
°t
'r
°t
Or
\"'Or
't
Or
....................... ............. ....
~ri':4
~-3 0r0f""'t
Or
2n_1 °r°f"' 'Of
\
~n_2
't
Of
°f""t
\
X2X'
c c c c
O 1 2 3
0
o0
000 0
1
0 1
o0 0 0
o0 0 0
o0 0 0
o0
2
1 0
3
1 1
0
1
2
o0
3
,
o0
o 1
2
1 0
1 1
0
0
1
2
3
.Figure 3-A two level t . c.
-,;1
g,
(II)
0
0
(IJ
f
~)
,
,
f4)
(I)
£
f
OJ)
c'o
0
,
tI)
tuJ
0
0
(8J
I
,
r_J
0
(lIN
I
(ilJ hJ (f$)
~'
I
o 1
1 0
1 1
3
Xf----~----~----~----~~
1 1
O 1
X
Or
Or
Of
'tOr" 'Or
°r\"'Or
3
n-1 n-'
Co C,
....................... ............. ....
~n_2
141
o0
0 1
1 0
1 1
C C
=
2-F
CO
o0
0
0 0
n
v
o0
0
0
1 1 1 1
1 1 1 1
1 1 1 1
1
1
1
1
1
1
1
1
1
1
1
1
0 1 1
101
1 1 0
1 1 1
0 1
o 1
1 0
1 0
0
0
0
,,
1
1
1
0
1 000
o10 0
001 0
000 1
1
1
1 0
1 0
o
o
0
1
1
1
1
1
1
then for Xl = 1, starting from the map of c~ as far as the
map of ~"-i-l (0, test);
(2) the squares of the third columns, as at point (1)
(I, test);
(3) the upper squares of the fourth columns and then
the lower squares of the second columns, as at point (1)
(0, test);
(4) the upper squares of the second columns and then
the lower squares of the fourth columns, as at point (1)
(It test).
Every cell on level i is tested 2 i-I times. It is useful for
what follows to note the law for the construction of the
map of a cell of level i from the maps of the two cells
above of level i - I (Figure 5).
Properties of the tests
Figure 4-Correspondence between the tests and the entries
of the cell maps
controlled in the following order (the columns are
numbered from left to right):
(1) the squares of the first columns, first for
Xi
= 0,
A tree An can be decomposed into two subtrees having
n - 1 levels, A1I- I and ~-h and in its output cell. For
the sake of simplicity the outputs C~l and C't"l of the
two subtrees An-I and ~-l will be indicated in this
section with a and fJ.
Lemma: If the 0" 1" 0 t, 1 t testf:, carried out on an
A., give correct outputs, outputs a and fJ of subtrees
142
Spring Joint Computer Conference, 1969
Table
i-I
.j
-e2j
.
I
X
A:'~
..I
0, 1
Of:
0, 1
1 :
f
°
at:
A
n
n-1
n-1
~O
bits.
?
Table 6
x
n
AI
A
n-1
Po
0, 1
Of: (Xo
Of:
0, 1
1 : cx,
f
1 : (3,
f
0
at: <:to
f-
- - - - -1
1 : cx
1
f
0
1 : a.
t
1
- - - Of: ~O
f-o--
1
A
n
n-1
'£: (31
f-
-
-
°t:
~
- -
Po
Of: ~O
-- - 1 : ~,
t
II
Of: 0
1f:
at:
1
°1
't: 1
Proof Necessity: it is obvious. Sufficiency:. according
to the Lemma, if the outputs are correct a and (3 axe
. constant in each of the eight half-tests. A Karnaugh map
can therefore be constructed for the function of the
output cell, as shown in Figure 6. The function implemented by this cell is therefore of the following type:
F = a * xn
+ f3* Xn •
(1)
Since the outputs are correct, two possibilities may
occur:
Diagrams and Utilization of Faulty Universal Tree Circuits
a,
a'o
0
0
I
I
I
0
0
I
4
Figure (j-The final cell map
(1) a* = a and!3* = !3: An-I,
are functioning correctly;
(2) a*
= a a/o !3* =
P:
~-I and
the output cell
An - I a/o A~_1 give the
complemented output, but the output cell makes up for
this defect.
In both cases for Xn = 0 {XII = I} the output of An
reproduces that of A n - 1 {A~_I}' apart from complementations. Therefore the maps of C~-l and of C~-l can be
constructed for Xn = 0 and for Xn = 1 respectively. It is
seen at once that also the functions implemented by
these two cells are of type (1), and therefore the
considerations made for c~ are still valid. Proceeding in
the same way, we can construct the maps for all the
cells of the circuit, which always implement functions
of type (1). It can be concluded that circuit An functions
correctly, since it has been proved that all the cells
function correctly, apart from pairs of faults that cancel
each oth~r out and therefore cannot influence the overall
behaviour of the circuit.
Theorem 2: The set of tests 0" 1" Oe, 1 t contains the
minimal number of tests necessary to control the
functioning of a circuit An under the conditions envisaged
for the faults.
Proof: In view of the structure of All and the type
of faults considered, the cells on the first level are all
independent of one another; it is evident, therefore, that
the number of tests necessary to control them is
8.2 11- 1 = 21142. This is obviously a lower limit for the
number of tests referring to the whole circuit. Then, too,
considering the independence of the cells of each level,
the attempt can be made to organize the 2 n+2 tests
necessary to control the cells of the first level so as to
carry out at the same time the tests on all the cells of the
following levels. Theorem 1 shows that this is actually
possible. This is what we set out to prove.
The utilization of fauUy cellular tree circuits
Fault localization
The method set forth in the preceding section also
makes it possible to localize the faulty cells in a way that
143
will be described. As has been seen, tests 0" 1" 0 t, 1 t
make it possible to construct the Karnaugh map for the
ceH at level n, and every square of the map is explored
by 211- 1 tests. At level i a cell c1 is tested 2 i-I times. If
this cell is faulty, exhibiting a mistake in a square
corresponding to Xi = 0 {x i = I}, 2 i-I consecutive
wrong outputs occur starting from element 2k· 2 i-I
{(2k + 1) ·2 i-I} of one of the four sequences.
The same output sequence is obtained if the two cells
c~ and c~tl ar~ faulty in the same way as ct Similarly
it can be seen that 2h cells at level i - h with faults in
the same squares of the maps (and all the combinations
of these faults) lead to the same output sequence.
It can be concluded, therefore, that, if in one or more
tests there exist as many output sequences composed of
2 i-I wrong terms starting from element 2k· 2 i-I or
(2k + 1)·2 i-I, the subtree having ci as its output cell
contains one or more faulty cells. If there exist several
wrong sequences not correlated in the preceding way,
there exist as many faulty subtrees in the circuit.
The data supplied by the four tests do not permit a
more exact localization of the faults. Then, too, it is
easily seen that the number of additional tests necessary
for this purpose can become prohibitive in proportion as
the dimensions of the faulty subtree Ai grow. Furthermore, a minimal set of these tests cannot generally be
fixed in advance independently of the results of the
preceding tests.
A method will be described which makes it possible,
on the contrary, to use a faulty An to implement a subset
of functions of n variables without further diagnostic
tests.
Finding a set of functions that can be
implemented by a faulty t.c.
Let us suppose that the tests 0" 1" Ot, 1 t have
detected a subtree Ai. containing one or more faulty
cells. Cases i = 1 and i > 1 are considered separately.
1st case (i = 1): Tree Ai is reduced to only one cell
of the first level. Since the inputs of this cell are all
accessible from the outside and therefore known, it is
easy to obtain the function implemented by the faulty
cell. Let this function be c} = g(Xl' C2;, C2i+l)' If it is
expanded according to Shannon with respect to Xl, we
get
Terms go and gl can be considered as equivalent
specialization bits and they depend generally on both
the signals applied to the two control terminals of the
cell.
If and only if the correspondence between pairs gog)
144
Spring Joint Computer Conference, 1969
and C2j~j+1 is a permutation, cell c} is still able to
implement all the functions of Xl, and therefore An is
able to implement all the functions of n variables. In all
other cases the functions of Xl that can be implemented
by c} and tberefore the functions of n variables that can
be implemented by An can be found immediately.
Example 1: Let us consider an A3 (Figure 7). The
result of the diagnostic tests is supposed to be the one
shown in Table 7.
In each test one wrong isolated term is noted;
therefore the faults of the circuit are limited to the first
level. Since the wrong terms correspond to X = 2 and
X = 3, it can be deduced (k = 1) thattheyaiicorrespond
to cell c~; the map of the function implemented by this
cell is therefore that shown in Figure 8. The function
impiemented by ci in iorm (2) is therefore
The equivalent specialization bits are:
C!eq
=
C~a
c3eq
=
~C3.
.xyl
f
1
o
0
0
I
I1
i
I0
Figure 8-The map of the faulty cell of example 1
Owing to the correspondence between the specialization bits and the minterms of the functions implemented
by A 3, it can be deduced that all the functions having
one and only one of minterms nl2 and ms can be implemented. To Lrnplement a function with m~ alone the
terminals can be specialized in the usual way; to
implement a function with m3 alone it is necessary, on
the contrary, to fix C2 and C3 both at 1.
2nd case (i > 1): Two types of faults can be distinguished as can be seen from the map of cell c;
which has
(a) one correct row.
(b) errors in both rows.
If------~---+--~--~~~~--+---~--~_+
Z2----------~---+----------~~--~+
F
Figure 7-The t.e, considered in example 1
Table 7
x
Of
1f
°t
't
1
,
0
1
0
0
2
1
0
0
1
,
3
0
0
0
0
0
1
1
1
1
1
0
0
0
0
0
0
4
5
6
7
(a) If cell c~ has the map with the row Xi = 0 {Xi = 1}
correct1 it can be said that subtree Ai functions correctly when Xi = 0 {Xi = I} according to the considerations set forth in Theorem 1. The faulty tree can
therefore be decomposed as in Figure 9.
When Xi = 0 {Xi = I} the output c; coincides with
the output of A i - l {~-l}' Then, too, when Xi = 1
{Xi = 0 1 the output of c~ can be known independently
of Xl, ••. , Xi-l if all the specialization bits of ~-l {Ai-I}
are fixed at 0 or at 1. This output coincides with the
value of the lower {upper} square corresponding to test
0, or I, on c).
An An with such faults can implement functions of
the following type
(3)
1
1
0
1
1
1
1
where: X; = Xi {Xi} if the upper {lower} half-map is
'\
correct;
~-i is the vector (X'+l' .," xn) direct or
complemented so that c~ = cj for X!-i = 1.
-yisdefinedinFigure.l0forxi = X;,; for xi = Xi,
'Y is defined in a similar way, taking into
account the lower half-map; 0';'-1 is the
value common to the 2 i-I specialization
bits of ~-l fAi-I} ;
Diagrams and Utilization of Faulty Universal Tree Circuits
145
Table 8
X,
--------~----_+--------~~~_+----~
x.L- -(--------~~------------~~----_+
They are therefore programmed on their
subtrees specializing the bits in the usual
way.
Xjq-l)
0
0
0
1
3
0
4
5
6
0
0
0
0
0
0
0
0
0
0
0
1
1
1
14
1
15
0
1
0
13
0
1
1
1
1
1
1
1
1
1
0
0
1
1
1
1
1
0
0
1
1
1
1
(4)
r
+ II L
q=l
hq~iq
X!~ ghq(Xl, ... , Xiq) .
In fact, owing to the structure of the tree, the first
terms of Equation 3 written for' the individual faults
can be implemented independently. The second terms
of Equation 3 must be intersected with one another so
as to obtain the residual part of An which does not
belong to any of the faulty subtrees.
Example 2: Given an At, it is supposed that the result
of the tests is as shown in Table 8.
There is a sequence 0000 in column 1 t for X = 0,
1, 2, 3; this implies the presence of a fault in a subtree
As (2 i - 1 = 22), which has cg as its output cell (k = 0).
Similarly, the two sequences 00 in tests 1 f and 1 t
corresponding to X = 10, 11 imply the presence of a
~
ITIIJ
0
1
2
12
+ x~ 'rq] +
q-l
1t
10
11
If there are r subtrees ~1' • • • , ~r which show faults
of this type, the proceeding is similar. The circuit can
implement functions of the type:
~q-iq [x;q fq(x!, ... ,
°t
7
8
9
f and g are any functions of their arguments.
r
1f
0
0
0
Figure 9-Deeomposition of a fault.y tree Ai
L
Of
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
x·----------------~~--_+------------~
t,
F(X) =
x
fault in an A2 with c~ as its output cell. The maps
corresponding to cg and c~ are shown in FigUre 11. Both
have one correct row. Applying Equation 4 we obtain:
F(X) = ~ xSf1(Xl, X2)
+ xSO"s + J4Xs x2f2(xl) + X2'0 +
+ J4gl (Xl, X2, Xs) XS~~,1 (Xl, X2) +
+ XaX~'2(Xl, X2) + XsJ4g2.S(XI, X2) =
= X~fl(XI' X2) + XaX40"S + X2 XsJ4f2(xl) +
+ XsJ4f(XI, Xli) .
In the last term f(Xl, X2) has been used instead of
gl(XI, X2, 1) g2,S(XI, X2) since this product is any function
of Xl and X2 .
.c R
.c'
4
()
y=O
r1INIJ )' = "i-I
ITIIJ
~
--;2
.l31 0 0
I
I
-sf
~,
0 0 0 0
.cs
I
[Q[]TI]
ITIIJ
Y ="i-I
[I[JZ[J
ITIIJ
y=
f
,c3
0
Figure 10-Definition of the function
'Y
2
.c2
Figure II-The maps of the faulty... cells of\, example 2
146
Spring Joint Computer Conference, 1969
Table 9
(b) If the map of c) does not have a correct row,
let us consider the functioning of Ai in tests 0 f and 1 f·
Since every square of the map of c; is explored 2 i-I
times co~esp~nding to all the values assumed by
Xl, ... , Xi-I, the output of Ai in these tests is a function
of Xi alone or is constant, according as to whether the
columns of the map of c; corresponding to tests 0 f and
If are 01, 10 or 00, 11. Therefore A1'I can implement
functions of the type:
F(X) = ~-i [CTiC;(Xi)1
I
hq ,c3 q
+
usXa)
1
1
0
0
0
0
0
0
0
1I
0
1
1
m
I
I
,. 0
.c f2
+
XsX4(U2X2
+
CT2'0)
If
0
0
0
0
0
It
0
0
0
1
1
1
1
,
1
1
0
0
0
0
1
0
1
1
1
+
+ [~gl(XI, X:;, xs)]· [XsX4g2,I(XI, X2) +
+ XaX~,2(XI' X2) + X~g2,3(Xl, X2)]
= xsX4 + CT2X2X~ + x~f(xI' X2) .
The number of the functions that can be implemented by a faulty circuit according to Equations 4
and 6 can be considerably increased if we admit the
possibility of permutating the variables XI, ... , X1'I on
the n inputs. To be exact, the number of functions
that can be implemented should be multiplied by n!.
In the case of Example 2, for instance, the fUIlctions
.c03
I
!
1
1
1
.c'
4
"
.%"61
Xiq) •
Example 3: Let the results of the tests carried out
on an A4 be those shown in Table 9. The presence of two
faulty subtrees with output cells c~ and c; can be noted.
Their respective maps are shown in Figure 12.
If we apply Equation 6, we get:
F(X) = ~(CTsXa
1
f
,cZ
r
q=l
0
0
0
0
13
14
15
+ uiq c;:(Xiq)o] +
X!~iq ghq(Xl, .. "
1
1
1
12
(6)
II L
1
1
1
11
q=l
+
1
10
In the case of r subtrees Ail' ... , Ai,. with faults of
this type, we obtain:
[CTiq C;:(Xiq)1
1
1
1
1
0
0
1
7
8
9
where: CT i is the value common to the specialization
bits of Ai;
C)(Xi)1 and C;(Xi)O are the functions implemented
by cell c; during the tests I, and 0 f
respectively;
the gh are any fun~tions of Xl, ... , Xi and are
programmed on their subtrees by specializing the bits in the usual way.
q
0
6
h,ci
r
0
0
0
0
4
5
(5)
L' xt:-'i
0
3
+ L X!-i gh(XI, ... , Xi)
F(X) =
u
1
2
+ UiC;(Xi)O] +
ot
x
I21
~
·0 0 0 I
.c'S
,£'2
Figure 12-The maps of the faulty cells of example
2
:~
implemented are 211 = 2048; by permutating the
variables in any way, they become 2 11 ·4! = 49152.
CONCLUSIONS
A diagnostic method for t.c. has been described which
makes it possible to utilize faulty circuits in a simple
way. The diagnostic tests for the circuit are in minimal
number and can easily be carried out automatically, in
view of their independence of the faults and their
uniformity. In the use of faulty t.c. one or more subtrees
containing the faulty cells are isolated and their
specialization bits are all fixed at 0 or at 1. In this way
it is not possible to TInd all the functions that the faulty
Diagrams and Utilization of Faulty Universal Tree Circuits
t.c. is still able to implement. However a large number
of additional tests, which furthermore cannot be
established in advance, would be necessary to determine
the complete set of functions that can be implemented
on a faulty An. Then, too, the law for giving the
specialization terminals their proper values would be
generally somewhat complicated.
REFERENCES
1 R C MINNICK
147
A. survey of microcellular research
Journal of the A C M vol 14 no 2 April 1967 pp 203-241
2 R C MINXICK
Cutpoint cellular logic
IEEE Trans vol EC-13 no 6 Dec 1964 pp 685-698
3 G CIOFFI V F ALZO~E
Ci7'cuiti cellulari con struttura ad albero
Automazione e Strumentazione vol 16 no 8 Aug 1968
pp 338-350
4 S S YAU C K TANG
Universal loy'ic circuiis and iheir modular reaiizatiorl
Proc S J C C 1968
Solid state keyboard
by EVERETT A. VORTHlVIANN
Honeywell, Inc.
Freeport, Illinois
and
JOSEPH T. MAUPIN
Honeywell, Inc.
Plymouth, Minnesota
INTRODUCTION
The computer industry is no doubt one of the most rapidly growing industries today. With the increase in
computer usage, there is an increased demand to improve man's ability to communicate with the computer.
The prime instrument of input communication today
is a keyboard, and it appears that this will be true for
some time in the future.
The requirements of today's keyboards are becoming
more complex. Increased reliability and more flexibility
to meet specialized demands are essential. Remote
terminals are quite often operated by relatively untrained personnel and the keyboard must be capable
of error-free operation for these people. At the same
time it should be capable of high thru-put for the trained
operator as will be used on a key tape machine.
Some of the limitations of existing keyboards are:
bit parallel code is usually used. Two codes currently
used are ASCII and EBCDIC and the keyboard design and construction must be such that any code can
conveniently and economically be supplied. The output
signal must be compatible with the solid state integrated
circuits used in today's computers.
Specific design objectives
At this point, each key may be thought of as a simple
switch, actuated by the position of a key plunger.
Human factors studiesl -4 helped establish the following for mechanical and tactile features of key operation.
Operate force: 2 to 5 ounces
Pretravel (before operate): .075 inches min. from
free position
.l\1echanical interlocks which reduce operator speed.
• Excessive service (increasingly linportant for remote terminals).
• Contact bounce and wear of mechanical switches.
• Non-flexible format.
Our general objective in developing the solid state
keyboard was to overcome these limitations and still
have a competitively priced design.
Keyboard organization
Before setting forth specific design objectives, some
general comments may be helpful, depending on the
reader's familiarity with this type of equipment. The
purpose of a keyboard is to feed information into a
digital computer by means of a binary code. An eight
Release point: .040 inches min. from free position
Release point (R.P.)
~
Operate point (O.P.) where a = differential
a
Switching transitions should be "snap acting" or regenerative so that it will not be possible to hold a key
in a position that will cause ambiguity at the output.
Rise and fall times must be in the low microsecond
range without any ringing or oscillation. The encoding
electronics must be capable of blocking error codes when
two or more keys are depressed.
Keyboard formats are quite varied, depending on the
user's needs and preferences. This indicated that each
key should be a separate module. Finally, the service
life should be in excess of 10 million operations per key,
149
150
Spring Joint Computer Conference, 1969
and low cost was given a priority second only to reliability.
TRIGGER CIRCUIT
OUTPUT AMP
I I
The approach
From the outset, our thinking was slanted toward the
development of an integrated circuit chip transducer
for the key module. The powerful and still growing
economic advantages of batch processing used in integrated circuit manufacture were considered essential to
our stringent cost objectives. To fully exploit these
advantages, it was desirable that the chip be complete
in itseif i.e., that ii require no external components to
accomplish its function. The latter cannot be added in
batch fashion.
Several approaches to mechanical position detection
without contacts were studied, based mostly on unique
sensor effects available in a semiconductor such as silicon. Position control of an electric, magnetic, acoustic,
or electromagnetic (including optical) field pattern is
fundamentally involved. Hall effect sensing in a silicon
device, inCluding appropriate integrated electronics,
and coupled with permanent magnet actuation, was
singled out for detailed analysis, design and development.
This approach was eventually adopted for the solid
state keyboard. The competing approaches mentioned
above, though quite feasible, seemed to require more
expensive packaging, or more expensive and less reliable field sources, or were known to require external
components in the electronics. :Vlagnetic actuation
looked particularly attractive because it appeared that
the sensor device could be integrated on the silicon chip
along with associated electronics as well as allowing
more freedom in package selection. Among the several
galvanomagnetic effects present in semiconductors, we
found that only the Hall effect in silicon is large enough
to be useful in the low field « 1000 Gauss) region of
interest.
The' silicon chip that has been developed is described
by the functional breakdown in Figure 1.
A circuit schematic is given in Figure 2, and a picture
of the chip comprises Figure 3.
Some of the analytical and experimental investigations associated with this development are presented
in what follows.
TRIGGER
HALL
GENERATOR
+
~
CIRC.UIl
AMPLIFIER
Figure I--Functional description of silicon chip transducer
o
Figure 2-Circuit schematic of chip transducer
Figure 3-Photograph of chip
H all effect characterization
As many readers will already know, the Hall effect
is old in scientific terms, having been discovered by
Edward W. Hall in 1878. It is currently enjoying a.
renaissance of practical applications interest due mainly
to advances in semiconductor technology. Two publications6 •6 by A. C. Beer provide excellent general references. The Hall effect results directly from the Lorentz
force on moving charge carriers; where the average
motion is constrained in direction, as in a solid. This is
illustrated in Figure 4. The Lorentz force creates a
charge unbalance in the y-direction. The resulting
Solid State Keyboard
151
(2)
VH= EyV
:RHIB
V = supply voltage
8
8
10 t
Where RH=HIII
Coefficient ::
~-IB
I
T Fy
Vx _
.
zJ--x' ···~ ···
Ey ~ I
- -JJ( Bz nqc
+
A factor less than unity has to be applied to equation
F=q(E+(t)vxB)
Figure 4-Hall effect illustration
electric field, called the Hall field, provides a force that
cancels the Lorentz force. Integration of the Hall field
between a pair of probe contacts on the sides of the
conductor produces the Hall voltage.
Equation 1 shows an approximate Hall voltage expression for a homogeneous layer with predominately
one type of carrier concentration.
H
-
RH IB
108 t
(1)
RH
= Hall* coefficient ~_ J:..
n
= concentration (cm- 3)
nq
I, B, V H = mutually perpendicular
t
= Thickness (cm)
B
= Gauss
VH
volts
I
amperes
q
W = width
2 if the aspect ratio W /L is not smaller than unity.
THE HALL EFFECT IN A SOLID IS A DIRECT MANIFESTATION OF THE
LORENTZ FORCE ON MOVING CHARGE CARRIERS:
v _
= mobility (cm2jv-sec)
L = length
1
=-1. (v +B )
Ud
= charge on an electron
Since most electronic circuits operate from a constant
voltage supply, equation 2 below is more appropriate,
It is straight-forward derivation * from equation 1 for a
rectangular geometry.
* \Ve assume "Hall mobility" and "conductivity mobility" to be
substantially equal for the conditions of interest. The validity of
this assumption, has been confirmed through private communication with Dr. G. D. Long. Honeywell Corporate Research
Center.
This is due to the shorting effects of the end contacts on
the Han field. One cannot increase the Hall voltage
indefinitely by increasing W /L.
Equation 2 illustrates the important role of carrier
mobility. In this respect, silicon is not a good material5
compared to, say, IuSb or GaAs. However, one must
go beyond equations 1 and 2 to include practical constraints of power dissipation, electrical resistance,
range of impurity concentrations, and temperature
variation of Hall coefficient. When this is done, silicon
looks much better. Relating constant current and constant voltage modes of operation to semiconductor
processing, observe that thickness and concentration
(equation 1) are also the major processing variables that
control resistor values in integrated circuits, and the
expected tolerance is quite large. On the other hand,with
constant voltage, only the mobility is process dependent, and it tends to be a weak function7 of concentration
in the region of interest. Thus we expect and obtain
much better reproducibility of Hall voltage with constant voltage excitation. This is gained at the expense
of a higher temperature coefficient, however, due to the
variation of mobility with temperature.
Assuming a field of 1000 Gauss t~ be available,
straight-forward calculations using typical mobility
and reasonable geometries showed that we could obtain
a signal of about 30 millivolts with a five volt supply,
and without exceeding typical power dissipation capabilities in IC chips.
Figure 5 shows an expression for total d.c. output
voltage of a Hall element, including the effects of small
loading at the Hall terminals. The characterization is
entirely in terms of parameters measurable at the
terminals. The offset voltage term, Vq, which is the open
circuit output voltage with zero magnetization, is a very
important parameter in this device. Economic restrictions ruled out the use of external resistors for adjustment of Vq. Its nominal value using IC technology depends mostly on contact geometry and sheet resistance
uniformity in the conducting layer comprising the Hall
element. Fortunately, very accurate geometries are
possible using photolithographic techniques developed
152
Spring Joint Computer Conference, 1969
experimentation was conducted, confirming its feasibility and the accuracy of the preceding characterizations.
As to process considerations for the associated circuitry, the objective was to take advantage of conventional IC processing strengths, which lead to high yield
results on the following:
1. High gain, accurately matched NPN transistors.
2. Low gain PNP transistors.
3. Accurate control of resistance ratios, but not
absolute values.
Throughout the design-development cycle, extensive
effort was devoted to achieving a simple design that is
amenable to high yield processing, yet adequate for the
intended function without external components.
If (13
V34
Vq
+ 1 4 )«
= Vq + VH -
= Offset
The trigger cirmtit
IH ;
I3 R3
~
I4R4
H = Hall Voltage
Voltage; V
Figure 5-Hall element output voltage characterization
for IC fabrication. Variations in Vq can be caused by
several factors, such as internal stress (through the
piezoresistance effect) and temperature gradients. Regardless of the nature of the electronic circuitry that
follows the Hall element, the variations in Vq must be
much lower than the Hall voltage for adequate "signalto-noise" ratio.
Design-Process interrelation8hips
As with any integrated circuit development, the
circuitry, device physics, and process techniques are
interdependent, and must be so treated. At the time the
development was initiated it was considered essential
for low cost objectives to use the epitaxial-diffusion,9
bipolar, NPN based, type of processing which was
rapidly becoming an industry standard. MOS type
processing was not sufficiently controllable to be
seriously considered.
In an NPN type of bipolar structure, the collector
layer has the lowest carrier concentration and highest
mobility; it is the best choice for a Hall element. Hence
the design approach was pursued on the basis of forming
the Hall element simultaneously with collector regions
for NPN transistors. The same isolation diffusion is used
for defining the Hall element geometry. (The Hall element outline is faintly visible in Figure 3). Since this is
a novel type of Hall element structure, some preliminary
The function of the trigger circuit is to accept the
linear output (with or without linear amplification) of
the Hall element and convert it to a binary or ON-OFF
mode, with regenerative switching transitions and controllable hysteresis (or differential between the "turn
on" and "turn off" operate points).
The trigger circuit we devised is shown in Figure 6.
It is a variation on the Schmitt type of circuit. It may
be implemented with just two resistors and two bipolar transistors. An approximate analysis aimed at
providing insight into its general characteristics will
be given here.
Assumptions used in approximate analysis:
a. The transistor model shown in Figure 6 applies.
The most important feature of this model is that
Shockley'S law applies to the I'E - VBE characteristic. This is well established for silicon
planar bipolar transistors. Extrinsic resistances,
collector conductance and all time dependent
effects are omitted. The model requires active
region operation, which is easily met.
b, 111 + I B ' = I, a constant
c. IB« I c (high gain)
The static voltage control characteristics at the input
base is of primary interest.
(3)
Using the above assumptions this becomes,
VB = - KT (1
q
~
n I's
+1
1 - IE/I)
nIBil
(aIR4) IE!I
(4)
Solid State Keyboard
LOAD SUCH THAT
NOT SATURATE
switching transition, but not the fact of its occurrence.
The trigger points are thus found by taking the derivative of equation 4, shown below as equation 5, equating
it to 0, and simultaneously solving equations 4 and 5.
T' DOES
I
I
KT
dV B
V
d (I )
8
III
80-----4
= -
1
q (1 - Ill/I)
fI
- aIR4 = 0
(5)
A result from thls approximate analysls is given
below for one condition of regenerative feedback. The
"ON" condition is defined as T' conducting and T off.
T
E
Trigger Circuit Schematic
1 ~'l
.LVV
Transistor Model Used
Turn ON point
Turn OFF point
- .069 volts 0.723
- .061 volts 0.276
Figure 6-Trigger circuit. schematic
.130 volts
The first term of equation 4 represents the control
characteristic 10 of a conventional difference amplifier
stage using the same assumptions noted above. The
second term is the result of linear regenerative feedback.
If this term has the appropriate magnitude, the transfer
characteristic will have a negative resistance region that
covers a few millivolts. The transfer characteristic may
be easily observed on a curve tracer using a discrete
component version of the circuit. One such observation
is reproduced in Figure 7. The constant total emitter
current condition is approximated in this version of the
circuit by using an emitter resistor with voltage drop
that is several times larger than the VBB voltage.
The nature of regenerative switching transitions may
be reviewed in a number. of references, particularly
those dealing with turmel diode circuits. Chapter 15
in Linvill and Gibbons' bookS is especially good. We
will only note here that the trigger points depend exclusively on static parameters, and are given by the
transition points from positive to negative resistance
around any closed mesh of the circuit. Reactive effects,
active device response time, etc., affect the speed of the
KT = .026 volts, and I, = I',
q
Our investigations showed that this circuit configuration could provide regenerative switching transitions
with rather precisely defined trigger points and voltage
transitions between trigger points of a few millivolts.
The component requirements are well suited for integration, with critical performance depending on transistor matching and resistance ratios. Note that the transistor matching requirements are the same as for a good
difference amplifier stage, with VBB matching to about
±2 millivolts. This is routinely done in Ie's, due to
close physical proximity, extremely accurate matching
of geometries, and simultaneous processing.
Output amplifier
The output amplifier, consisting of a PNP stage
driving an NP~ Darlington, operates in standard saturated switching logic fashion. Its characteristics are
relatively non-critical. The PNP is fabricated with a
"lateral" geometry and its current gain is low. Static
conditions for the OFF and ON states are as follows:
lOpA/div.
.,
INPUT
..
:···~·r~
OFF State T' Off
zero drive to
PNP base
ON State
Figure 7--Experimentallook at trigger circuit contl'Ol
characteristic
OUTPUT
Output voltage = 0
(with reference tosupply)
T'On
Output voltage =
PNP saturated supply voltage minus
(VeIl SATa + V BR4
V BBi)
+
154
Spring Joint Computer Conference, 1969
As previously noted, a functional requirement is that
there be no linear region in the output of the device,
i.e., output voltages between the OFF and ON levels can
only exist on a transient basis, This requires t.h9"t the
thresholds associated with the output amplifier operation be well within the negative resistance region of the
trigger circuit Dontrol characteristic. The resistor R2 is
designed such that the value of I'C at the trigger circuit turn on point will not develop enough voltage
across R2 to forward bias the PNP bas&-emitter junction. The combined PNP-NPN gain requirement is
such that the PNP stage saturates at a value of Fe
that is below the trigger circuit turn off point. Resistor
Ra provides adequate margin against self turn-on in the
Darlington stage under worst case temperature and
gain conditions.
The output transistor has dual emitters and provides
two isolated outputs. This aids in the encoding logic;
in effect, part of that logic is included in the chip. This
is an example of the economics possible when using IC
technology, for the additional output adds virtually no
cost to the chip.
An additional benefit of the solid state keyboard is
that the output sjgnal from the key does not require
additional buffering to eliminate the effects of contact
bounce. Switching times are in the low microsecond
range and are free from ringing or oscillation.
has been the stress sensitivity of the Hall element
through the piezoresistance effect, previously mentioned, and this has been overcome by some special
mechanical features in the chip-package design.
Chip specification
The specification is given in Table I. It is written as
broad as possible to maximize the overall process yield.
Computer aided analysis
In the design of a product intended for the computer
field, the utilization of computer-aided analysis seems
especially fitting. When we avoid some of the simplifying assumptions used in the preceding approximate
analysis; equations analogous to (4) and (5) become
extremely cumbersome. Their simultaneous solution to
obtain operate and release points becomes humanly
intractable; a computer program was written to obtain
such solutions.
Performance of the device was studied as a function
of several independent parameters.
l. Supply voltage
2. Transistor gain, matched and prescribed mISmatch
3. Emitter junction saturation current, matched
and prescribed mismatch
4. Resistor and resistor ratios R 1 , R 4/R 1 .
5. Offset voltage, Vq
Integration of sensor and electronics
Aside from the usual considerations of parasitic
interactions within an integrated circuit, the special
effects resulting from including the sensor in
the Ie chip constituted an interesting and novel
aspect of this development. In general, we find
more advantages than disadvantages in this approach
and predict a growing trend toward "integrated transducer" semi-conductor devices. Inductance parasitics
are virtually eliminated due to the extremely small
dimensions. A potential source of ringing or oscillation
in regenerative switching circuitry is thus avoided. For
the same reason, noise pickup in the leads from sensor
to electronics is minimized. High impedance leads to the
outside world are avoided.
In the functional operation of this device, magnetization is applied over the entire chip. This has no effect on
the electronics, as expected, for the resistors and transistors do not have any magnetic sensitivity in the
magrietic field range of int~rest. The Hall element output, like a balanced bridge with matched temperature
sensitive resistors, is sensitive to temperature gradients.
This has to be taken into account in the output stage
design and operation, and the thermal design of the
package. The most troublesome parasitic encountered
Space does not allow presentation of this analysis
and results. The reader may contact the authors If
interested. The computer-obtained results have been
of great value in guiding the design and the design-process relationship. Figure 8 shows the effect of gain and
~=1.05
5
\=
I
INDUCTION Y. S.
I
800
S
S
I-~~
t1.P.
L
I
I
I
,
600
~
iL
f(
I
I
I
i
i I
I
1
20
I
I
I
~
400
10
30
tB~
I
j,.- V """ I
700
500
~5= 0.9
a
1 I I 1 I I I I II I I I I I I
9001
G
A
U
1.0
40
"!I,
I
I
I
I
i
i
I
I
i
50
60
70
80
Figure S-J£ffect of gain and gain mismatch
I
I,
i
I
tB
"s'
90
100
!
R.P.
t----
Solid State Keyboard
gain mismatch. We note that performance becomes
essentially independent of transistor beta in the range
above 50. With these results, a realistic process gain
specification minimum of 30 was established.
Temperature characteristics
The dependence of operate and release points on
temperature for a typical device is shown in Figure 9,
based on experimental data. The slope of the cunTes is
roughly accounted for by the expected temperature
dependence of mobility. However, second order effects
in the circuitry have a certain influence, not completely
analyzed at this time. First order temperature effects
in the circuitry are eliminated by use of matching and
ratioing techniques.
Packaging the chip
Upon examining the economics of integrated circuits,
it becomes apparent that much of the cost of commercial integrated circuits is in chip packaging rather than
the chip itself. It was necessary, therefore, to develop a
low cost, reliable packaging technique suitable for
magnetic operation.
In developing such a package there are many parameter trade-offs that must be made in order to arrive at
an optimum configuration. In most standard chip packaging approaches the chip is eutecticly bonded to a
metalleadframe or header. The metal is normally kovar
which closely approximates the thermal expansion of
the silicon chip. Since this device was to be magnetically
operated, kovar is not desirable because it is ferromagnetic. On examining the non-magnetic metals and al-
loys, it was evident that there were none with the proper
thermal coefficient of expansion. Therefore, it was necessary to find another method of holding the chip. The
approach selected was to allow the ohip, in essence,to
float in a non-rigid. potting material. This is accomplished in the following manner: A leadframe is stamped
from phosphor bronze, inserted into a mold, and transfer molded with a rigid plastic leaving a cavity for the
chip and access to the ends of the lead frame as is shown
in Figure 10. It should be noted that the cavity for the
chip is entirely plastic.
The chip is inserted into the cavity and the four
wires are ultrasonically bonded between the pads on the
chip and the leadframe. At this point, the chip is held
in place by the four wires. The final packaging operation
is to fill the cavity with a silicone potting material,
which has a very low viscosity in the uncured condition,
and it completely encapsulates the chip including the
reverse side. Figure 11 shows the chip in its cavity prior
to being potted.
In order to minimize the cost of this packaging approach, it was necessary to design so that wire bonding
could be automated. This was accomplished in the
following manner. The wafer is sawed into chips with an
abrasive slurry, rather than use the normal scribe and
break process. The sawing produces chips with square
edges and with dimensions controlled to within ± .001
inches. The chip cavity is made only slightly larger
than the maximum chip size; hence the location of the
pads on the chip relative to the leadframe is rather
precisely controlled. This allows the wire bonding machine to be mechanically aligned, rather than require
the operator to make a visual alignment for each bond.
It should also be noted from Figure 3 that the pads on
the chip are large-(by integrated circuit standards)approximately .010" square.
800
Gauss
600
OP
400
RP
200
Tempera ture in degrees Cen tigrade
30
Figure 9-Effect of temperature on magnetic operation
155
60
Figure l{}---Lead frame showing chip cavity
Spring Joint Computer Conference, 1969
156
asymptotic to the zero flux axis, a slight change in the
release point of the chip would require a large change in
the movement of the magnet to reach the release point.
This is not desirable. If two magnets a.re used and are
magnetized as shown in Figure 13, the flux versus gap
position curve will tend to be sinusoidal. This is desirable if the total travel of the magnet assembly can be
limited to the nearly linear portion of the curve. Since
the flux required for both operate and release points is
positive, the negative portion of the curve would not be
used. By inserting the two magnets in a "U" shaped
shunt and magnetizing them in place with a specially
shaped magetizing fixture, it is possible to produce the
curve shown in Figure 14. The result of this is to move
the majority of the sinusoid above the zero flux axis.
Figure 14 also shows the ma~l.Let assembly and the shape
of the poles on each of the magnets.
Figure II-Chip bonded in place
sl
IC~IP I
Package thermal considerations
I
Is :
Without a eutectic bond to provide heat transfer
between chip and package, it is necessary for heat
transfer to occur through the aluminum wires and the
silicone potting material. By using .002" diameter wire
the thermal resistance is 355 degrees Centigrade per
watt, unpotted. The potting material further reduces
this to 266 degrees Centigrade per watt, which is quite
comparable to the standard plastic dual in-line package.
(
Magnet actuation
DISTANCE =(d)
If a bar magnet is moved along its axis perpendicular
to the plane of the Hall element, the normal component
of flux will vary with the magnet movement according
to the curve shown in Figure 12. Since the curve runs
MAGNETIC
FLUX
t
Figure 1:3--Flux
HAll GENERATOR
\
1000
(GAUSS)
1
b
~
iBAR
j
VH
position, double pole magnet
100
®
t
MAGKEll
N
NI
~d~
S
MAGNETIC
FLUX
(GAUSS)
d '-'-
100
50
50]
i i i
.050
.100
..
.150
DISTANCE =(d)
Figure 12-Flux vs position. single pole har magnet
.100
DISTANCE
.150
=(d)
Figw'e 14---Fiux V~ position, douhle pole, modified
Solid State Keyboard
The magnets are made of polyvinyl chloride filled
with barium ferrite. This combination produces an extremely stable, yet low cost, permanent magnet material. The shunt is soft iron which increases the magnet
efficiency and helps to reduce the effect of stray· magnetic fields. The chip package is made as thin as possible to reduce the air gap. The magnet assembly with
the chip package is shown in Figure 15. Referring to
the specification on the chip, and relating these to the
flux versus position curve, it is possible to establish the
operate and release points of the key, as shown in
Figure 16.
157
Table I -Chip specifications
Parameter
Operate Point (OP)
Release Point (RP)
Differen tial
(OP - RP)
Supply Voltage
Supply Current
(OFF Condition)
Output Voltage
(ON) @ 5V supply
Output Voltage
(OFF) 5000 ohm
load
Output Current
(ON) (each
terminal)
Minimum
300
100
150
4.75
Maximum
750
Gauss
Gauss
;).25
15
3.4
Units
Gauss
Volts
rnA
3.6
Volts
0.25
Volts
10
rnA
Reliahility test results
Figure 15-Chip package and magnet assembly
A variety of enviromnental tests have been made on
the key chip integrated circuit, packaged as noted herein. In addition to tests on functional performance on
conventional chips, chips with special metallization
patterns were prepared and packaged, such that junction characteristics and Hall element output could be
measured directly. This allows a more sensitive indication of incipient de~adation than does functi '"lnal
performance. Table II describes tests on four lots of
devices. The results are in keeping with the reliability
1000 -
500 -
o
Key Travel in Inches
Figure 16-Operate and release ranges of key
Figure 17-Plunger magnet assembly
158
Spring Joint Computer Conference, 1969
Table II - Reliahility test results
No. of Dem:ces
Type of Test
30
Functional,
magnetic actuation
Functional,
magnetic actuation
Hall element (Vq)
15
30
Collector junction
6
V CBO @ 10 jJA
Environment
Time
Results
Normal Office
15 months
Xo failures
75 to 100 deg. F.
4~30
No failures
70 deg. C.
90% R.H.
70 deg. C.
90% R.H.
1000 hrs.
hrs.
1000 hrs.'
Maximum variation
of 2%
No change
expected of semiconductor devices, when designed,
processed and packaged properly. These tests are continuing and others are being initiated.
Mechanical assembly
The magnet assembly is inserted into the key plunger
which is shown in Figure 17 .:rrhe plunger magnet assembly is guided in the key housing by large area. guides.
We have shaped the top of. the plunger and the inside of
the two-shot molded button so that the button is press
fitted directly into the plunger, avoiding the conventional adaptor pin. In addition to lower cost this provides the advantage of a low keyboard profile.
The chip package is inserted into slots in the housing
which hold it in the gap of the magnet assembly. Two
small tangs on the bottom of one side of the magnet
shunt hold the return spring in place. This spring is
designed to provide the two to five ounces of operating
Figure t9--Mounting rail-PC board assembly
force under minimum stress conditions, assuring long
life without getting weak.
The key module, shown in Figure 18, is inserted into
a mounting rail. The module snaps into the rail, which
has clearance holes for the leads of the chip package to
extend through it and be soldered into a printed circuit
board. The mounting rails are welded to the end mounting bracket and the entire assembly is riveted to a PC
board as shown in Figure 19. The printed circuit board
provides the electrical connection between the key
modules and a second PC board. The latter contains
the electronics for encoding, t4e strebe signal, and the
electrical interlock which prohibits an error code generation when more than one key is depressed.
CONCLUSION
Figure IS-Key assembly
The solid state keyboard uses a new switching concept
which capitalizes on the inherent reliability and low
Solid State Keyboard
cost of integrated circuits. The output of this device is
compatible with the integrated circuits used in computers.
The keyboard is deliberately made modular so that it
can be adapted to special key formats and codes. It
provides an electronic interlock instead of the usual
mechanical one, and as a result allows higher speed
operation.
¥l}>ile the keyboard is different in TIli:my :respects, it
has maintained those industry standards which have
been substantiated by human factor studies such as key
stroke and force, key loea tion, and the key layout in the
touch typing area.
ACKNOWLEDG MENTS
The development of the solid state keyboard has been
possible through the enthusiastic support and dedicated
efforts of many people in our respective organizations.
We could not hope to fairly cite individual contributions
within acceptable space limits here. We also appreciate
the consultation provided by other research and engineering groups in our Company.
REFERENCES
R L DEININGER
Human factors engineering studies of the design and use
159
of pushbutton telephone sets
BSTJ Vol XXXIX No 4 995-1012 July 1968
2 R L DEININGER
Desirable push-button characteristics
IRE Transactions on Human Factors in Blectronics
March 1960
:3 H M BOWEN
Rational design jor control: Man communicating to machine,
Industrial design Vol XI No 5 51-59 May 1964
4 R D KI~CAID
Human factors design recommendations for
touch operated keyboards
Report 12091-FR Honeywell Systems and Research Center
January 1969
5 A C BEER
The Hall effect and related phenomena
Solid State Electronics Pergamon Press Vol 9 339-351
6 A C BEER
The Hall effect
International Science and Technology December 1966
7 0 N TUFTE E L STELZER
Magnetoresistance in heavily doped N-Type silicon
Phys Rev Vol 139 No 1A A-265-A-271 July 5 1965
8 J G LINVILL J. F GIBBONS
Transistors and active circuits
McGraw-Hill Book Co New York 1961
9 R M WARNER JR J N FORDEMWALT (Editors)
Integrated circuits
McGraw-Hill Book Co New York 132-149 1965
10 J T MAUPIN
The control characteristic oj current switching logic stages
Honeywell Corporate Research Center Memorandum
HR 63-37 July 1963
Computer generated graphic segments
in a raster display
by RICHARD A. METZGER
Rome A ir Development Center
Rome, New York
In addition, graphic figures require a set of defining
equations, each valid for a given domain. Thus one of
the simplest means of generating complex figures is by
combination of graphic segments (lines, circles, arcs,
etc.), into the higher order figures.
The particular problem to be addressed here is the
generation of graphic segments (straight and curved
lines) within the constraints of a raster format display.
Algorithms are developed to allow computer generation
of selected graphip segments of arbitrary length (constrained by screen si,ze) at any desired screen location.
The raster will be considered as an N x M Cartesian
grid, where N is the number of scan lines and M is the
number of addressable points on a line. All operations
will be performed within the constraints of this address
grid. By treating the grid dimensions as variable, the
algorithms are immediately usable for any line standard raster. The software approach to development of
the algorithms was adopted since this allows usage with
any of the standard D-V converters, whereas a hardware implementation is particular as to type. However,
there is nothing within the adopted approach which
prohibits hardware implementation.
Prior to considering the algorithms for generation of
graphic segment, a bri~f discussion of Digital-to-Video
conversion as a display technique will be presented.
INTRODUCTION
The increased use of computer graphics to enhance the
man-machine interface has resulted in many and
varied systems and devices to meet a multitude of
needs. One type of eli,splay that is receiving new emphasis as a computer output device is the "raster
for!p.at" display (of which standard television is a particular type). Among the reasons for using this type of
display are: (1) the relative simplicity of the display
dev~ce, (2) the ease of remote operation for multiple
statIOn users, (3) the low cost per station, (4) capability for mixing output with standard television
sources, and (5) good position repeatability for computer generated data.
However, to utilize a raster display (either standard
525 line TV or other line standard) as a computer output device, a conversion from digital to video data
must be performed. The device utilized to perform this
function Is commonly referred to as a Digital-to-Video
(D/V) Converter. It accepts digital data from the data
processing system and converts it to a video signal
compatible with the raster scan display. The converter
being a digital device, often becomes complicated sinc~
it is forced to operate within the timing constraints of
the Raster Scan Display System (RSDS). A problem
a!so arises in the subjective appearance of the display,
smce all data must be generated within the line-by-line
structure of the raster. In the case of alphanumerics a
fixed-size matrix of dots can be used to generate v:ry
acceptable symbology. However, the generation of
graphic segments is not as easily accomplished.
Graphic segments and figures vary greatly in terms
of size, shape, orientation, and complexity. If the scan
lines forming the raster together with the discrete
points on each scan line are considered as a Cartesian
grid, it can be seen that in general, graphic segments
will not fit exactly within the constraints of this grid.
Digital-to-video conversion
The generation of data within a raster formatted
display is governed by the timing of the raster sweeps.
To generate a "dot" at a given point it is necessary to
unblank the beam at the instant it traverses the specified address. As stated previously~ the Raster Format of
the display can be considered as an address coordinate
grid where the individual scan lines represent the ordinate values (Y -Address) and the points along the line
represent the abscissa values (X ·Address).
161
Spring Joint Computer Conference, 1969
162
By considering the relation between the scan rate of
the electron beam and the Cartesian address grid, it
can be seen that associated with any given picture element there is a corresponding X:- Y coordinate address
and vice versa. Thus by taking into account the number of lines preceding the addressed line and the number of elements on this line preceding the addressed
element, a given tiple interval after the beginning of
each frame can be associated with each picture element.
In this way D- V conversion can be considered as a
position to time conversion.
I
~
,....,,..1-,.
\JQI\..J.1.L
v.L.
Since the raster timing must provide overall control
of the conversion as well as display process, all digital
and display functions must be timed to the raster
synchroniza tion pulses or harmonics thereof. The sync
and comparator section provides this control interface
as well as provide the neceRRary timing signals internal to the converter. There are two primary ways of
providing the control interface. In the first, the raster
synchronization pulses are fed from the display device
to the sync and comparator section and the internal
timing for the converter derived from it. In the second
mode, the sync and comparator section of the converter
contains a crystal controlled clock \vhich operates at a
harmonic of raster timing, with the latter being derived from the crystal.
Under control of the sync and comparator section,
the data is transferred from the buffer memory to the
character generator where a dot pattern of the alpha-
J
Interface
Contro I
l
Sy nc and xComparator
y
Bit per elemept techniques of D-V conversion
One means of implementing a digital-to-video converter to provide the above type of position to time
conversion is the "Bit Per Element" converter. The
general functions of such a converter are outlined in
Figure 1. Input data is accepted from the data source
by the interface control in a word serial, bit parallel
form. This data consists of an X and Y address (es),
character code and control bits. Data format and parity
are checked and if proper, the data is transferred to the
buffer memory and process control. The buffer memory
is a small high speed digjtal memory (usually core)
which temporarily stores the character, vector, and
control data ill the same form as received by the interface unit. By means of the process control, the address
bits are separa ted and transferred to the sync and comparator section while the character/vector dat~ is held
in the buffer memor~-. If the data supplied from the
data source is not sorted (in X-Y address), then the
process control has the additional function of sorting
the address data in ascending orders of Y and X within
Ho ri z and Vert
Synch ron izatlon
DiQitol Data
y
Buffer Memory
and
I nterf ace
Control
Vector
Genera to r
Character
Gene rotor
I
Input
Memory
Control
J
DiQital
l
Output
Video
Memory
,
Memory
Outp u t
Co ntro I
Video
Figure I-Bit per element digital-to-video converter
numeric symbol, etc .... to be displayed is formed.
This dot pattern is then transferred to a section of the
video memory determined by the display coordinate
address. In the case of a graphic segment, a single dot
is generated at each of a series of coordinate addresses
with the group or sequence of dots forming the graphic
figure.
The video memory contains one bit of digital storage
(1 = unblanked electron beam, 0 = blanked electron
beam) for each picture element on the display surface.
Thus by loading the dot pattern of the character at a
Computer Generated Graphic Segments
memory address corresponding to the display address,
the contents of the video memory bear a one-to-one
correspondence to the generated display. To maintain
display continuity and eliminate presentation of partial
characters caused by loading sections of characters during free memory cycles, loading of the video memory is
performed during retrace of the electron beam when it
is blanked from the display surface. The memOIY is
read out in synchronization with the beam, i.e., ever.f
bit is read out as the electron bea.m traverses the corresponding point on the display surface. To attain the
output speed required, it is necessary to perform multiple word read out, multiplex several tracks or lines, or
use very long word lengths. In each case the data is
read into a register for parallel to serial shifts. When
the serial bit stream is inserted into the synchronization and blanking interval, the video signal results.
Real time techniques of D/V conversion
An alternative method for implementation of D /V
converters are the "Real-Time" type represented by
Figure 2. The primary difference is the absence of the
large (digital) video memory to recirculate the "bit per
element" display at the 30 frame/sec refresh rate.
The data is transferred from the data source through
the interface unit to the buffer memory in a manner
analogous to the previous example. In this case, however, the buffer memory is of sufficient capacity to
store a complete frame in computer word form, e.g., to
present 1000 characters, each defined by three computerwords requires a 3000 word memory. The addressed portion of the stored words are continuously
compared to the position of the scanning beam. This is
accomplished by use of two counters controlled by the
raster synchronization pulses. One counter is advanced
by the horizontal synchronization pulse and indicates
which scan line (Y-Address) is being written. A second,
higher speed, counter advances by M for each horizontal sync pulse, until a number corresponding to the
number of picture elements per line is attained. In this
way the second counter indicates the picture element
(X-Address) being scanned. By continuously sampling
both counters, the screen address for any specified X-Y
Address can be obtained.
A given interval prior to coincidence (sufficient to
account for propagation delay) the synchronization and
comparator circuits transfer the character data from
the buffer memory to the character/vector generator.
A dot pattern of the character/vector is generated at a
bit rate sufficient for insertion directly into the raster.
Thus the data is transferred directly from the character/vector generator to the display device by means
of high speed register without the requirement for a
163
Horz ond Vert
Synchroni zotion
Dioital Data
Interfoc e
Control
Sync and X-V
Comparator
Buffer
Memory
Process
Contro I
Vecto r
Generator
C harocter
Generator
Output
Contro I
L
I
J
Output
vi d eo
Figure 2--Real time digital-to-video eonverter
digital video memory. This sequence is performed at a
30 frame per second rate since no digital video memory
is available for display refresh. Erasure of the data is
accomplished by inhibiting the data output from the
character/vector generator and entering new data into
the digital memory. In the use of the bit per element
converters, a specific erase function (which amounts to
entering the complemented character dot pattern) must
be provided to remove the displayed dot pattern from
the digital video memory.
Straight line generation
The complexity involved in generation of graphic
segments in a raster format can be seen by considering
the straight line vector as shmvn in Figure 3. It is desired to generate a line connecting points (Xl, YI ) and
(X2, Y2) where the Y values represent raster lines and
Spring Joint Computer Conference, 1969
164
X,V,
T~---- - - _
.illY'
V
z
Y,
--
--____
•
:::;:.::;".' :: -
.
/ " Troce
--___
Usi",;! Increment
Rounded To Neorest
--
=
:~
based upon a "best fit" technique minimizing the error
with respect to the desired line, introduced with an
incrementation in either the X or Y direction or both.
The main functions to be performed by any straight
line algorithms are:
InteQ,r
1. determination of direction, right or left, which
controls whether incrementation or decrementation, respectively of the X address coordinate
is required.
2. determination of whether the angle of inclination
is greater than, less than, or equal to 45°.
3. determination of the DELTA segment length.
4. generation of a "dot" at the sequence of points
between (Xl, Y1) and (X2, Y2) within the const.raints previously listed and in accordance with
the above data.
X z Yz
Error
I·
IError I
·1
Figure 3-8traight line segment in a raster grid
the X values represent picture elements within a raster
line. If the lines were horizontal, vertical, or 45 degrees,
the generation would be trivial. Without loss of generality, the analysis which follows is for a line directed
down to the right at an angle, a < 45° as shown in
Figure 3. (A similar type of analysis could be performed
for any other octant.)
To form a trace at an angle a < 45°, the address of the
generated dot must be increased by a given number
of units (called the DELTA value), in the X direction,
prior to a one-unit increase in the Y address. For a line
at an angle a > 45°, the address is incremented DELTA
units in the Y direction prior to a one-unit increase in
the X address. The key to generation of the proper line
thus lies in the choice of the "DELTA" value. If
DELTA is set equal to the slope,
then the error is equal to the remainder (R) of the
integer division. If the DELTA is set equal to Q
rounded to the nearest integer, then the error equals R
if R < aY/2 and equals (aY - R) if R ~ aY/2. In
general, if the slope Q is used to determine the DELTA
value, then to obtain a zero end point error requires R
increments of DELTA equal to (Q + 1) and (aY - R)
increments DELTA equals to Q.
This yields
LlX= (Q+l)R+(aY-R)Q=QaY+R (2)
which is the condition for zero error. However, it is a
formidable task to obtain a line with acceptable linearity and no end point error when computations are
based only end point data, since the technique for
intermixing the two different length DELTA segments
resulting in a zero error is dependent on the particular
end points in question. Thus the approach adopted is
The DELTA value is based upon a determination of
whether incrementing the current address (X" VB)' in
the X direction, Y direction or both will result in the
smallest deviation from the desired line. By summing
the number of unit incrementations in a given direction, X or Y (which corresponds to the number of
iterations prior to sign change), the DELTA length can
be determined.
Let the coordinate grid of Figure 4a represent the
raster coordinate grid in the vicinity of the start point
X. Y The actual trace represents the sequence of
points which most closely approximates the desired
line connecting Xs Y and XI YI (not shown). The inclination with respect to the 45° line (determined from
and aY) imposes a limitation upon the degrees of
freedom of movement. Referring to the case depicted
in Figure 4b, it can be seen that the possible new
addresses are point. ] (Xl! + 1; Y.) or point 2
B.
B
ax
xv.
S
y
s/"
,
341
~, ~
'"
y 341
y
345
~.
'"",,,
y 343
y 344
"""-
~
I
~,
\1'
I
~
I
~h
V
~
d
'~ ~.Desire
yac e
~
'",",
Figure 4A-Coordinate grid as utilized in delta suhroutine
Computer Generated Graphic Segments
165
2AY
AX
flY
AX
2 AY-AX
~i---~-dx2 AX- lAY
AX
/
Desired
Trace
Figure 4C--8econd move determination in grid structure
Figure 4B-First move determination in grid structure
x s+ I
XS+2
24Y
(X, + 1, Y 8 + 1). If the error associated with each
move is represented by A or B respectively, the geometric relationships allow the ratio of the error values
to be determined as
I-lll.
4)(
24)(-24Y
X=
4)(
,
YS+2
B
(3)
If the condition of equal error is chosen as the discriminant point, a value Rl can be defined such that
Rl = 2LiY - LiX
(4)
where the sign of Rl indicates the minimum error move
to point 1 or point 2. (In Figure 4b the minimum error
is to point 2.)
Referring to Figure 4c to consider the second move
determination involving error distances C and D, the
same analysis yields an Rl discriminant value
RI = Rl
4)(
+
2LiY - 2LlX
the previous point with the value dependent on
both the previous point and the slope.
c. All moves to new addresses can be made, based
upon the sign of the error term.
The form 9f the general equations is based upon
inclination:
a. If the angle of inclination is
(5)
If the initial address modification from X8 Y had
been to point 1 rather than point 2, the RI for the
subsequent move, Figure 4d discriminant, would assume
the form
II
RI = Rl
Figure 4D---Alternate second move determination
+ 2LiY
a. After the first move from point X Y B, all subsequent moves reduce to one of the two above
cases.
b. The form of the error equation is dependent upon
(7)
2LiY - LiX
and
RI+1 =
(6)
In both cases the sign of RI would determine the
minimum error move.
If this analysis is pursued to the general case including inclinations both greater and less than 45°, the
following results are obtained:
=
Rl
< 45°, then
{
RI
t
RI
+ 2LiY
2LiY - 2LlX
if RI 2: 0
(8)
<0
(9)
if RI
b. If the angle of inclination is >45° the roles of X
and Yare interposed and we obtain
Rl
(10)
= 2LlX - LiY
and
8,
RI
RI+1 =
{
RI
+
2LlX - 2LiY
+ 2LiX
if RI 2: 0
(11)
<0
(12)
if R I
166
Spring Joint Computer Conference, 1969
The resultihg equations (Equations 7, 8, 9, 10, 11,
and 12) can be employed to determine the length of the
DELTA segments by noting the number of iterations
performed on RI + 1 between sign changes. Proper
initialization based upon inclination with respect to the
45 0 line allow use of the following equations which are
independent of line inclination:
Rl = 2T [2] - T [1]
RJ+l
fRI + 2T [2] = i
lRI
+ 2T [2]
2T [1]
(13)
if RI
~
if RI
<0
0 (14)
(15)
Each iteration of RI ~ 0 increases the current address
by one in both the X and Y directions. Each iteration
of RJ < 0 increases the X Address by one, while holding
the Y Address constant. Summation of the iterations
RI < 0 prior to each RI 2:: 0 yield the DELTA value.
This algorithm was verified by means of a computer
program to generate straight lines connecting any two
points within a 525-line raster grid.
The constraints placed on the straight line generator
routine were the following:
1. All vectors will be generated in the direction of
increasing Y address with the origin of the
coordinate system at the upper left-hand corner
of the display. (Addresses need not be sorted for
input.)
2. All vectors will be processed (although not
specified) as one of the following:
a.
b.
c.
d.
e.
f.
g.
Down to the left at an angle <45 0
Down to the left at an angle >45 0
Down to the right at an angle <45 0
Down to the right at an angle >45 0
Horizontal line
Vertical line
Down to the right/left at an angle = 45 0
Typical results are depicted in Figure 5. The routine required approximately 370 instructions in a
machine with a 64 instruction repertoire. The maximum error from any computed point to the desired
line is less than 0.5 units.
Circular line generation
In a manner similar to generation of a straight line,
the generation of a circular trace consists of determining the X- Y Address points which minimize the
error distance from the desired trace to the selected
point. By examining a circular trace overlaid on a
Cartesian grid, many of the properties of the circular
Figure 5- -Line segments generated hy eomput.er program
symmetry are observable. A circle of radius 7 is depicted- in Figure 6, together with the appropriate x- Y
Address sequence to generate the trace within the
constraints of the grid structure, where the Y-Address
corresponds to scan lines and X-Address to picture
elements along that line. The display trace ,vould bE'
generated by a" dot" (the area of which is equal to a
unit square) at each arrowhead.
It can be seen from Figure 7a (and is equally true
for any radius) that the address sequence from 1 to A
is exactly equivalent to those from 1 to D, 2 to A,
2 to B, 3 to B, 3 to C, 4 to C, and 4 to D. Thus by
determining the proper address sequence for the first
octant, the address sequence for all other octants (referenced to the center of the circle) have been obtained.
It should also be noted that no point is more than one
unit removed in each direction from the previous or
subsequent point. Two possible address modifications
can be determined for each octant, the first of which
modifies only one address (X or Y) by one, while the
second modifies both X and Y addresses by one. The
octant in question determines whether the address
modification is an incrementation or a decrementation.
The possible address sequence for each octant are de-
Computer Generated Graphic Segments
167
picted in Figure 7b. Using these address sequences, it is
apparent that each move encompasses a point exterior
to the circle and a point interior to the circle. Table I
\
OCTAN,.
OCTANT I
4
FigUJ'e 7B-Computational model for first octant
OC TAN T
OCTANT
5
represents the various possible moves for each octant,
where (X Y n ) represents the point from which the
move is being made and the columns are the resultant
addresses after the move is made.
8
lI
OCTA NT
6
OCTANT
,
7
Table X- Y-Address modification pattern
I.
Exterior
Interior
Octant# X-Address V-Address X-Address V-Address
Figure 6---X- Y addreHs sequence for generation of a eircular traee
1
2
3
4
5
6
7
8
f
r
,L
OCTANT 4
OCTANT I
I t
OCTANT
OCTANT 8
..J I
5
X
X" +
X,,X
X
X
X" +
X"
1I
1
1
1I
1I
1I
1I
1I
1I
-
Y" - 1
Y
Y
Y
1
Y" + 1
Y
1
1
-
1I
Y"
Y 1I
X" - 1
X" + 1
X
1
X + 1
X" + 1
X" - 1
X + 1
X
1
lI
-
1I
1I
+1
1I
-
Y" - 1
Y1l + 1
Y" + 1
Y" - 1
Y +1
Y" - 1
Y
1
Y" + 1
1I
1I
-
The problem then is to determine in each case,
whether a move to an exterior or an interior point
represents the minimum error. This can be accomplished by comparing the differences bet\veen the actual radius (Ro) and the external and internal radii
(Re and R i ) respectively, as shown in Figure 7b. If it
is determined that
(16)
then the minimum error move is to the next exterior
point. Likewise if
Figure 7A-- -X- Y addl'eH;; sequenee for eac-h oetant
(17)
168
Spring Joint Computer Jonference, 1969
then the interior point represents the minimum error.
From Figure 7b it can be seen that
~
Rn
= v'An2
R. =
V'An2 +
RI =
V' (An
(Bn
- 1)2
+ Bn
2
(18)
+ 1)2
(19)
+
(Bn
+ 1)2
(20)
Substituting Equations (19) and (20) into Equation
(16) yields
2Ro> V'An2 + (Bn
+ 1)2 + V (An
- 1)2
+ (Bn + 1)2
(21)
By means of the Triangular Inequality this yields
In a similar manner, Equations (17), (19), and (20)
yield
4Ro2< (2An - 1)2
+ (2Bn + 2)2
(23)
Thus if we define a quantity Q such that
Q = (2A" - 1)2
+ (2Bn + 2)2
- 4Ro2
(24)
then the sign of Q determines whether the minimum
error move is exterior or interior, with Q < 0 denoting
an exterior point and Q ~ 0 denoting an interior point.
Due to the symmetry of the trace, it is only necessary
to determine the move pattern for the first octant and
use this result to perform the address modification for
all octants.
This algorithm was implemented and found to yield
circular traces (Figure 8) in which no computed element is in error by a distance of more than 0.5 address
units in either direction, i.e., interior or exterior. The
generation of circular arcs is accomplished by the same
algorithm by merely specifying data to define the end
points.
It should be noted that for circles with sufficiently
small radii « 4 units) the appearance of uniform curvature diminishes. This is due not to a failure of the
routine but to the fact that for those radii, insufficient
points within the grid structure exist to properly define the curvature. It can be shown that the algorithm
itself is valid for all radii greater than 1.25, with this
lower limit being dictated by the lowest value of R for
which the use of the triangular with Equation 21 remain vHlid,
Figure S-Circular t.races generated by computer program
Parabolic line generation
The generation of parabolic trace within a raster
format under computer control is accomplished in
much the same way as one would generate the trace on
linear graph paper. A set of X-Y axes are assumed and
for selected values along the Y axis, corresponding
values of X are computed according to the defining
Equation.
X 2 = 4PY
(25)
Similariy for selected values of X, one can compute
values of Y according to the Equation
y2 = 4PX
(26)
The difference in method of generation arises in that
the trace on the graph paper is obtained by connecting
Computer Generated Graphic Segments
the points defined by the computation, whereas within
the raster the increments for the independent variable
are chosen to be one line width apart and thus by
merely generating a "dot" at the computed X-address
points, a continuous curve results.
A typical X-Y address sequence for generation of a
parabola is depicted in Figure 9. The actual trace would
be created by generating a "dot" at each arrowhead.
A. It.nrll1O'n
}l.c1c1rp.~~
~p.Ollp.ncp.
will varv
denendin!!.'
..........
"" ...... - - 0 ...... t.np
_.-.... --- --- .,."
upon the focii value (P) several important factors can
be deduced from the figure. The move pattern is up with
increments to the right and left. The number of increments in a given direction is dependent upon the square
root for value of independent variable in relation to
the square root for the previous value of the same
variable. For each increment in the Y direction if
-~------
-,L-
~
.
a
1.
0
< [y4PY
1I
2. 1/2
3.
1
y4PY1I - 1] :::; 72
then Xn = X n- 1
-
< (y4PYn
< [v!4PYn
y4PY1I-l] :::; 1
then· Xn = X n- 1
-
-
y4PYn - 1] < 1'1
then Xn = X n - 1
+1
+
lVI
The third case depicted will occur near the base of the
parabola with case (1) prevailing as the parabola approaches its asymptote. Since the parabola approaches
an asymptote which tends toward infinity, the trace is
continued until a screen address is exceeded in one
direction at which point the computation stops. The
proper incrementation address sequence is dependent
upon the form of the equation, the sign of P, and the
relative values of the square root for succeeding values
of independent variable. The incrementation conditions
for all cases are depicted in Table II where (Xn, Y is the
point being computed, while the value along axis of
symmetry is incremented by one unit.
TI )
The implementation of an algorithm for performing
the above arithmetic and manipulative function is not
complex. However, the computation time becomes very
large for all cases except where the length of the axis of
symmetry is kept small. This is necessitated by the
iterative methods required for computation of the
square root. When implemented on a computer with a
six (6) microsecond cycle time, running times in excess
of 30 seconds were not uncommon. However, the accuracy obtained placed each computed point within one
half display element, since the X (Y) address points are
computed for each Y (X) address. The question immediately arises that if the accuracy specification is
relaxed and an approximation to the parabola (as it
approaches the asymptote) is acceptable, can an appreciable decrease in running time be obtained?
If, for example it is assumed that beyond a given
point(Xp, Yp) (Figure 10) the parabola can be approximated by the straight line (X p, Y p), (X2, Y2) a maximum error E would result at the point the trace
reaches the maximum address or edge of the screen. In
addition, to maintain the trace uniformity, the slope of
the approximating line is chosen to be the same as
the slope of the parabola at the point (X p, Yp). The
slope of the parabola at X p , Y p is
y- A .. i,
\ /
169
.,,'0';.";0'
Xp
dy \
dx yp = 2P
(27)
Since this also represents the slope of the approximating
line,
\
then
X
Ay
2= 2P
~X
(28)
which yields
x
c
y
c
x - AlIi,
(29)
'Figure 9-X-Y address sequence for generation of a parabola
Spring Joint Computer Conference, 1969
170
Top
The value for Y2 is the STOP address of the axis variable
from which X 2 can ~e computed The approximation
can be completed by drawing straight lines between the
points (X p, Y p) and (X2 ,Y2) where X 2 = X 2 + E.
A similar analysis can be carried out for a parabola
satisfying the Equation
Of Display Grid
~
x:. v:. I
flY
y2 = 4PX
yielding a defining Equation for Y p,
Where )(p
Xp
and
fx,
=
+
def~ned
as
EI=JIXZ+ El' - 4Pv,l
t
v,+ EI±JIY, + El'- 4PXZJ
Yp:
With
Yp are
The inclusion of the approximation as a subroutine,
to be entered if the allowable error is E > 0, results in
greatly reduced running times proportional to the error
allowed. In addition, the subjective appearance is
maintained (Figure 11) by retaining the desired curva-
the
Sion
,±)
dependent
upon
the focii
value
Figure l(}-Parabolic approximation model
but
and
Combining the above yields
The above equation (30) relates the acceptable error E
to the X address of each computed point (X p, Y p) and the
coordinate of the point at which the parabola reaches
the edge of the screen (X2, Y2)' By allowing the error to
be specified by the operator, it allows the choice of the
error specification in terms of percent of axis length,
percent of opening, absolute units, etc ... If we use the
defining equation for the parabola (X2 = 4PY) together with Equation (30), the value for Xp can be
determined as
(31)
Figure 11- -Parabolie tl'a('eH generated by eomplltel' program
Computer Generated Graphic Segments
171
Table II-Address modification pattern for parabolic trace
Defining
Equation
P
Axis of
Symmetry
X2 = 4PY
X2 = 4PY
POSe Y
> 0,
~
y2 = 4PX
Left Side
Right Side
X,,~X"_l
XlI~X_l
X,,~X_l+l
X,,~X_I+1
"
> 1/2, ~ 1
> 1, ~ M
> 0, ~ 1/2
"
> 1/2, ~ 1
> 1, ~ M
>0
1/2
Top
Bottom
Axis
"
"
X2 = 4PY
1/
Neg. Y
Axis
1/
1/
1/
"
y2 = 4PX
"
"
>0
"
POSe X
>0
--.,.~
Xn~X_l
Xn~X_I
Xn~X_I+l
Xn~X_I+l
y
X,.~Xn_I+M
> 0,
~
.+M
X ii+-X,,_l+M
~y
"""-.3Irrr..1j-l
n~X_I+M
Yn~YlI-l
1/2
Y"~Y"-l
Axis
"
"
y2 = 4PX
"
"
"
Neg. X
Axis
"
"
"
> 1/2, ~ 1
> 1, ~ M
Yn~Yn_l+l
Y"~Yn_l+1
Yn~Yn-I+M
Yn~Y"_l+M
<0
> 0, ::; 1/2
> 1/2, ::; 1
> 1, ::; M
Yn~Yn-1
Y"~Yn-l
Yn~Y_I+l
YII~Y_I+I
Y,.~Yn_I+M
Yn~Y"_I+M
II
1/
1/
"
ture at the vertex and use of the straight line approximation as the parabola approaches the asymptotic
value.
c. Circular Arc -Center Point (Xc, Yc), Radius,
Start Point (Octant, Y Add)
Stop Point (Octant, Y Add)
Many other graphic figures could be generated by
using the "error minimization" technique above; however, their utility would depend upon the system in
question. The figures developed thus far (straight line,
circle, circular arc, parabola, and parabolic arc) form
the basis for a rudimentary system. The more important
aspect from a user point of view would be the combination of the various segment generators for complex
figures.
d. Parabola
Raster graphic system considerations
To effectively utilize the algorithms thus far defined,
they must be incorporated as part of an overall graphic
system or subsystem which includes the Graphic Segment Generators as well as a Graphic Operating System.
In configuring the combined Segment Generator, it is
assumed that the Operating System would provioo the
following data in addition to the segment type designator:
a. Straight Line-Start Point (Xl, Y1), Stop Point
(X2, Y 2)
b. Circle
-Center Point (Xc, Yc), Radius
(R)
-Vertex (X"' Y v ), Focus (P),
Orientation (H or V), Axis Stop
Point
e. Parabolic Arc-Vertex (Xv, Y v), Focus, Orientation, Side, Axis Start, Axis Stop
The Generator would be entered from a Graphic
Operating System and upon completion of its processing
function would return control to the operating system.
I~ addition, all data points would be entered through
the Graphic Operating System which would control
storage and output of the calculated points as well.
The routine is entered at the same point for any of the
segments and branches to the desired section (Straight
line, Circle, etc ... ), based upon the mode bits of the
data words.
The" move discriminant" functions are the same as
previously derived and must remain separate entities in
the combined program. Fn each case, a determination is
made to increment or decrement the variables X and Y.
In general, N incrementation or decrementation will be
performed upon one variable for each increment or decrement of the other variable, where N is calculated by
the respective discriminant function.
Typical program length on a six-microsecond, 64Instruction Set computer, by function:
172
Spring Joint Computer Conference, 1969
Functional Sections
Discriminant-Straight Line
-Circle
- Parabola
Incrementation/Decrementation
Iteration Control
Overhead
Locations
60
50
70
250
75
350
The size of the output block set aside for storage of
the calculated points depends upon the system in question. For example, if the converter being driven requires
three computer output words to describe a symbol, then
1200 storage locations would describe 400 symbols to
the converter. The size of this storage block is one reason
for considering hardware methods of graphics generation as an alternative to software.
The running time for generation of any given segment is directly proportional to the dimensions of that
segment since the relative size determines the number
of iterations required and all computer instructions
execute in equal time.
In the construction of complex figures from simple
graphic segments many geometric constructions (Tangents, Normals, etc .... ) appear often enough to warrant inclusion in the Operating system. In general, this
amounts to calculating a new set of defining parameters
based upon the segment (or segments) already generated and new segment to be generated.
The following have been investigated and found to
produce desired results with minimum software (Figure
12).
1. Head-to-Tail straight lines.
2. Parallel lines.
3. Perpendicular line from a Point Xp Y p on a line
(L).
4. Perpendicular line from a Point Xp Y p to a line.
5. Tangent and Normal to a circle.
6. Tangent and Normal to a parabola.
It has been found that if the desired segments are
defined in terms of critical parameters much of the
manipUlative software developed for direct writing
systems is applicable, with the segments defined by the
manipUlated points being generated by the special
algorithms.
The entire question of number of segments, hardware
vs software generation, amount of manipulative capa-
Figure 12-Cam lever generated by graphic segment generator
bility, etc ... , in the final analysis must be determined
by the system in question.
REFERENCES
1 F G STOCKTON
x-v move plotting
C A C M Vol 6 No 4 April 196:3
2 BECKENBACK & BELLMA~
An introd'uction to inequalities
Random House ~ew York 1961
3 J H WILKE~SON
Rounding errors in algebraic processes
Prentice Hall Series in Automatic Computation
Englewood New Jersey 1963
4 K E IVERSON
A. programming language
K Wiley and Co New York 1962
5 F GRUEN BERGER
Computer graphics
6
7
8
9
Thompson Book Co Washington D C 1967
L L BRINER
A graphic information processing system
IBM TR-21197 March 1966
I E SUTHERLAND
Sketchpad: A ';nan rnachi'ne graphical communication system
Technical Report fJ 296 Lincoln Labs MIT Jan 1963
A D FALKOFF & IVERSON
The APL/360 terminal system
IBM Research Report RC-1922 Oct 16 1967
A D FALKOFF & IVERSON
The
~1P L
terminal system: instructi01".8 for operation
IBM Research Yorktown Heights New York 1966
Errors in frequencv-domain processine:
of images *
.&.,
.&
'-'
by GRANT B. ANDERSON and THOMAS S. HUANG
Mas8achusett8 Institute of Technology
Cambridge, Massachusetts
INTRODUCTION
Practical techniques for the determination of image
spectra have been developed and become popular in the
past few years. Both optical processing systems and
digital computers can be used to perform linear filtering
via the frequency domain. Optical processing systems
use Fourier-transforming lenses and coherent light.
Digital computer software uses the Cooley-Tukey
algorithm to advantage, while computer hardware must
be augmented by optical scanning devices that interface
with images. Processing errors arise in both types of
systems, but for different reasons. In this paper we
present some results concerning errors in the spatial
frequency domain.
Two-dimensional Fourie:r analysis
To facilitate later discussions, we shall review briefly
the key relations in two-dimensional Fourier analysis.
The Fourier transfonn of f(x, y) is defined as
F(u, v)
= J~
L:
f(x, y)
e- i2r (ux+1IJ1)
dxdy .
(1)
Fourier series may be used to represent f(x, y) in that
area. In particular,
i:: i:
f(x, y) =
m=-QO
am,n
= -1T:.:TlI
fTrt:
0
am,1I ei2r(m:.:!Trt:+1IJ1!T,,) .
(3)
n=r-CO
1'1'11 f(x, y) e-i2r(mx!Trt:+1IJ1!TlI) dxdy.
(4)
0
When f(x, y) is impulsive and of the form
M-l N-l
f(x, y) =
L: L:
m-o
n-o
(jm,lI
a(x - mT:!:, y - nTlI ) , (5)
where a is the Dirac delta function and T:!: = MT:.: and
Ty = NTy, then a discrete Fourier transform is appro- .
priate. The discrete Fourier transfonn of the discrete
function (jm,1I is given as
where k = 0, 1, ... , M - 1, and i = 0, 1, ... , N - 1.
The inversion relation is
The inversion relation is then given by
f(x, y) =
L: f~
(7)
F(u, v) ei2r (w:+111/) dudv .
(2)
If f(x, y) is nonzero only inside a finite rectangular
area 0 ::; x ::; T:.:, 0 ::; y ::; T J" then a two-dimensional
* This work was supported principally by the National Institutes
of Health (Grants 5 POI GM-14940-02 and 5 POI GM-I500602), and in part by the Joint Services Electronics Program
(Contract DA28-{)43-AM~2536(E».
Fourie:r trans!cmnation
Optical processing systems l
When a film transparency of complex amplitude
f(x, y) is illuminated with collimated monochromatic
light at the front focal plane of a double-convex lens,
the light amplitude at the back focal plane will be
17'<
174
Spring Joint Computer Conference, 1969
F(x/Ad, y/Ad) = F(u, v), the Fourier transform of
f(x, y). In this relation, x and yare spatial coordinates,
A is the wavelength of light, d is the focal length of the
lens, and u and v are spatial frequencies.
imately as independent noise that is being added to the
real and imaginary parts of the filter function.
Vander Lugt used a reference beam of coherent light
hi recording his complex filter on filnl. The function
recorded on film, which is non-negative, is
Digital processing systems
The Cooley-Tukey algorithm reduces the number of
basic operations in the calculation of discrete Fourier
transfonus from N2 to 2N 10~N, where N is the number
of sample points involved, and a basic operation is
defined to be a complex multiplication followed by a
complex addition.2 This time-saving reduction has made
the calculation of image spectra practical for digital
machines.
A device, which can act as an interface between
images on film and the digital computer, is needed as
auxiliary equipment. Precision flying-spot scanners,
such as the one built by Professor W. F. Schreiber at
M.LT., are ideal for this purpose. 3
Linear fiUering
Optical processing systems
The simplest optical processing system capable of
doing linear filtering uses two double-convex lenses and
two film transparencies aligned along a path of collimated coherent light. An input film is placed at the
front focal plane of the first lens, while the filter-function
transparency is placed at the back focal plane of the
first lens. The front focal plane of the second lens is
coincident with the back focal plane of the first lens.
When no errors are present, the light amplitude at the
back focal plane of the second lens, except for a possible
change of scale, is
g(x, y) =
11
00
00
-00
-00
F(u, v) H(u, v) e i2r (ux+ell) dudv ,
(8)
where H(u, v) is the filter function, and F(u, v) is the
Fourier transform of the input image.
Complex frequency -domain filters for optical filtering
may be made by varying the density of film according
to a desired magnitude function and varying the film
thickness to regulate phase. Practical difficUlties in
varying film thickness in this direct method have led to
the development of the methods of Vander LUgt, 4
Llhmann,6 and Lee.s These methods penuit complex
filtering using positive real filters. In the Lohmann and
direct methods, noise in the filter transparency can be
modeled approxinlately as independent white noise that
is being added to the magnitude and phase of the filter
function. For the methods of Vander Lugt. and Lee,
noise in the filter transparency can be modeled approx-
+ H(u, v)12
A2 + IH(u, v) 12 + AH*(u, v) ei2rGu
S(u, v) = IA ei2rau
=
+ AH(u, v) e- i21/"Gu,
(9)
where the asterisk denotes complex conjugation. The
impulse response of S(u, v) is
s(x, y) = A2o(x, y)
+ Rh(X, y) +
Ah( -x -a, -y)
+ Ah(x -
a, y),
(10)
where hex, y) is the impulse response of H(u, v), and
Rh(x, y) is the autocorrelation function of hex, y).
lVlultiplication of F(u, v) by S(u, v) corresponds to the
convolution of f(x, y) with sex, y). If f(x, y) and hex, y)
are of finite spread, then the constant a can be chosen to
produce the desired output g(x, y) without interference,
but displaced along the x-axis in the output plane.
The filter of Lohmann has only binary transmittance
values. Clear slits for light transmission are placed on
film to synthesize complex transmission functions. The
slit area determines the magnitude of light transmission.
Varying the slit position changes the phase of the light
transmitted through the slit.
Lee's method for producing complex filters on film is
similar to Lohmann's method, except that it provides
for a continuous variation in transmittance. Lee's filter
uses four non-negative sample points placed along a line
to construct a complex sample point. The positions of
the four sample points result in transmission phases
of 0, 7r/2, 7r, and 37r/2, respectively. By adjusting the
transmission amplitudes for the four points, any desired
complex transmittance can be obtained.
Digital processing systems
Linear filtering is accomplished on the digital computer by Fourier transformation, followed by multiplication, followed by Fourier inversion. Round-off error
occurs in this process. A crude model for the error is
independent white noise added during the computation.
Quantitative effects of frequency-domain errors
Additive noise
If independent noise is added to the real and imaginary
parts of F(u, v) [Equation (2)], then independent noise
Errors in Frequency-Domain Processing of Images
of the same power will be present in the reconstructed
image f(x, y) upon Fourier inversion. This is true
because of Parseval's theorem. In particular, independent white noise transforms to independent white
noise of the same power. Independent white noise added
to the magnitude of F(u, v) also results in contamination of f(x, y) by independent white noise. The model
of independent white noise can be used as a first
approximation for grain noise in film, and for round-off
error in digital computations.
f/>(u, v) for filters made by the direct method. Inaccuracy
in the slit positions has the same effect in the Lohmann
method.
When phase noise occurs, the filter function will be
given by
H(u, v) = \H(u, v)1
g(x, y) =
When Vander Lugt or Lee filters are used for linear
filtering, g(x, y) [Equation (8)] is contaminated by a
noise equal to
-00
L: L:
n(x, y) =
L: f~
where N(u, v) is the film grain noise added to H(u, v),
and is assumed to be independent. Under the condition
(12)
;
(13)
where R, is the autocorrelation function of the input
image f(x, y). Film grain noise causes errors in \H(u, v)\,
the magnitude of H(u, v), for the direct method filter,
while inaccuracy in the slit area has the same effect with
the Lohmann filter. In these cases the filter becomes
H(u, v) = {iH(u, v)1
+ X(u, v)}
ei2 THEN 'output G';
END FNO;
END CYES;
CNO: END SX;
END se;
END SY;
DECODING (WRITE)
INIT: 'input YIN';
IF SLIT THEN 'input eIN';
'input XIN';
IF NGL > 2 THEN 'input G';
SY: DO Y = YB BY LlY TO YE;
SETe:e = eIN;
IF Y = YIN THEN
SX: DO X = XB BY LlX TO XE;
IF X = XIN THEN
MOD: DO; 'modulate beam';
'input next coordinate';
IF 'coordinate is a new Y' THEN
NEWY:DO; IF SLIT THEN 'input eIN';
'input XIN';
IF NGL >2 THEN 'input G';
GO TO SETe;
END NEWY;
NOTNEWY:IFNGL >2 THEN 'inputG';
END MOD;
END SX;
END SY;
where (XB, YB) and (XE, YE) define a rectangular
area to be scanned at increments of (LlX, LlY). In
encoding each scan line is swept once for each of the
orientations between eB and eE, where Ae is the
orientation increment. Actual encoding takes place
only when the criteria is satisfied. In decoding, only
those scan lines which are specifically read in are swept
at the input orientation, and writing takes place (or
more generally, is initiated) only at those positions
which match the input coordinates.
NGL is the number of gray levels. If this number is
greater than two, additional encoding/ decoding is
necessary to obtain the gray levels. For NGL = 2,
the fact that the criteria is satisfied implies the gray
scale infonnation.
The most general coordinate string of an X-axis
scan has the form:
Y coordinate, 8, X coordinate; gray scale;
X coordinate, gray scale, X coordinate, gray
scale...
Y coordinate, e, X coordinate, gray scale, ...
Increlnent forlnat
The incremental string is composed of a sequence of
elements that can be interpreted either as a segment
vector or as an incremental command. The segment
vector is composed of two incremental displacements,
DX and DY, the corresponding signs for each displacement, SX and SY, and the 'beam condition.' DX specifies the number of unit cells the beam is to be displaced
in the X direction and DY specifies the number of unit
cells the beam is to be displaced in the Y direction.
The beam condition is given as being either on or off
during the move.
If (DX, DY) = (0, 0), the two signs, (SX, SY),
and the 'beam condition' are interpreted as an incremental command, where incremental commands have
the following semantics:
H
IT
Halt, close out the operation.
ITerate (magnify) the next segment vector.
The next two elements in the string should
be a count followed by a segment vector.
MB Modulate the Beam intensity (at a fixed
position).
NOP No OPeration
RGR Reset Grid Resolution
RSO Reset Stencil Orientation
RSS Reset Stencil Size and/or shape
RVB Reset Vector Begin point
The IT command with its count is equivalent to having
the same segment vector appear sequentially in the
string by the number of times given in the count byte.
If the displacement is (0, 0) the IT command is ignored.
The four commands that reset parameter values are
followed by string elements containing the new parameter values. The element format is the same as that
defined for the initializing parameter string.
For the incremental format (XD, YD) and (XE,
YE) are interpreted as defining a file area, outside of
which no recording (film) or displaying will be allowed
to take place. (XB, YB) becomes the initial point from
which the beam will start the first segment vector.
Figure 2 shows the use of incr~mental vectors with
the command RSS inserted at point P (between vectors
(2,2) and (3,1» and with command RGR inserted at
point Q,
Parametic Description of Scan-Display System
(XB)"B)
(6,1)
R
---IDEALIZED
SEGMENT
- - - - - . INCREMENT PATH
(IF DIFFERENT THAN IDEAL)
Figure 2-Segment vector plotting. Note change in stencil size
at P and change in resolution (unit cell) at Q
191
gross coordinate position (which can be interpreted
as a local 'benchmark'). One then has a localized grid
of mesh 2bl1+br where b r is the number of bits in the
vernier counter used to extend the gross resolution.
The smallest resolvable square has sides of 2- Cbfl+b r )
units and is termed a vernier basic cell. The remaining
bo bits in the vernier counter define the gross-vernier
overlap, or the maximum vernier window as having sides
of 2bo gross basic cells (see Figure 3) or 2Cbo-bg ) upjts.
The above discussion defines the design parameters
that determine maximum position resolution. Not all
applications warrant this maximum resolution. More
importantly one cannot contrive efficient scanningrecognition algorithms without a range of resolution
options. One clearly wants. independent choices of
resolution for the two axes, either because the application warrants it, or becuase the format warrants it, as in
the case when scanning in the coordinate format using
a slit-like sampling area.
The parameters p and q specify the sampling resolution as every 2p basic cells in the X -direction and
every 211 basic cells in the Y -direction:
ax
Resolution, sampling and scanning parameters
= 2p
basic cells
units
= 2pCb l1+k)
. Resolution
In order to encode a digital representation of an image
it is necessary to impose a grid and coordinate system
upon it. It is convenient to conceive the total image or
raster area as a unit square and to interpret the addressable positions of the image as fractional coordinates
ranging between 0 and 1. The mesh of the grid
superimposed on this range is then 2bfl where b g is the
number of bits used to specify coordinate position.
The smallest resolvable square has sides of frbfl units
and is termed a gross basic cell.
The aspect ratio of the raster area need not be 1 :
1. The physical interpretation of the basic cell will
more generally be a rectangle, hence the effective resolution along one axis may differ from that along the
other.
The adopted coordinate system-left-handed rectangular-is a natural one for most textual material
and also corresponds to standard video practice of
left-to-right top-to-bottom scanning.
In concept one achieves the physical limit of resolution by choosing b g sufficiently large. In practice this
is difficult to implement and one distinguishes between
a gross position counter specified by b g , and a vernier
position COlllter specified by b v • The vernier counter
has a sign bit, Stl, and is interpreted as a signed position
relative to the gross position. This is equivalent to
overlaying a vernier grid in the immediate vicinity of a
(1)
(2)
o
x .....
1
V
I
B
y
+
,
H±t- +
Ey
I
-J
L/
X8:
.101 •.. 1011101
;
GROSS COUNTER
bg >bo
I
I
I
I
I
I
I
I
I
I
I
1+111111111
-"'-"--y-J
bo
br
VERNIER COUNTER
bo =2
b,=2
Figure 3-Maximum vernier 'window area with respect to B
coordinate. Shown is an overlap of two bits (bo) and maximum
local resolution for a resolution extension of two bits (b,.)
Spring Joint Computer Conference, 1969
192
The gross/vernier selection determines k as O/b r • The
smallest resolvable rectangle is flX by flY units and is
termed the unit cell.
rr'l,.",
.L .l.lCi
~",,,~.j.~,,,~
n""''''-/-e''' ;'"
;nn
...a'YYlentarl
Ilt thp
nth
pV~~lJ~V.l~
\JVUJ..L\J .J.
.1.01
.J..1..LV.l.V.l...L.I.
UV'-A.
","",v
v ................ ..t'
.L....
r-----,-,---------~----------4~~
'-
-
~e
X
{'IT'
......
.&.
qth significant position of the gross/vernier counter,
hence the number of significant position bits is:
x
raster gross:
bg - p
raster vernier: b g + b r
y
-
p
For the coordinate representation it is desirable to
increase gross sampling resolution along the scan axis
while incrementing the position counter at the pth significant position as described above. This can be done
by interpolating between counter increments and
concatenating the be interpolation bits to the b g - P
significant counter bits. One then has for the coordinate
resolution:
coordinate
gross: b g
+ be -
,
y
SLIT:
SPOT:
Ls= MINIMUM
Ws =DIAMETER
p
significant
bits.
e
RELEVANT
A natural choice is to make be = b r since b r reflects the
physical limit of resolution.
Sample encoding
The maximum number of image density states for a
read command or recording beam intensity states for a
write command are indicated by the gray scale parameter, n. The number of encoded bits is interpreted
as 2", hence the number of possible states as 22.. , The
maximum value of n is specified as n max .
Triggering or filtering of output information may
be done by either a standa.rd level diRcriminator or by
a specially designed plug-in unit. The value "assigned
to the parameter T chooses between these two.
The parameter B8 will distinguish between the choice
of a standard size spot (~q gross basic cell in diameter),
and a slit or non-standard spot size. If the non-standard
option is taken, then the parameters u and v define
the sample width and length as 41.£ and 2t1 gross basic
cells respectively. The range of circular spot sizes can
be specified by u with v = O.
If the sample area is slit-like then the orientation
becomes significant. The unit of angle is the circle,
or radians/21r. The angular resolution is 2-b a units
where b a is the number of bits used to specify an angle.
The angular sweep Begin-End coordinates, (8B, 8E),
specify the range over which incrementing is to be
accomplished. The increment is defined by the parameter z as 8 = 2z-b a units. The slit is swept the length
of a scan line for each value of 8 in the specified range.
e IRRELEVANT
Figure 4-81itjSpot. geomet.ry
Figure 4 illustrates the /l:eometrical definition and angular reference.
Scanning rate
Sweep velocity will in general be limited by the
following:
1. positional digital-to-analog response time
2. maximum channel data transfer rate
3. number or bits of gray scale eucoding/ decodin~
Sweep velocity can generally be expressed as a function of the following parameters (see Appendix B),
where a constant clock rate for incrementing the positional counter is assumed:
vs =
C1 .
f(p,q,A) , g(DF, K, n, n max ).
Here f is determined by the scan axis and unit cell
selection:
f(p,q,A)
=
(I-A) . 2P .
ox +
A . 2q
•
oy.
The maximum continuous data rate is required for
the Raster format with n = n max , where g can be normalized as
g = Z-"max'
Parametic Description of Scan-Display System
The data per sample are higher for the coordinate
format, but the average data rate is normally less than
for Raster. (Otherwise the nnage would be more optimally encoded in a raster format.) Buffering is needed
to handle local bursts of perhaps three or four consecutive samples. The amount of data for coordinate representation are essentially (though not absolutely)
independent of the number of bits of gray scale encoding/ decoding.
For an X-axis scau at constant sample rate one then
has
Vs
=
C1 •
Z-nmax · 2P . 5x.
C1 can then be determined from the clock frequency.
This equation yields a constant sample rate with the
Raster format for any value of n.
Since the data per sample is 2n bits, one obtains a
constant data rate by introducing the quantity nmax - n
in the exponent yielding:
Here instead of incrementing the position counter
at the pth significant position, the burden on the positional D / A conversion is appreciably lessened if one
increments only at the [p + (nmax - n) ]th significant
position and interpolates to obtanl samples at the
(2 nmax-n -1) positions between counter increments.
The constant data/sample rate option for a given
resolution is then determined by the parameter K.
quence. The scan axis is specified by A as X or Y, and
S selects the scan line sequence as interlaced or sequential. These two parameters a10ng with the B-E combination completely determine the sampling sequence.
One obviously starts with the Begin coordinate and
terminates with the End coordinate, determining the
direction of sampling along a scan line. The hexagonal!
rectangular lattice option is defined by L as described
below.
The matrices in Figures 5 and 6 illustrate the sampling sequences for a scan direction parallel to the Xaxis on a Rectangular Lattice. The position of point
No.1 in the lattices is specified by the Begin Coordinates.
The End Coordinates specify point No. 42 in the Sequential case (Fi~e 5) and point No. 15 in the Interlaced (Figure 6) case. Since the Begin and End coordinates are constrained to be multiples of AX and
AY they will always be member points of the Lattice.
Figure 7 illustrates the relative positioning of points
and their sampling sequence for the two scan directions
on Hexagonal Lattices when line sampling is sequential.
The Hexagonal Lattice is obtained by shifting the
lattice points of odd numbered scan lines in the corresponding Rectangular Format by an amount AX/2
(or AY /2) along the positive scan axis. Otherwise hexagonal formats are analogous to their rectangular counterparts.
The Interlace option and the adopted coordinate
system are particularly suited for communication with
a standard video network through an analog-to-digital
interface. Figure 6 shows the relation between the
\Vindowarea
The term window was introduced above in defining
the maximum area that can be covered in a single operation with vernier resolution. Two pairs of coordinates
serve to specify the portion of an image to be scanned,
encoded and displayed. They are termed the Begin
coordinates (XB, YB), and End coordinates (XE,
YE), and are interpreted as defining diagonally opposed
corners of a rectangle. Since the position counters may
be decremented as well as incremented anyone of four
B-E combinations may be chosen to specify the same
window area. This feature and the coupled-uncoupled
option of the monitor position counters allow the Rotation Group transformations described below. The
coordinates must be multiples of (~X, ~ Y).
Scan format (lattice and sequence)
. . .
2
·
3
4
5
•
8
Y!
15
·
22
.
6
7
•
·
·
0
14
j
6X
1
O'E]
L
CELL
21
2
28
3
.
·
35
36
42
29
•
•
4
5
1
SCAN LINE NUMBER
SEQUENTIAL: LINE SEQUENCE IS
The scan fonnat, determined by the parameters L,
S and A, imposes a Lattice upon the grid in terms of
the un'tt cell and specifies the scan line sampling se-
193
0,1,2,3,4,5
Figure 5-Sequential scan along X-axis using a rectangular lattir·e.
(t1 Y = t1X)
194
Spring Joint Computer Conference, 1969
. .
I
FIELD 2
2
I
I
o
o
o
•
2
•
·)V
•
,
o
vr
L___
21
.35
SCAN
LINE
NUMBER
:
G)
2~---3--__4-----5-----6~.4--~1
,u--~---r21
.1
LINE NUMBER_x'_"_ _ _ _ __
INTERLACED: LINE SEQUENCE IS 0.2,4.1.3.5
31.
16!
I
I
~
.17
.3
--~--
.4
.1-
.5
.25
Figure 6---Interlaced scan along X-axis using a rectangular lattice.
(b)
35.
•30
10
(~y = ~X)
PARALLEL TO
V- AXIS
Figure 7-Sequential scan along (a) X-axis, and (b) Y-axis using
a hexagonal lattice. The hexagons around point 11 in (a) and
point 17 in (b) illustrate neighbor points. The dotted
rectangle.."l Rhow neighbor points in the eorresponding
rectangular lattice. (~y = ~X)
.
2
o
3
't----
4
5
. .
6
7
1
I
I
I
e
1
1
I
14
.~
i
I
I
I
I
V ideo compatibility
I
.
.. --I
I
15
2
When interfaced by a video scan converter the video
can be handled as a scanner. However, the
scan converter is not essential since the S-J\I-V Controller can be designed to satisfy the constraints of the
video systems. The following discussion uses the parameter i to identify the v-ideo system within the network;
4
i
(a) PARALLEL TO X-AXIS
.2
fields and the sample points for the interlace option.
Lines have been drawn between points surrounding
point No. 11 in Figures 7(a) and 8 and point No. 17
in Figure 7 (b) to illustrate the concept of neighbor
points. An interior point of the Hexagonal Lattice has
6 neighbor points whereas that of the Rectangular has
8. Since the Hexagonal Lattice is not regular (it is
rhombic), although it is nearly so for dX = d Y (see
Figure 7), neighbor points are not all equidistant from
their interior point; but they always partition by
distance into two sets of 4 and 2 points each. Those
for the Rectangular Lattice partition generally into
three sets of 4, 2 and 2 points each, and for dX = d Y
the two sets of 2 and 2 become a single set of 4. Compare
Figure 8 with Figure 7.
2
3
·6
n~-twork
I
0
r -_________
30
4
~SCAN
o?
.29
3
10
x
Q9.11
'U.42Xj
· .
•
.22
2S
I
~
7
6
I
I
15
19
18
· .
5
r---1:~
8
17
o
4
3
.
21
I
3
I
2.2
•
•
LSCAN LINE NUMBER
Figure 8--8ame as Figure 7 (a) with ~ Y =
2~X
Parametic Description of Scan-Display System
it assumes the controlJer-video link to be direct and
develops the corresponding constraints.
Since the viedo 1ine sweep timf, Llt(i), is a fixed
parameter the number of data bits that can be transferred to or from core per full scan line is coilstrained
by the I/O channel capacity, where the maximum bit
transfer rate is f b• A buffer will allow a 'burst-mode'
sampling for some fractional part of the scan linehence higher resolution in sampling a vertical band can
be achieved.
The Incremental string cannot be passed directly to
video; it must first be passed to a scan converter.
The Coordinate otring with video has a resolution
along the scan line equivalent to Raster resolution
with n = nmax , hence the scan axis counter increment,
LlC, is given by:
Raster with constant data rate option:
Raster with constant sample rate and Coordinate:
Maximizing position resolution minimizes gray scale
resolution and vice versa. S(j,n) achieves its maximum
value for n = 0:
= S(j,O) =
Smax (j)
2'
A 1-1 correspondence between a full scan line at
video and the S-~f-V control grid requires:
S(j ,n) . LlX = 2bg basic cells.
One would nonnally choose the constant data rate
option. The Coordinate string resolution can only be
locally maintained because the buffer storage limits
the number of succe.3sive saIPples in contiguou~ unit
cells. This is not a severe restriction since the coordinate
representation is not very meaningful unless the image
is rather sparse. Note that orientation sampling is
meaningless with video.
The entire video discussion is from the point of view
of the Rastel' string representation. The stling win have
existence only when core memory participates; otherwise there is only the analog signal transfer between
the other three media. The resolution results are valid
independently of the point of view.
Substituting for S(j,n) from equation (4) yields:
(6)
This defines the achievable video resolution along
Table I-Inherent characteristics of three video systems and
maximum sampling resolution, Smax(j) , as constrained by
other media
i
N(~)
Horizontal (X-axis) resolution
To achieve a maximal uniform resolution across a
full scan line it is necessary to maintain a constant
data rate. We choose the largest j such that
(3)
and hence maximize and fix the number of bits in a
full line of sampling. Position resolution and gray scale
resolution are not independent: the number of bits per
sample is 2 hence equation (1) constrains the number
of samples in a full line to be
t1tCL)
}L-sec
~
56
1
525
2
1536S
~520
3
1536F
~
43
Smox( i )
1
512
9
4096
12
256
8
,
S(j,n)
= 2i- n •
(5)
Table I shows values of Smax(j) for three different
video systems. Parameter values used in the calculation
are given in Appendix C. If a window contains only a
fractional part of a scan line, then only a corresponding
fractional part of S(j,n) samples can he obtained along
each scan line.
Sampling at the position counter stepping frequency,
fe, maintains the aforementioned data rate for an
2 n max bit gray scale datum. An interpolation counter
is used to achieve the rate for other choices of image
density resolution with the constant data rate option:
LlC = 2P.
71
195
(4)
F= FAST SCAN
S= SLOW SCAN
196
Spring Joint Computer Conference, 1969
Table II-Maximum sampling resolution and interdependence of
position and gray scale resolutions as constrained by media
characteristics. The main entry is the maximum number
of samples per video scan line, S(j, n),and the value
in parentheses is the corresponding maximum
value of aX, (ax)mlU:(j,n)
which may be restated as:
CLlY) 17
g(j)
n
8
64
(64)
512
(8 )
( !6 )
(8 )
12
128
(32)
2048. 1024
(4 )
(2 )
64
128
(32) I ( 64)
256
512
9
3
2
I
0
4096
( 1)
256
(16)
32
(128)
4
2
1
I
f(j) . 2Il+ n -p,
where
f(j)
j
=
= r,,/r
B
•
N(i) . 2-i.
As in the discussion of horizontal resolution we wish
to approximate by powers of 2, and determine a g(j)
such that
0
-I
The video line sampling freqw:mcy is then determined
at the 8-l\1-V controller from
3
(LlY)" = 2Il+ n +oW-p
-
8
since the four terms in the exponent are defined by the
parameter assignments.
2 n , bits of gray scale
Media selection
scan lines as well as the largest useable sampling increment that may be associated with the 8-~1-V control
grid scan axis, Table II illustrates the interdependence
of position and gray scale resolution for the three video
systems of Table L It contains the values of 8(j,n) as
constrained by equation (4), and in parentheses the
corresponding maximum values of SX as given by
equation (6). All parameter values used are listed in
Appendix C. The function g(j) is explained in the
following section.
Vertical (Y-axis) resolution
::.vIedia selection is determined by the parameters
F, V and C. The choice of a Read or Write command
is then determined from the source-destination matrix
shown in Figure 9. Of the sixteen possible states for
F , V, C and ReadjW rite ten are allowed as meaningful
or useful, and this may be succinctly stated as:
States
4
4
Having determined the video resolution along a scan
line we now determine the vertical sampling so as to
achieve a unit cell match to the 8-::.YI-V control grid.
Assuming an X-axis scan at the controller, this constraint requires the video line sampling frequency to be
Source
(FEBV)
F
V
C
Destination
Command
(CEBC)
V.C
F.C
(FEBF) . (VEBV) .
READ
READ
WRITE
WRITE
Figure
15
16
16
17
whereEBmeans exclusive OR. As indicated these states
are illustrated in Figures 15-17. A destination medium
always exists since the monitor participates in all
DESTINATION
(LlY)t,
=
r"
-rs
N(i) LlY
. -8('
)' AV'
J,n LlA.
(7)
where r8 and rv are the aspect ratios at the control
grid ltnd video, respectively. N(i) is the number of
lines per video frame. The unit cell resolution ratio at
the 8-NI-V control grid is LlX/LlY, and the corresponding video resolution ratio is 1/8(j,n) N(i)/(.1Y)v. Using
equations (1), (2) and (4) equation (7) can be written as
SCANNER
SOURCE
VIDEO
r-N~R~
l~:RY'
MONITOR
MEMORY
:« W~ ~
R
R
W
R-READ
W-WRITE
Figure 9-Command matrix. Read/Write selection as a function
of Relected media and desired transfer direction
Parametic Description of Scan-Display System
operations. Whenever core memory (C) is not the
image source, display at the monitor or video can be
indefinitely repeated by setting the Regeneration parameter, J.
When transferring an image between two media, it
is necessary to consider:
a. the XjY aspect ratios, and
b. the XjY resolution ratios.
If either of these ratios differ, then a contraction quite
independent of any magnification can take place along
one of the axes. Both sources of image distortion may
be averted by matching aspect ratios of the unit cell at
source and destination media.. Since several media may
be involved it is useful to adopt the concept of an S-1\1V control grid and coordinate system through which
any inter-media transfer must pass, as illustrated in
Figures 14 through 17. One then forces a match between
each medium and the S-l\I-V control grid. All position
and resolution specifications in the parameters can be
interpreted as referring to the S-M-V control grid and
coordinate system. They must be specified with a
particular medium (or media) in mind, however, and
must be compatible with its associated characteristics.
Scanner and monitor are completely dominated by
the S-l\I-V Controller, hence the unit cell match is
easily accomplished. The same is true of core memory
as a destination mediwn. As a source medium the core
memory unit cell match is under program control, and
it is therefore necessary to associate inviolate unit cell
as well as other parameter information with any string
representation. Except for initiating a video scan, the
link between S-~l-V Control and video is basically an
information transfer link. The video match is effectively
accomplished by selectively transferring information
from video (say every other scan line) and by holding
back information to video (say blanking every other
scan line) by employing (.1Y)v as discussed in the
section on Vertical Resolution.
.
Extending this "match-to-control" concept allows
all the transformations (rotation, magnification and
translation) discussed in the following sections as well
as the dual interpretations of video as a source medium.
The entire transformation discussion is from the
point of view of gross resolution. Vernier resolution
differs basically in having an inherent magnification
of 211,. to both xfonitor and Video, and in having a
limited window area.
Monitor transformations
Information is communicated to the monitor during
each of the S-l\I-V operations. The area of interest
in an image is specified by a 'window' at the S-~l-V
197
control grid delineated by the Begin and End Coordinates. Three types of transformations may be applied
to the window as viewed at the monitor: rotation,
magnification and translation.
Rotation
The Rotation parameter, G, allows the option of:
(Rl) slaving the monitor to the S-1\1:-V Controller
grid in scan axis and direction or,
(R2) choosing the scan axis and direction at the
Monitor to be parallel to the X-axis and
incrementing irrespective of the Controller
choices.
When option (R2) is taken then scanning the X-axis
at the Controller grid obtains the transformations
shown in Figure 10, whereas scanning the Y-axis
yields the transformations shown in Figure 11. The
choice of a B-E orientation fixes the scan direction and
the initial scan line, hence selects one of the four
transformations. The four transformations in Figure
10 are called the "four group" of rotational synunetries
on the rectangle. The eight transformations in Figures
10 and 11 define the "Klein Rotation Group" of
symmetries on the square.
Magnification
The window displayed at the monitor can be magnified by factors of 2 with the parameter h subject to
the combined restrictions:
The underlying assumption is that the range of resolution options on p and q is identical at monitor and
scanner, and that the unit cell at monitor is magnified
by m = 2h.
One naturally constrains the choice of h to keep
the magnified window from exceeding the raster area:
m'
YB-YE ~ 1.
{I XB-XEI}
This restriction is refined in the discussion below on
translation.
Translation
Translation of the window at the monitor may be
achieved with the M on~tor Displacement Coordinates.
Spring Joint Computer Conference, 1969
198
TRANSFORMATION
SCAN
o
DISPLAY
X--+
--_:.!.--,-=------,
8
It
I
p'
IDENTITY
I
I
I
.~
II
.
[II
180ROTATION
8'
REFLECTION
11
8
8
11
I
E
ABOUT
VERTICAL
E
II
~.
8
REFlECTICW
I
HOiI~
i
I
5-M-V
CONTROL
E
E
,.
~
I
f4
I
O-r----__
r-I
E'
J
'
,,'"
I
y
~
I
I
I
I
I
I
L--"""'~~E
I~I------------------~
DARK LINE AND ARROW SHOW SCAN
AXIS AND DIRECTION
Figure l(}-Group transfonnations effected by the four different
Begin-End coordinate orientations with X-axis scan. (G = 1)
MONITOR
DISPLAY
TRANSFORMATION
8
II
,K
.~.
I
II
...• II ·r
REFLECTION
ABOUT
K-K
E
8'
REFLECTION
ABOUT
L~L
B
B
E
1
p
vf4
D
90- CCW
ROTATION
B
E
m
E'
E
If
I I
]
I
9O-CW
ROTATION
-
DISPLACEMENT}
BEGIN
COORDINATES
END
MONITOR MAGNIFICATION
-
-
Figure 12-Image translation and magnification at the monitor
B
IY4RK LINE AND ARROW SHOW SCAN
AXIS AND DIRECTION
Figure II-Same as Figure 10 with Y-axis scan. (G
=
1)
As shown in Figure 12, D transforms into (0, 0) at the
monitor, hence B is repositioned accordingly.
If a magnification m is superimposed on the translation it affects the area delineated by the D-E coordinates, hence the combined transformation is completely
defined as operating on the two vectors u and v:
1. translate the tail of u to (0,0) and
2. magnify the length of u and of v by m.
The four allowed orientations of D, Band E are
shown in Figure 13. The implied const.raint is that in
case (a) D ::; B ::;E with a corresponding interpretation
for the other three cases. D always transforms into the
corresponding corner position at the monitor with
Rotation option (R1). For Rotation option (R2), D goes
to (0, 0) at the monitor in all cases.
For proper centering, one must choose (XD, YD)
such that
m
(IXB -xEI +21xD -xBI ) =
1
m
(IYB - YEI +21YD -
YBI ) =
1.
and
Complete positioning freedom is not always possible
when combined with one of the· rotation transformations, e.g., when the window is very close to the edge
of the grid and the chosen tran.8formation requires D
to be on the edge side of the window.
Parametic Description of Scan-Display System
x
0
~
CONTROL
y
GRID
~
0
r-----~
I
0t"-----,
I B
:
U~E
I
~B!
_oJ
E
CORE MEMORY
S-M-V CONTROL
(b)
(0)
199
SCANNER
S-M-V
CONTROL
GRID
Figure 14-Monitor totally slaved to the source media
MONITOR
EWgj~~
As shown in Figure 14, the Controller can then avoid
the time-consuming redundancy of the transformation
steps inherent in a sequence of small windows.
I
I
I
I
0'
(e)
(d)
Figure 13-Four allowed orientations of D, Band E coordinates
with the corresponding monitor interpretation. (G = 0)
Totally slaved to scanner
When tracking a line or a boundary, by scanning a
sequence of windows, a 1-1 correspondence between
Monitor and source is desirable; otherwise the relative
positioning of windows at the source is not reflected
at the Monitor, and the tracking procedure cannot be
viewed. This can of course be achieved with the proper
parameter assignments as a standard transfonnation
but one would like to avoid the time involved in doing
so. Since the wi~dow will be small the scanning time
can be significantly reduced by recognizing a special
case. The following natural setting for the parameters
listed can be interpreted as defining the special case:
1.
2.
3.
4.
(XD, YD) = (0, 0), no translation
gross resolution
no rotation, option (Rl)
no magnification
Totally slaved to video
As indicated in, Figure 14, video is inc1uded in the
total slaving concept. For video this is accomp1ished
by replacing constraint (4) in the previous section with
the following:
(4')
h·
ax = axmax (j,n).
At most one window can be scanned per video frame,
thereby limiting the repetition rate.
Video transformations
The video network, unlike the monitors, can act
both as a source and as a destination. A window,
specified by the Begin and End coordinates at the
S-M-V control grid, determines the area of interest.
Transfonnations similar to those at the monitor can
be effected within the limits of the video constraints.
Source medium options
It is useful to distinguish two interpretations of
video as a source medium:
Spring Joint Computer Conference., 1969
200
r----------,
I
I
(81) l-lcorrespondence between video and the 8-MV control grid (excluding rotation), thereby
allowing translation and magnification of a
window to the monitor;
I
I
,
I
I
,
,
'
I
I
,
,
I
I
I
I
L~~_E_ ~~~~~: J
(82) 1-1 correspondence between video and some
portion of the 8-M-V control grid, effectively
allowing translation and demagnification of a
window to film.
......
~E
X2
hy
D
..
8
Options (81) and (82) are illustratfd in Figures 15
and 16 respectively.
S-M-V CONTROL
~-:e-'"
l~E
.....
...
..
0'
8'
...
~
xi hy
SCANNER
VIDEO
IX2h
Rotation
0'
When video acts as a destination medium, the
transformations are effected in the same manner as
they are to the monitor under option (R2). Because
the video scan axis and direction are fixed, option (Rl)
never applies.
When video participates as a source medium the role
is reversed and one always gets the inverse transformation to the 8-M-V control grid. If option (R2) is
chosen for the monitor the two transformations cancel
(into and then out from the control grid)-effectively
yielding the identity transformation to the monitor.
e'
f7777:l
I
I
Figure 16-Transmitting between scanner and video. Display
at the monitor 'with h = h"
Magnification and demagnification
Equation (6) defines (aJe)max (j,n), the largest useable
Choosing ax < (ax)max (j,n) allows So video
ax.
I
0'
D
~E
I
---~~,
o~-- ...
8~
l~
Figure 17-Transmitting from core memory to one or more
media. If to video, h = 11.
SCANNER
D"
---~,
~
:
8
I
magnification of
mv(j,n)
= (ax)~ (j,n) =
2hv(j,n)
J
~
80
Figure la-Magnifying a winduw at the munitor and/or
transmitting to core memory
hv(j,n)
=b
g -
j
+
n - p = Pmax (j,n) - p .
Paranletic Description of Scan-Display System
When video is a source medium m is a demagnification, and when video is a destination medium mv is
a magnification.
In the (SI) interpretation of video as a source medium
..:lX = (..:lX)max is assumed, and the monitor magnification is achieved in the same manner as when the
source is core memory or film scanner.
p
Translation
When video is a destination medium translation is
effected in the same way as it is at the monitor with
the rotation option (R2); (XD, YD) at the S-.:.\f-V
control grid transforms into (0,. 0) at the video. For
proper centering (XD, YD) is chosen so that:
mi>(IXB-XEI
mv(IYB-YEI
+ 2IXD-XBI) = S(j,n)
. ..:lX ~ 1,
+ 2IYD-YBj) = ll~~y~u(i) ~
1,
where Nu(i) is the number of useable lines per video
frame (or maximum (llY)l1 steps).
With video as a source medium translation to the
monitor is accomplished by associating (0, 0) at the
video with (0, 0) at the S-M-V control grid. Translation to the monitor then takes place in the usual way.
This is option (SI) and is illUstrated in Figure 15.
Option (S2) is accomplished by associating (0, 0) at the
video with (XD, YD) at the S-M-V control grid and is
illustrated in Figure 16. Translation to film then takes
place as the inverse of the translation effected when
the transfer is from film to video. Note that translation
to monitor and film cannot be effected simultaneously;
the options (SI) and (S2). are mutually exclusive as far
as translation is concerned-hence the distinction.
Totally slaved as a destination
Video is not likely to be useful for display under the
totally slaved concept, since this would constrain the
sampling increment to be
ilX = AXmax(j,n).
SUMMARY
This paper has developed the parametric description
of a general purpose Scan/Display System for image
digitization and display. Central to the system is the
S-~1-V Controller which can service either simultaneously or individually three distinct media: film,
closed-drcuit television and incrementally-driven CRT
displays. An adjunct of the system is a Video Com-
201
munications Net to provide both high and commercial
resolution service to remote users.
Media compatibility
The S-M-V Controller acts as a media-media interface that identifies the necessary information transfer
constraints or rejects the operat~on request as one
demanding inconsistent parameter assignments. Transfer constraints considered include XjY resolution
ratios, aspect ratios and line sweep times of the media,
and D-A/A-D conversion times. A constant data rate
option allows operation at I/O channel capacity for
all choices of gray scale resolution.
The digital encoding of an image generated in a
scanning operation can be retransmitted to the S-M-V
Controller for output (display)-and on any of the
three available media.
Rasters
By associating (X,Y) positions with binary counter
value pairs the controller can generate a family of the
two-dimensional regular lattices-rectangular and hexagonal. X and Y resolutions are independen,tly variable,
the allowed resolution values are in geometric progression and correspond to changes in counter incrementing position. A selected "window" of the full
image can be specified.
Sampling/display strategies
Three sampling formats (Raster, Coordinate and
Incremental) allow a variety of sampling/display
strategies. Raster format provides uniform sampling
of alllat~ice positions. For coordinate format however,
sampling takes place only at those lattice positions
where the image satisfies some criteria prescribed by
selection of a triggering/filtering circuit.
Incremental format is provided for segment vector
plotting. Conunands are provided for setting the
starting point, line width and plotting resolution.
Segment iteration can be specified.
The sampling beam stencil is variable in size, shape
and orientation. The shape options are spot/slit. The
slit option includes orientation resolution and range.
Metrological facilities
An optional local extension of position resolution
can be specified through a gross/vernier counter selection. With the vernier option selected, the gross counters define a benclunark while the vernier counters
represent a local displacement. Using this technique,
202
Spring Joint Computer Conference, 1969
positional resolution of 1: 30,000 is currently attainable
in flying spot scanning.
Implementation
The 11liac III computet' .10 employs a scan/display
system with parameters as specified in Appendix C
of this paper.
Except for the video scan converter, the microimage
storage and the video storage, the scan/display system
is anticipated to be operationa1 by Sununer 1969.
ACKNOWLEDGMENT
Many'stimulating discussions with members of the
Illiac III staff aided in the formulation of concepts
developed in this paper. :NIr. Robert C ...<\....~endola has
contributed significantly to the Video Network specifications and to scanner optical design. Dr. Kenneth
J. Breeding participated in the first design of a scanner
controller which was subsequently expanded into the
S-M-V controller described in this paper.
A description of the analog and digital logic design
of the scan/display system is now being prepared for
publication by Dr. James L. Divilbiss and Mr. Ronald
G. lVlartin, respectively.
The authors wish to thank ~1r. John H. Otten for
preparing the illustrations and :\1rs. Donna J. Stutz
for typing the paper.
REFERENCES
:l
3
4
f)
6
L A DUNN L N GOYAL B H McCORMICK
V G TARESKI
S-M-V programming manual
Department of Computer Science University of Illinois
Urbana Illinois March 1968
D M COSTIGA:.l
Resolution co;~siderations affecting the electrical transrnission
of technical documents by scanning process
National Microfilm Association Jour Vol 1 No 3 Spring 1968
B F \YADSWORTH
PEPR--a hardware description
Emerging Concepts in Computer Graphics Don Secrest and
Jurg Nievergelt (Eds) W A BenjamL.TJ. Inc New York 1968
R CLARK W F MILLER
Computer-based data analysis systems
Methods in Computational Physics Vol 5 Berni Adler
Sidney Fernbach Manuel Rotenberg (Eds)
Academic Press N ew York 1966
R B M ARR G RABINOWITZ
A software approach to the automatic scanning of digitized
bubble chamber photographs
Methods in Computational Physics Vol 5 Berni Adler
Sidney Fernbach Manuel Rotenberg (Eds)
Academic Press N ew York 1966
J VANDER LANS .J L PELLEGRIX
H J SLETTENHAAR
The hummingbird film digitizer system
SLAC Report No 82 Stanford Linear Accelerator Center
Stanford University Stanford California March 1968
7 R S LEDLEY L S ROTOLO T J GOLAB
J D JACOBSEN M D GINSBERG J B WILSON
FIDAC: Film input to digital automatic compuier and
associated syntax-directed pattern recognition programming
system
Optical and Electro-optical Information Processing Teppep
J Berkowitz D Clapp L Koester C and Vanderburgh Jr
(Eds) 1\1 I T Press Cambridge Massachusetts 1965 Chap 33
8 H KAZMIERCZACK F HOLDERMANN
The karlsruhe system for automatic photointerpretation
Pictorial Pattern Recognition G C Cheng R S Ledley
Donald K Pollock and A Rosenfeld (Eds)
Thompson Book Co Washington DC 1968
9 B H McCORMICK
Advances in the development of image processing hardware
Image Processing in Biological Science Ramsey D M
(Ed) University of California Press 1968 in press
10 B H McCORMICK
The illinois pattern recognition computer--illiac J I I
IEEE Transactions on Electronic Computers Vol EC-12
No 5 December 1963
APPENDIX A-DEVICE SPECIFICATIONS
Scanners
The scanners are flying spot scanning systems with
an added diquadrupole coil for astigmatic defocusing
of the spot into a line element to achieve a slit mode.
All scanners are capable of either scanning from developed film or photographing onto unexposed film. The
optical path of the beam is split, with one path transversing the film and the other path through a reference
grid to establish stability against engraved fiducial
marks.
Several types of media transports are provided to
handle the projected range of problems. A 70 mm.
scanner is provided primarily for 70 mm. negative
bubble chamber fihn. Here the format of the raster is
2.362 inches X 3.522 inches, and the minimum spot
size is approximately 0.001 inch at the film. Due to
the 1ength of the frame to be scanned, scanning is done
in two steps. The two horizontal halves of the frame
are scanned successively with a 4 mm. overlap to
establish half-frame continuity. Large motors are used
for slew and gross positioning of the film and a small
digital stepper motor is used for fine positioning of the
frame. Frame position sensing is accomplished by using
the digital stepper motor as a tachometer and by
counting sprocket holes. Total film capacity is 1000
feet.
A scanner for handling 47 mm. film is similar to the
70 nun. transport design except for the following:
The fi1m format is different. A friction drive is used
on the digital stepper motor, since the film is un-
Parametic Description of Scan-Display System
sprocketed. The frame position is determined by sensing
small index blocks at the lower edge of the fihn using a
fibre-optics light guide and a photodiode.
The microform scanner contains three units. The
first is a 35 mm. full frame digitally controlled camera
which can read light through the fihn both negative
and positive. The second unit contains a 16 mm.
Bolex camera for making computer-generated black
and white movies and a modified 16 rom. film editor
for scanning 16 rom. film of all types. The third unit
is a microfiche transport mechanism for scanning and
producing a single microfic.he in the 72 image COSATI
format. For the three different units the C.R.T. raster
is adjusted optically to fit the particular frame size.
A fourth type of scanner is built around a microscope
with a digitally controlled automatic stage. Positional
accuracies are on the order of ± 2 microns, and the
maximum slide area coverage is 1.2 inches X 1.2 inches.
Variable reduction is available from a four objective
rotating turret. Full visual observation is available to
an operator.
Monitors
The monitors consist of 21-inch cathode ray tubes
controlled in a manner similar to the scanner C.R.T.'s;
viz., digital position counters control the spot location
through accurate, high-speed digital-to-analog converters. The monitor counters are digitally controlled
directly from the S-M-V Controller via an incremental
communications scheme; essential1y the only commands
issued by the S-M-V Controller for the monitors are
increment the counters, decrement the counters, reset
the counters, and reset the parameters. Therefore,
any spot movement possible on a scanner C.R.T. can
be accomp1ished on the monitor C.R.T. The video
input for the C.R.T. grid is also synchronized by the
S-]~/I-V controller.
Included with the monitors for communications to
a central processing system are a selectric typewriter,
microtape input/output tape drives, and a light pen
for cursor control.
Video scan converter
The video scan converter consists of a high resolution storage tube capable of storing a useable picture
for at least 30 seconds. Multiple readouts can be made
from a stored image before degradation is significant.
The storage tube can be written into and read from
at any of the video rates in the system (525, 1536F,
1536S) on the video switching matrix side. On the
SMV control side the scan converter looks like a film
203
as seen by a scanner; therefore, reading and writing is
handled in exactly the same manner as it is in a scanner.
V ideo switching matrix
The video switching matrix is a mechanical cross
bar matrix. Therefore, the switching speed will be in
the order of 100 milliseconds or less. In this routing
switch any source can be switched to from one to tliree
different destinations simultaneously. In addition,
switching provisions are also included to mix any two
video sources to provide a composite signal to the
selected destinations.
Character generator
The Character Generator is designed to accept up to
512 ASCII characters i~to its 4096 bit memory. A 99
dot matrix, 9 dots wide by 11 dots high, is used to
develop each character into the appropriate video
levels. The maximum TV screen display is 16 horizontal
rows of 32 characters or spaces each. Alternatively
132 characters/line print-out can be generated on the
Videograph printer. A special cursor is also available
along with eight commands for controlling it.
The output composite video signal can be either
525 or 1536 lines per frame, depending upon the
externally supp1ied sync signal.
V ideograph printer
The Videograph Printer can print on demand at a
rate of 0.8 seconds per 8~ X 11 inch sheet. Horizontal resolution is 128 lines per inch and vertical
resolution matches the high resolution of the 1536
line slow CCTV cameras. Gray scale resolution is
limited to four shades. The paper used is inexpensive
zinc-oxide coated stock.
525 line T. V. cameras and monitors
The 525 T.V. Cameras and 11onitors are conventional
television units; namely, 525 lines per frame, 30
frames per second interlaced (60 fields per second).
These units provide for relatively low cost reduced
resolution, which is sufficient for many message routing
and simple acquisition and display purposes.
1536 F/ S cameras
The 1536 F /S cameras are vidicon camera units which
can be remotely selected to operate either in fast scan
mode (15 frames per second) or slow scan mode (1.25
frames per second). The format of either mode is 1536
lines per frame done in a sequential (non-interlace)
~4
Spring Joint Computer Conference, 1969
s~. The aspect ratio is variable, but it is set for a
nominal 8Y2 X 11 aspect ratio. The camera bandwidth is limited to 9.5 Mhz for fast scan and 1.4 l\1hz
for slow scan.
track video disk, where a single track can contain a
complete image. Input and output can be at either the
1.25 or the 15 frames per second rate with resolution
matched to the corresponding v-ideo devices.
Remote video consoles
Each remote console is a self-contained unit with
two video monitors and the necessary equipment for
conununicating with a digital computer. The video
monitors consist of a 17 inch 1536 lines per frame slow
(1.25 frames per second) monitor with a P-26 phosphor
and a 17 inch 1536 lines per frame fast (15 fra..rnes per
second) monitor with a VC-4 phosphor. Each monitor
matches characteristics of the associated camera.
Included with the console for direct digital communications to the central iomputer are a teletype
ASR-33 unit and a small special keyboard to be used
for frequently used machine orders. Other items to be
included with the consoles are a microfiche reader, a
digital patch panel for digital control signals, and an
analog patch panel for analog control signals.
Special plug-in options for a universal cursor control
could provide for such devices as a light pen, joy stick,
matrix pad, bug, etc. Other options could include provisions for direct handwriting of orders at the console
by T.V. camera pick-up and/or Rand tablet type device
and a monitor microfiche camera for filming images
from the C.R.T. screen.
Microimage storage
The Microimage storage consists of a microfiche
reader/access mechanism that is able to store, retrieve,
and display COSATI standard microfiche on demand.
Storage of the IPicroflche is by a rotary drum that is
a changeable unit. Images can be digitally selected,
and the display of any requested image requires less
than five seconds. Access time to an adjacent image
(Le., one within the same fiche) is less than two seconds.
The output is displayed in an 8Y2 X 11 inch format
if desired, and it is projected upon the two-inch vidicon
of a 1536 F /S line television camera for distribution
into the video network.
The drum holds 750 modified microfiche cards of
60 frames each. Each frame again contains an array of
7~ microimages or basically a standard microfiche.
Therefore, a single drum will provide storage for
3,240,000 page images. Readout from the selected
microfiche frame is accomplished with a fly's eye
readout mechanism.
V ideo storage
The video storage consists of an interchangeable 72
APPENXIX B-SYMBOL AND
LIST
PARA~1ETER
Parameter values assigned at design time
Parameter values explicitly assigned at
execution time
$
*
Upper case Latin
*A
*
ACW
B
Bs
BCW
*C
*
D
DCW
DF
DPB
DX
DY
E
Ell
ECW
*F
FPB
*G
*J
*K
*L
Ls
LPB
$ N(i)
Nu(i)
NGL
PW
*R
*S
Scan Axis selection
Angle Coordinate Word
Equivalent to (XB, YB)
Standard spot/nonstandard spot, or slit
selection
Begin Coordinate Word
}Iedia selection, Core memory
Equivalent to (XD, YD)
Display Coordinate Word
Data Format selection
Display Parameters Byte
X-component of the incremental format
Displacement vector
Y -component of the incremental format
Displacement vector
Equivalent to (XE, YE)
Same as E, to distinguish Vernier
End Coordinate Word
Media selection, Film (scanner)
Format Parameters Byte
Group rotation selection for the monitor
Display regeneration request
Constant data/sample rate option (for
a given p) with the raster format
Lattice selection
Length of Slit = 2" gross basic cells
Lattic'e Parameters Byte
Number of lines per video frame
N umber of useable lines per video frame
(or maximum (.6Y) v steps).
Number of Bits in a raster string representation
Number of Samples in a raster string
representation
Number of Gray Scale Levels = 22ft
Parameter Word
Gross/vernier Resolution selection
Sequence selection, sequential/interlaced
Parametic Description of Scan-Display System
S(j,n)
Smax(j)
*
SPB
SX
SY
T
* XB
* XD
* XE
XEv
* YB
* YD
* YE
YEv
::\1aximum achievable number of Samples
per full video scan line
Maximum value of S(j,n) (achieved for
n = 0)
Slit/spot Parameters Byte
Sign of DX
Sign of DY
Trigger (filter) selection for encoding in
the coordinate string representation
11edia selection, Video
Sweep Velocity
Width of Slit or spot diameter = 4u
gross basic cells
X-coordinate, Begin cell
X-coordinate, Displacement
X-coordinate, End cell
Same as XE, to distinguish Vernier
Y -coordinate, Begin cell
Y -coordinate, Displacement
Y -coordinate, End cell
Same as YE, to distinguish Vernier
Video magnification/demagnification =
2hv(i ,n)
*n
$nmax
*p
Pmax(j,n)
*
$ be
g(j)
k
m
q
$ r!.'
$ rv
* Sv
*U
$umax
*V
$vmax
*
Z
$
Zmax
2 n is the number of bits of gray scale
Maximum value of n
AX = 2P (see ~)
Maximum value of p for Video Network
= bl1 - j n
AY = 2q (see AY)
Aspect ratio] control grid (Standard)
Aspect ratio, video
Sign bit of vernier counter
Slit width is 4u gross basic cells
Maximum value of u
Slit length is 2" gross basic cells
Maximum value of v
e = 2z-b a (see Ae)
Maximum value of z
+
Greek
~t(i)
Lower case Latin
N umber of bits in the angle orientation
counter
Number of interpolation bits concatenated with the bg-p gross resolution bits
Number of bits in the gross position
counter
Number of gross-verrrier overlap bits
Number of vernier bits that extend gross
resolution
Number of bits in the vernier position
counter
Rweep velocity constant (with Cl = fe,
V s is given in basic cells per microsecond)
Maximum data bit transfer rate
Position counter incrementing frequency
Video unit cell match function = rv/rs
. XCi) . 2- i
Video line selection modifier. Closest
interger such that f(j) ~ 2g (1)
Monitor magnification = 2h
Maximum value of h
Video magnification/ demagrrification exponent (see mv(j,n))
Video system identification
Video system resolution parameter,
Smaxmax
qmax
y=Cl.I, """,7
ANGULAR INCREMENT - - - - - - '
t:.I'J =2'.2- 8
3
z:o:o,l, """ ,7
(d l
7
7
1:1 (but
variable)
3:4
Figure 19-Display (a), Lattice (b), Format (c), and
Slit/Spot (d) Parameter Bytes as defined for Illiac III
Umax
Vmax
Zma.x
slit width is 4u basic cells
slit length is 211 basic cells
angle increment is 2z-l'a units
3
7
7
Interactive tolerance analysis with
graphic display
__
_
...
If
by LAWRENCE A. O'NEILL
Bell Telephone Laboratories, Incorporated
Holmdel, X ew Jersey
INTRODUCTION
spread in each range that is dependent upon the manufacturing process and the component's age. Operat~g
conditions are usually introduced during optimization
as either typical or worst case discrete values, but more
realistic estimates of anticipated performance can be
obtained if the actual statistical distributions are taken
into account,
Tolerance analysis provides two primary sources of
inforI.l.latidn to the designer:
One of the principal advantages of a dedicated computer with on-line graphic display is that the user is
able to quickly and easily interact with the program.
The value of this interaction has been clearly demonstrated in the optimization of circuit and system designs.1.2 A related task on which interaction can have a
significant impact is the investigation of the influence of
parameter tolerances on the performance of an optimized design.
There are three basic approaches to computer-aided
tolerance analysis currently in use-moment method,
monte carlo approach, and worst case analysis. 3 •4 The
experimental approach presented here is a version of the
monte carlo approach in which performance distributions are acquired by randomly perturbing the parameters. It is economically feasible to accumulate distributions rather than just compute a few statistics
because of interaction and graphic display. The experimental approach is not subject to the linear assumptions
of the moment method and the performance estimates
are more realistic than those obtained by worst case.
The advantages of the experimental approach, in computational simplicity and in the nature of the design
information provided, are discussed and illustrated III
this paper.
1. Tolerance Specifications-The designer can speccify maximum tolerance limits guided by a prediction of the expected yield.
2. Design Information-The designer can select
among alternative realizations based either on
which is less sensitive to expected parameter
variations, or which will be less expensive to
manufacture.
Experimental approach
The experimental approach to tolerance analysis
consists of simulating the system under investigation,
randomly perturbing the parameter values and displaying the distribution of performance criterion. The
two basic advantages of this approach are:
1. Nonlinear systems can be investigated as easily
as linear ones, without making assumptions and
approximations.
2. The distribution of the performance criterion
that is necessary for further statistical investigations can be measured.
Tolerance analysis
Tolerance analysis 3 of systems and circuits is required because the optimized parameter values cannot
be exactly realized in manufacture, and the range of
conditions under which the system must operate is
usually much broader than the limited number of cases
that can be considered during optimization. The parameter values are not exact because components are usually available only in discrete ranges with a statistical
This nonlinear capability is important not only because
many systems contain nonlinear elements but also
because nonlinear performance criterion are normally
applied even to linear problems-for example, a mean
Rquared error criterion. A nonlinear criterion compli207
208
Spring Joint Computer Conference, 1969
cates a statistical investigation because the relative
influence of parameter tolerances cannot readily be
predicted, but the influence can be measured by the
experimental approach. A measured frequency distribution, when properly normalized, provides the probability
used in statistical estimates of yield and cost.
vVithout interaction, the computer run times required using this approach become prohibitive because
a large number of trials is needed to acquire confidence
that an histogram· is representative of the population.
In addition, the time required to evaluate the performance is frequently long. With interaction and graphic
display, the number of trials can be significantly reduced
by quickly terminating unsatisfactory distributions
and also recognizing when sufficient samples have been
accumulated by the insensitivity of the display to new
data. ~\1oreover, if the dedicated computer can be
operated in a hybrid mode, the solution time for problems requiring time domain analysis can be drastically
reduced by employing analog simulations. The ability
to use whichever mode of simulation (digital or hybrid)
best satisfies the requirements. greatly broadens the
range of problems to which the experimental technique
can be economically applied.
Tolerance analysis program
The experimental approach has been implemented
with a digital program. The basic features of this program are shown in Figure 1. *
The parameters of the given system are randomly
perturbed according to known statistical distributions
and the performance is measured. The perturbation
subroutine provides for the shaping of the distribution
obtained from the random number source and for the
correlation of the independent nllillbers to satisfy spo
cific problem requirements. The distribution of the
performance criterion is obtained from these m~asure
ments by dividing the criterion range into class intervals and accumulating the number of occurrences in
each interval. The accumulated data may be displayed
either as a frequency distribution histogram or a cumulative distribution histogram. The real-time display on
a digital scope enhances the evaluation of the histogram
and facilitates interaction with the program. Documentation is provided on the printer-both parameter
specifications and the diRtributions are printed when
required. The real-time interaction allows the user to
modify the histogram scaling, parameter nominal values
* A detailed description of this program has been submitted,
elsewhere, for publication by D. M. Bohling and the author.
In that paper, the procedures for random number generation,
histogram accumulation, and interaction with the computer
are discussed.
TOLERANCES
PARAMETERS
I NTERACT I ON
Figure I-Tolerance analysis program
and tolerances whenever required so that computer time
is not wasted in accumulating useless data. It is the
simplicity with which this technique can be applied to
any problem, linear or nonlinear, without extensive,
preliminary investigations that led to the design and
wide utilization of this tolerance analysis program.
Application
The discussion of the experimental approach to
tolerance analysis can be clarified by considering applications that illustrate its features. The two examples
were selected to demonstrate the value of being able to
use both digital and hybrid simulations, and the value of
the ability to measure performance in nonlinear problems and then accumulate statistical distributions.
Digital simulation of an inductor
The first example illustrates the application of the
tolerance analysis program to an all-digital simulation of
a gyrator circuit. The obj ective of this experiment was to
detennine what component tolerances would oe necessary in the gyrator circuit of Figure 2 to allow it to be
used as a replacement for an inductor. The reason for
using this circuit is to save on the cost, weight, and
size of the inductors that are used in this frequency
range. Such a replacement is feasible because the price of'
the integrated circuit components and amplifier to be
used are expected to become quite inexpensive in the
future.
The gyrator circuit must exhibit the same characteristics as an inductor and be stable, throughout the frequency range from .5 to 10 KHZ. The perfornumee
criterion selected was the Q of the cirCUIt-the ratio of
standard measure of inductor quality. The Q was
evaluated by calculating the input impedance of the
gyrator and taking the ratio df imaginary to real part of
this impedance. The circuit will become unstable if the
real part of the impedance become~ negative. At the instability threshold, the Q becomes quite large and thus
Interactive Tolerance Analysis
l/Q was used as the criterion to simplify scaling. Since
the evaluation of this impedance at a particular frequency is an algebraic problem, one can take advantage of
the high speed of digital simulation. A subroutine was
written that calculated this performance criterion
directly from the perturbed component values.
The display of the frequency and cumulative distributions of l/Q used in evaluating the performance is
shown in Figure 2. Gaussian variations were applied to
all parameters on the circuit-passive components and
amplifier characteristics. Several sets of component tolerances were evaluated before the acceptable performance illustrated in Figure 2 was obtained. The frequency
distribution was used to determine the stability of the
realization (no designs should exist with negative values
CO.PONENT
TOLERANCE
AT 4",
209
of l/Q) and to acquire confidence in the sample size. The
cumulative distribution reveals what percentage of the
designs can be expected to have a Q less than any
selected value. The tolerances used for this design were:
0.1 percent on the passive components, and for the
amplifier characteristics, 50 percent on the gain, 10
percent on the cutoff frequency, 67 percent on the input
resistance and 100 percent on the output resistance. The
design was then statistically evaluated. at several
frequencies within the intended operating range.
The accumulation of data with this digital simulation was extremely fast; 200 designs could be tested
and the histogram updated every second. The total
amount of computer time required for this investigation was quite short not only because of this fast operation, but also because the interactive capability allowed
the user to terminate unsatisfactory designs before
many samples were accumulated.
Hybrid simulation of a pulse equalizer
PASSIVE 0.11
UPLIFtER
Ao
50s
T
101
R'I"
&71
RD
1001
1.0
FREQUENCY
DISTRIBUTION
O~-L
o
____
~~~
0.02
1/0
__
~
0.04
1.0
CUIULA Tl YE
DISTRIIUTION
O~---",-_......L.
o
_ _ _ _..L-
0.02
1/0
0.04
Figure 2-Performance of a gyrator simulation of an inductor
may be evaluated from histograms obtained by applying
Gaussian distribut.ions to components
The influence of parameter tolerance on the error
rate to be expected from a pulse equalizer was investigated to establish manufacturing specifications. The
equalizer was one of a set to be used in a digital transmission system operating at 6.3 megabits per second
over standard telephone lines. The nominal equalizer
designs were optimized by Fleischer2 on the same interactive, hybrid facility that was used for tolerance
analysis; therefore, the basic analog simulation and
digital error rate calculations were available.
The calculation of error rate includes terms reflecting
intersymbol interference, thermal noise, crosstalk and
sampling jitter. The transient response of each equalizer
design had to be evaluated to determine interference
and noise. The intersymbol interference, which indicates
the effect of adjacent pulses on the one being equalized,
was calculated from the analog measurements of the
signal at sample points preceding and following the
pulse peak. The thermal noise power to be expected
from each desjgn was estimated from the impulse
response of the system. The determination of the
transient response by digital computer simulation took
far too long for either optimization or tolerance analysis
and thus an analog computer simulation was used.
The block diagram of the hybrid simulation of the
equalizer that was used in the tolerance analysis is
shown in Figure 3. The computer program repeats the
following sequence of operations and accumulates the
distributions under the user's control. A set of component values for each design is chosen randomly and
inserted into the simulation. A subroutine is provided
to convert the component nominal values and tolerances
specified by the user into simulation parameters. Both
210
Spring Joint Computer Conference, 1969
Figure 3-Hybrid equalizer simulation
an input corresponding to the pulse to be equalized and
an impulse are sequentially applied to the perturbed
design to evaluate intersymbol interference and noise
power respectively. The analog outputs of the equalizer
are sampled and processed on the digital computer to
determine error rate. Even for this complex application,
it is possible to evaluate the error rate for one design
every five seconds.
In the subsequent discussion, only component tolerances in the three bridged -T sections are considered; it
is assumed that these sections are buffered and all other
parameters are set to their nominal values. All the components in the basic bridged-T equalizer shown in
Figure 4 may have tolerances applied to them except
the characteristic impedance labeled R. Care must be
exercised in a tolerance analysis simulation to avoid
programming simplifications that may not be valid
when components are perturbed. For example, the
bridged -T section can be analyzed as a second order
system if it is assumed that the series and shunt arms
are properly matched; but since this match would be
destroyed by perturbations, a fourth order simulation
is required.
Before the analytical difficulties introduced by a nonlinear criterion (error rate) are discussed, a linear
criterion directly related to the equalizer response is
discussed so that the differences can be illustrated.
First, the standard deviation (0') of the peak amplitude
of the equalizer output pulse is estimated by the
moment method for various sets of tolerances applied to
the components in one bridged-T section. The same
data are obtained by measurement with the tolerance
analysis program and the results are compared. Then
the error rate is measured under the same conditions
and the influence of parameter tolerances are qualitatively compared.
The variance of the pulse peak can be estimated
from the distributions applied to the component values
by the moment method. 4 The performance criterion is
expanded in a Taylor series and only the lowest order
terms are used. Then the variance of the response
(O'~) is found for normally distributed, uncorrelated
component perturbations with the formuia.
(1)
where the a" are the component values. The partial
derivatives of the response with respect to the parameters can be obtained by a fiuite difference approximation or by measurement using the parameter iufluence method.1i The second method, which requires that
an auxiliary circuit be programmed to measure the
partials without an approximation, was used to obtain
the data for the equalizer. The auxiliary circuit was
realized by analog simulation and the measurements
were sampled and nonnalized with a hybrid program to
provide the sensitivity coefficients, Si.
oln P ai Po
S·= - - = - . ,
alnai
P
(2)
oat
HZ
c
R
R
where P is the pulse peak with no components perturbations. Let us express the standard deviation of the
component distributions about the nominal values in
terms of tolerance specifications. We define the tolerance
percentage (X) to correspond to the Ka point of the
normal distribution.
Thus
(3)
l
c
Equation (1) can be rewritten as:
O'P)2
(P
Figure 4-Bridged-T realization of fixed equalizer section
2
i~ Si
N
=
(X
lOOK
)2
(4)
This< same additive procedure can be applied if per-
L'"lteractive Tolerance Analysis
211
turbations are introduced in the component values of
all three sections.
Equation (4) was used with measured sensitivity
coefficients, Si, to calculate the data given in Table I
for various sets of component tolerances applied to one
equalizer section. A comparison of the Si revealed
that peak amplitude is most sensitive to variations in C
and L'. These two components have equal influence and
no other component is even 1/20 as effective.
.9999
.999
.99
.98
/
.95
. !I!!
Table I -Standard deviation of pulse peak
.80
:z
.70
Tolerance at 2(J
(percent)
(Jp/P
.60
(1Q-2)
.50
. 40
H C L
Calculated with
Equation (4)
lVleasured with
Tolerance Program
CoIPoN ENT
Tol ERANCE
IS = 100
0 0 0
1 1 1
1 1 3
3 3 3
5 5 5
0
0.56
1.23
1.68
2.80
0.03
0.50
1.20
1.80
2.71
To determine the (J of the pulse peak with the tolerance analysis program, the error rate calculation was
replaced with a measurement of peak amplitude. The
program was used to accumulate histograms, with at
least 150 designs measured for each case, for the tolerance sets listed in Table I. The (J estimated from these
histograms is also listed in Table I; the similarity of the
reRults is obvious. The finite (J with no perturbations is
due to small errors in the analog simulation; the program thus provides a check on analog reproducibility.
The relative sensitivity of the components is determined
with this program by experimentally varying tolerances
and observing the histogram changes.
Let us now consider the influence of the parameters
on the error rate under the same conditions listed in
Table I. The histograms were clearly not normally distributed. These cumulative distributions were replotted
on probability paper as shown in Figure fl. On this
paper, a normal distribution appears as a straight line
with (J inversely proportional to the slope. Since the
distributions are not normal, the tolerance sets cannot
be compared on the basis of their (J as in the moment
method. The relative influence of the tolerance sets can
be compared on the basis of yield at a selected rate as
determined from the curves. The threshold of acceptability for this equalizer was an error rate less than
10-1°; therefore, using 1 percent tolerances with K = 2
for all components, approximately 98 percent of the
designs are acceptable. With the low number of samples
used to obtain this data, the absolute yields may not be
co
0-
:::>
ID
.30
~
.20
c
.....
0-
C:~i)
.10
:::>
~
x
CURVE
NO.
R
C
l
.05
I
0
0
0
.02
2
I
I
I
3
I
I
3
4
3
3
3
5
5
5
5
.01
.005
.002
. DOl
.0005
-15
-I 2
-II
-10
-9
-8
-7
.0001
LOG OF ERROR RATE
Figure 5-Influence of component tolerance on equalizer
performance as determined by scaling the Gaussian
distributions applied to the components in a single
fixed section with various tolerance sets
extremely accurate but a comparison of relative values
is valid. A comparison of curves two, three, and four in
Figure 5 reveals that selectively tightening the tolerances on the R's and C's does reduce the variance, but
that the yields are not appreciably improved until the
L's are also tightened. With the linear criterion, it was
observed that C and L' were equally effective; but when
comparing the yields for a given error rate, this is clearly
not the case.
The difficulty of combining error rates is also evident
from the curves of Figures 6 and 7 in which are compared the error rates of each of the three bridged-T
sections perturbed separately and all three simultaneously perturbed. The simultaneous perturbation of all
three did not produce performance appreciably different
from the worst of the individual sections (each section
had different nominal component values). If one
attempts to combine the individual section data to
obtain a worst case estimate of the overall three section
performance, a much more pessimistic estimate would
result than the performance actually measured..
Spring Joint Computer Conference., 1969
212
1.0r-------------------~__._----~
1.0------------------~~~------~
SECTION 2
FIRST SECTION
0.8
0.8
z:
z:
CI
CI
COMPONENT
TOLERANCE
AT 2(7'
~
:::I
CD
a:::
0.6
~
~
W
>
~
a::
0.4
...I
C
t
L
0.6
~
~
R 1S
CI
C
~
:::I
CD
CI
lAo!
1S
3S
>
~
c
...I
0.4
r
COMPONENT
TOLERANCE
AT 2(1"
:::I
-=
:::I
-=
:::I
~
:::I
R 1%
C 1%
L 3%
(.)
0.2
0.2
o
~~
____
-16
~~
-14
____ __________
~
-12
-10
~~
-8
o
-16
-14
LOG OF ERROR RATE
Figure 6-Relative influence of each of t.he t.hree fixed sections
In the equalizer as determined by applying Gaussian
distribution to all components in the section
Pessimistic estimates of performance may also occur
if fixed values on system parameters, other than components, are used in the calculation of error rate. For
example, in obtaining the component tolerance data,
a fixed value of crosstalk was used that was indicative
of the worst cables measured. A statistical distribution
that reflected the measured crosstalk in many cables
was introduced into the error rate calculation by the
program. Figure 8 shows a comparison of error rates for
component variations in one section with fixed and with
normally distributed crosstalk. It can be seen that the
fixed value yielded an extremely pessimistic estimate
since most designs will produce significantly better
performance. If acceptable yields can be obtained with
worst case estimates, there is no need for measuring the
distributions. But typically with 'state of the art"
designs this is not the case and the distributions may
allow the designer to relax some specifications and still
obtain adequate perfonnance.
Realistic estimates of yield are invaluable in a cost
comparison of different realizations. Rather than tighten
all tolerance to provide a 100 percent yield and then
compare relative costs, an alternative probabilist.ic approach can be taken. Since yields can be determined from
-12
-10
-8
LOG OF ERROR RATE
Figure 7-The dominant influence of the first of the three fixed
sections of the equalizer is illustrated by applying Gaussian
distribution to the components in only the first section
and then to all three sections simultaneously
the cumulative distributions, the cost can be compared
on the basis of testing and rejecting a few of the unitH
that are constructed with wider tolerance components.
This cost calculation includes the yield to be expected, the
cost (C i ) of the individual components with a specified
tolerance (T i) and the cost (C T ) of testing to determine
defective units. Therefore, the cost of an acceptable
unit, that is one with an error rate less than the threshold (k) is:
C = CT
+ M(T1, 1. . .
.J..
rp
\
.L N)
f
i =1
C i (T i )
(5)
N = number of components in a unit
~I(T 1 , ••• TN) is the yield at threshold k, for the specified set of component tolerances, as obtained from the
cumulative distribution. This cost calculation is indicative of the many statistical applications in which
the probability density or the cumulative distribution is
needed to determine system performance.
Interactive Tolerance Analysis
_-....,....-------------"'T'"r----,.nll
CO.PONENT
TOLERANCE
AT 2,
.999
.95
.90
.ID
.70
. 60
. 50
.40
.30
.20
z:
0
...
...=
......
...,..
...
IE
provides the designer with realistic estimates of anticipated performance on which to base his decisions. The
performance distributions are acquired economically
because the user can quickly evaluate and terminate the
computer runs.
This technique is to be made more readily available to
designers by modifying a standard digital analysis program such as ECAp6 to fit into the structure. Then a
large class of circuit problems can be handled without
special purpose programs and simulations being provided. Therefore, only the more difficult problems will
require additional programming to perform the tolerance analysis.
0
c
.....
,=
!if
.10
. 05
.02
ACKNOWLEDGMENT
The discussions of this material with J. Chernak, P.
Fleischer, R. Snicer, and J. Davis are gratefully acknowledged. The author is particularly indebted to D .
Bohling who organized and wrote the tolerance analysis
program used in this work.
.01
.005
.002
.001
.0005
-45
-40
-35
-30
-25
-20
-15
LOG OF ERROR RATE
-10
-5
213
.0001
0
Figure 8-Comparison of equalizer performance as measured
with the same Gaussian distributions applied to the
components in the first fixed section using both fixed
and Gaussianly distributed values for external
crosstalk power
CONCLUSIONS
The values of the interactive computer with graphical
display for tolerance analysis has been demonstrated
in a variety of applications. The experimental approach
REFERENCES
1 Special issue on computer-aided desig'n
Proc IEEE Vol 55 November 1967
2 P E FLEISCHER
Hybrid optimization for electrical circuit dei:>ign
Eastern Simulation Council Princeton X J June 1968
3 D A CALAHAN
Computer-aided network design
McGraw-Hill ~ew York 1968
4 D G MARKS L H STEMBER JR.
Variability analysis
Electro-Technology Vol 76 No 1 July 196537-48
5 H F MEISSINGER
The use of parameter influence coefficients in computer
analysis of dynamic systerns
Proc Western J C C 1960
San Francisco May 1960
6 1620 electronic circuit analysis program (ECAP)
User's manual H20-0170 IBM Report 1620-EE 02X
A method of automatic fault-detection
+..00+
"~o,,
~.o""'Q"''''+':I''II.'''''
.fl"ll. ... .LVU.L
.f1"ll. .......-1'.LI.«0"::;
_...,.]" ... O'O
... « "...V.LI. .LV...
6.::1.L1.~
MOS LSI circuits
byY. T. YEN
National Cash Register Company
Dayton, Ohio
INTRODUCTION
ro determine whether an integrated digital circuit is
working properly, one may apply to the circuit a set of·
well-devised test sequences and compare the resultant
outputs with the corresponding correct outputs. Any
discrepancies indicate the presence of a fault. The main
task here is to find a set of test sequences which can
detect the presence of any prescribed fault in the circuit.
This test generation problem will become formidable for
large scale integrated arrays, since large number of logic
circuits may be contained in an array with a limited
number of exterior terminals.
Presently, the approach most commonly used in test
generation is computer fault simulation. In other words,
data are repetitively processed through a cycle of two
steps, i.e., test generation followed by test verification.
In each cycle, the generation of primary output test
sequences can be accomplished by a computer logic
simulation technique. The primary-input test sequences
are manually generated by engineers because much
creative work is involved.
In this paper, a method will be proposed to generate
primary-input test sequences for 4-phase MOS sequential switching circuits. This method can find the
shortest primary-input test sequences to detect a given
fault on an array.
An MOS transistor stuck at either short or open
permanently is the failure mode to be considered.
A single fault assumption4 will be made in this paper.
Peculiar circuit jeaJ,ures
Four-phase MOS circuits exhibit many peculiar
features not observed in other families of logic circuits.2 ,3
It is found that the test sequence generation problem
can be greatly simplified by exploiting the peculiar
features of these circuits.
.
There are four clock signals and four types of logic
gates in a four-phase MOS circuit.2
The time interval of one clock-phase is defined as one
unit of time t, as shown in Figure 1. For example, t = 7
is the time at the end of phase 3 of the second bit.
Let S t denote the set of logic levels of all internal logic
gates of a 4-phase circuit at time t:
Where Sit is the logic level of the i-th logic gate at
time t, and m is the total number of internal logic gates.
It should be noted that the output signal of a 4-phase
gate cannot be sampled during the certain clock-phase
times, because of the precharging behavior of the gates.
The clock-phase time during which the output signal of
a gate can be sampled is shown in Table 1.
Table I-Bampling time of gates
Type of gates
type-1
-2
-3
-4
Clock-phase time during which the
output signal of a logic gate can be
sampled.
Phases 3 and 4
Phase 4
Phases 1 and 2
Phase 2
Now the peculiar circuit features useful for test
sequence generation can be summarized as follows:
21.5
Spring Joint Computer Conference, 1969
216
lNITIAL
CfIX.K
PIIASE TI ME t -
I
3 I4
I
JST 8IT
I I 2 I3 I4
0
I
2
I
2ND BJT
I I2 I 3I4
I
3RD BIT
I 2 I OJ I
I
.3 4 S , 7 8 'I
- -
-
10 1/ - - -
Figure I-Definition of time t
(1) Each four-phase logic gate provides a storage of
at its output for one or two clock-phase
tunes, (2) feedback and feed-forward in a flipflop
circuit do not occur simultaneously, and (3) the logic
levels of· all logic gates in a circuit, including flipflops
can be initialized to predictable logic levels by inhibit~
the occurrence of one 4>2 or cf>4 clock pulse.
~ormation
Tracing technique Jor Jour-phase .il.1 OS circuits
In order to force the logic gates of a 4-phase circuit to
desirable logic levels, we will trace a signal backward to
find the necessary primary-input sequences and circuit
initialization. The peculiar features ·of 4-phase circuits
enable us to trace a 4-phase signal backward by
considering each unit of time t as follows.
Let F 11 be the 4-phase signal at a logic gate output at
time t = t 1 • ViF 11 will denote the function obtained from
tracing F tl backward by j units of time· t where j is a
positive integer. To trace V'F tl backward by one unit
of time, we will substitute every internal gate variable
s. of V'F tl with the combinatorial Boolean function
implemented by the logic gate SA:. Let us demonstrate
this technique by tracing backward the 4-phase signal
s, in Figure 2.
In Figure 2, iI, i" and ia are primary inputs. Sa and B4
are type-1 logic gates. BJ, SI, and Bi are type-2 3 and
. gates, respectively.
' ,
4 ',OglC
Since SI gate is a type-3 gate, the logic signal SI can be
sampled only during phases 1 and 2. Let tl be the time
at the end of phase 4 of bit N. Then (tl - 1), (tl - 2),
(~1 - 3) and (tl - 4) are the times at the end of phases
3, 2, 1 of bit N and phase 4 of bit N - 1, respectively.
Let SUm and iUm denote the logic level of SI and it at
time t = tm, respectively. In tracing SI backward, the
following relations are derived for each unit of time t:
SIll
=
St(Il-1) 'S&(tl-l)
= ~(tl-l)
+ ~(tl-l)
(1)
(2)
=
S,(I1-I)
+ ~(tl-I)
(3)
=
4(tl-a)
+ i (tl-a) + S1(tl-B) . Bi(tl-8)
(4)
=
4(11-8)
+ i2 (tl-8)
2
+ (8101-4) • St(fl-4»
·i;(lI-4)
(5)
J
Figure 2-A four-phase MOS Circuit
=
4(tl-8)
+
+ i2
(S8(11-1)
(tl-8)
+ ~(I1-1»
·1;(11-4)
(6)
Where (2) is derived by substituting SI of (1) with the
combinatorial Boolean function B!B4, which is implemented by the logic gate SI. Note that the time at which
signal SI can ~ sampled is one unit later than that at
which signals BJ and B4 can be sampled.
The relation (1) = (2) indicates that: (a) SI will be 1
at time t = tl if and only if either or both St = 0 and
B4 = 0 hold at time t = tl -1; and (b) SI will be 0 at
time t = tl if and only if St = B4 = 1 holds at time
t=tt-l.
Let us denote SIU as F u. Then VIF 11 will be
BJ(Il-l)"B4(U-lh as shown in (2).
Equation (3) is derived from (2) by tracing backward
another unit of time t. There is a type-2 gate B2 between
gates S3 and SI. However, there is no type-2 gate between
gates B4 and SI. Therefore, we will substitute 8J of (2)
with the combinatorial Boolean function S; implemented
by the logic gate 82. And, we will not substitute B4 of (2)
at this time. S8(1l-2) + ~(tl-!) of (3) will be denoted
as V2F Il •
Equation (4) is derived from (3) by tracing backward
additional unit of ti'lle t. We substitute S3 and s. of (3)
with the combinatorial functions h and it + SII%,
respectively. We will denote h(Il-B) + i2 (u-3) +
Sl{U-8) !36{U-I)
of (4)
&.9
VIF u.
Method of Auto:matic Fault-Detection Test Generation
Equations (5) and (6) are similarly derived from (4)
and (5), respectively.
It should be noted that gates S1 and S4 of Figure 2
form a RS flipflop. Recall that a 4-phase MOS circuit
possesses a peculiar feature that the feedback and
feedforward in a 4 phase flipflop cannot occur simultaneously. This feature enables us to trace backward a
signal in a 4-phase sequential circuit for each unit of
time, as shown above. No additional specification, such
as a truth table, is needed to specify a flipflop.
output of the logic gate if and only if the inputs of the
logic gate, except X m , satisfy the following condition:
Where £ i is the combinatorial Boolean function
implemented by the logic gate.
Let us consider the 4-phase gate shown in Figure 4.
Assume that Xs has a fault.
Then,
= XIX2 + ~
£(X s ~ 0) = X 1X 2
£(X s ~ 1)
Conditions of fault signal propagation
Let £(X1, X 2, - , Xn) be the combinatorial Boolean
function implemented by a 4-phase logic gate. A fault
of an input, say Xi, will be defined as the 1\10S
transistor fed by Xi is permanently stuck at short or
open.
In this section, an algebraic method will be discussed
to derive the input conditions of a legic gate under which
the output of the logic gate will respond to the presence
of a fault at an input Xi.
Boolean difference
See Figure 3. £(XI, X 2, - , Xn) is a combinatorial
Boolean function. Assume input Xm has a fault. Sellers
et aU show that the fault of Xm can be propagated to the
output if and only if the input variables of £, except
X m , satisfy the following condition:
£(Xm
~ 1)
EB £(Xm ~ 0)
Boolean difference
EB £l(X
~ EB X lX 2
D l • S = £l(XS ~ 1)
= X lX 2 +
S
~ 0)
=Xl~+X2~
Thus, D l ,8 = 1 if and only if either Xl = 0 and X 4 = 1
hold or X 2 = 0 and ~ = 1 hold. Under either of these
two input conditions this logic gate behaves as a logic
inverter, i.e., £1 = Xa. Consequently, the gate output
efl will then respond to any fault of Xt. It should be
= 1
Where EB is exclusive OR, and m is one of the integers
1, 2, 3, - , n. Xm ~ 1 (or 0) means that variable Xm
ot £ is substituted by the constant 1 (or 0).
A Boolean difference of a function £i(X1, X 2, - , X,,)
with respect to input Xm will be denoted as Di,m,
which is
Examining the features of a 4-phase logic gate, we see
that the fault of input Xm can be propagated to the
X.-t
X,
COM/JINATORIAL
X.. •
Figure
CIRCUIT
~~-Signal
notations of eomhinato,"ial eircuit
Figure 4-A four-phase MOS logic gate
218
Spring Joint Computer Conference, 1969
noted that each term of Dj,i represents such an input
condition.
Assume the l\fOS transistor Ts associated with input
Xs is permanently stuck at short. Then we must. apply
the signal Xs = 0 to T 3, so that the fault of "short" can
be detected at the output J\. Therefore, the input
conditions to detect T s permanently stuck at short are
the input conditions satisfying Xa.D1,s = 1.
Where
Xs.D1,s = Xs (Xl~
+
In other words, either
0 and
~
= 1
X 2 = 0, Xs = 0 and
~
= 1
=
gi,i+1,
for 1 :::;
:::; k,
gl,2 = D 1 ,2
g2,3 = (Vb gl.2) . D 2,s
gS,4 = (Vb g2,S) . D s ,4
~,5
= (Vb gs,4) . D 4,5
X2~)
= XIX~+MX~.
Xl = 0, Xs
We will denote functions
as follows:
or
will detect the fault of "short" of l\'{OS transistor T 3.
If Ts is permanently stuck a~ open, then XS.Dl,S = 1
are the input conditions to detect such a fault.
The shortest fault detection test procedures
See the block diagram of a 4-phase circuit in Figure .5.
Each block represents a 4-phase logic gate. Consider
logic gate £ k. Assume the transistor associated with its
input £ k+l has a fault. We will find the shortest tests to
detect this fault. The propagation path of the fault is
£k, £k-l, -, £s, £<;., and £1. Starting from £1, we will
find the Boolean difference and trace backward for each
stage of logic gates until we reach £ k+l as follows.
Where D i ,i+l is the Boolean difference of £i with
respect to £ i+l. Vb is to trace gJ,i+1 backward b units
of time t. b = 1 if one of £ j and £ i+1 gates is either
type-2 or type-4 logic gate. b = 2 if both £ i and £ i+l
gates are neither type-2 nor type-4 logic gates.
Let us consider the gate J'k. If the transistor associated with input £ HI is permanently stuck at short,
1 HI' gk ,k+l = 1 will be the input conditions to detect
the prescribed fault. If the transistor associated with
input J' HI is permanently stuck at open, £ k+1 • gk,k+l = 1
will be the input conditions to detect the prescribed
fault. We will denote
G = £HI gk,Hl if the transistor associated with
£ HI is stuck at short,
= £Hl
gk,k+1
if the transistor associated with
£ k+1 is stuck at open.
Every term of G is an input condition to detect the
prescribed fault. Each term of G may consist of primary
inputs and internal logic gate signals. We will check
each term of G to find whether it satisfies the following
condition:
Condition A :
OUTPUT
either
1. All variables of a term of G are primary
inputs
or
2. All internal-gate variables of a term of G
will become logic-l by inhibiting a proper
clock signal.
- - - fiATE
II
I
---IT
I
Figure 5-Block diagram of a four-phase circuit
(Sequential or combinatorial)
We will follow the following steps to
fault detection tests.
fin~
the shortest
Step 1. Check every term of G to determine if it
satisfies condition A.
Step 2. If no term of G satisfies condition A,
trace G backward by one unit of time t
and then repeat step 1. If there is a term
Method of Automatic Fault-Detection Test Generation
of G which satisfies condition A, this term
is the shortest test to detect the prescribed
fault. Furthermore, if there exists a test at
time t = tr which can detect the prescribed fault, then at least one term of G
at time t = tr satisfies condition A ..
If the function G becomes 0 at some step of tracing
backward, then there exists no test which can detect
the prescribed fault.
Let us derive the shortest tests to detect some fault
in the .circuit shown in Figure 2. Assume T1 is stuck at
open permanently. Then £1 and £2 are the gates Sl
and S4, respectively. Since the faulty transistor T 1
belongs to gate B4, £k and £k·H are B4 and Sl, respectively
Let t1 denote the reference time at Sl.
Since
£1 = Sl(t1) = B2(tl-1) S4(tJ-l)
= B2(tl-l)
thus
Since
£2 = S4(tl-2) = il1 (tl-s)
+ Sl(tl-S) S5(tl-S)
= S5 (tl-S) . i2 (t1-S)
thus,
~ ,3
= S5 (t1-S) . h (tl-S) . i~ (tl-S)
Since T1 is stuck at open,
= Sl(t1-S) S5(tl-S)
h(tl-s)
i~Ht1-S)
We will check G to determine if it satisfies Condition
A. Since internal-gate variables Sl and 85 cannot
become logic-l simultaneously at time (t1 - 3) by
inhibiting either cf>2 or cl>4 clock signal, we will trace G
backward one unit of time t. Here, it should be noted
that gate S5 is a type-4 gate and gate Sl is a type-3 gate.
219
time t] - 5, then all type-3 gates such as the gate S1,
will become logic-l at time (t1 - 4) and (t1 - 3);
therefore, V1G satisfies condition A. In other words,
if we set up the following condition, the fault of T 1
being stuck at open can be detected at the primary
output Sl at time t = t1:
Inhibiting cl>4 at time (t1 - 5)
is = 0 at time (t1 - 4)
h = 1 at time (t1 - 3)
i2 = 0 at time (t1 - 3)
Since V1G has only one term, this condition is the
only test to detect the fault of TI being stuck at open.
Compute?' programming
1Ianual implementation of this method was not
attempted for the complexity of logic in an LSI array
because of the complex detail involved. Using this
method, a computer program written in FORTRAN IV
was developed and has been used to generate test
procedures for each prescribed fault in a 4-phase MOS
LSI array.
This computer program consists of 15 subroutines to
perform the following manipulation:
Simplify a function
OR functions
AND functions
Complement a function
Find Boolean difference
Trace a function backward
Check a function to determine if it satisfies
Condition A
Simulate faulty signals
Keep tracking timing.
Every signal name is denoted by a number. A Boolean
function F x is specified by an integer number
NXTER~1, and two integer arrays NXNOVAR(I) and
NXVAR(I). For example, F x = SlSsB4 + ~4 and
Fy = ~S5 + Ss will be specified as follows in the computer program:
Fx: l\""XTERM = 2
NXNOVAR(l) = 3, NXNOVAR(2) = 2
NXVAR(I) = 1, NXVAR(2) = 3,
NXVAR(3) = 4
NXVAR(4) = 2, NXVAR(5) = -4.
F lI : NYTERM = 2
Let us check VIG to determine if it satisfies Condition A. If we initialize the circuit by inhibiting cl>4 at
NYNOVAR(I) = 2, NYNOVAR(2) = 1
NYVAR(I) = -2, NYVAR(2) = 5
NYVAR(3) = 6
220
Spring Joint Computer Conference, 1969
Where NXTERJ\lI specifies the number of terms in
function F:t. NXNOVAR(l) and NXNOVAR(2) show
the number of variables in the first and second terms.
NXVARCi) shows the variable at the ith order counting
from the left of the function F:t, i.e., NXVAR(l) = 1
denotes SI, and NXVAR(5) = -4 denotes 84'
F y is similarly specified in the program.
Now, let us OR the functions F z and F y • The resultant
function F z = F:t + F ycan be easily performed by the
computer program as follows.
Fz: NZTERM = NXTERM + NYTER]\rl = 4
NZNOVARCl) = 3, NZNOVAR(2)
2
NZNOVAR(3) = 2, NZNOVAR(4) = 1
NZVAR(l) = 1, NZVAR(2) = 3,
NZVA.R(3) = 4
NZVAR(4) = 2, NZVAR(5) = -4,
NZVAR(6) = -2
NZVAR(7) = 5, NZVAR(8) = 6.
This computer program is written in FORTRAN IV
for a NCR 315 RMC computer. Through the use of
40K-word core memory, 12 bits per word, it can
generate the primary input sequences of the shortest
fault detection tests for each prescribed fault in a
4-phase }\10S array of 70 four-phase logic gates. The
program needs 8 minutes of FORTRAN IV NCR 315
RlVIC computer time for the prescribed faults of one
3-input Jour-phase gate on a typical 70-gate array. The
computer time for this test generation can be greatly
reduced if this FORTRAN program is converted into a
NEAT (machine) language version for the NCR 315
Rl\1C computer.
REFERENCES
1 F F SELLERS JR
M Y HSIAO
L W BEARNSON
Analyzing errors wiJ,h the Boolean difference
Digest of the First Annual IEEE Computer Conference
September 1967 6-9
2 Y T YEN
A. mathematical model characterizing four-phase MOS
circuits for logic simulation
Input data
The input data to this computer program only
consist of:
a. Logic implemented at every individual logic gate.
This logic is a combinatorial Boolean function.
For example, the program needs the combinatorial Boolean function B2 + ~ to specify the
logic implemented by SI gate in Figure 2.
b. Type of each logic gate. SI gate in Figure 2, for
example, is a type-3 gate.
c. Designation of faulty lHOS transistors.
d. Designat.ion of one fault-signal propagation path
for each faulty gate. An internal signal of an LSI
circuit may be propagated to several primary
outputs. To simplify the computer program,
a desirable propagation path for an internal fault
signal need be given. The propagation path of a
fault signal S4 in Figure 2, for example, will be
specified as S4 ~ SI in the input data, for the
faults associated with S4 gate.
IEEE Transactions on Computers Vol C-17 September
1968 822-826
3 Y T YEN
Intermitient failure problems of four-phase MOS circuits
To be published on IEEE Journal of Solid-State Circuits
4 E R JONES C H MAYS
A. utomatic lest ge·ne·ration I1wtlwds for large scale integrated
logic
IEEE Journal of Solid-State Circuits Vol SC-2 No 4
December 1967
5 J P ROTH
Diagnosis of automata failures: A. calculus and a method
IBM Journal July 1966278-291
6 E G MANNING H Y CHANG
A comparison oj fault simulation methods for
digital systems
Digest oi the First Annual IEEE Computer Conference
September 6-8 1967 10-13
7 F P PREPARATA G METZE R T CHIEN
On the connection assignment problem of diagnosable system
IEEE Trans on Electronic Computers Vol EC-16
December 1967 848-854
8 S SESHU D N FREEMAN
The diagnosis of asynchronous sequential switching systems
IRE Trans Electronic Computers Vol EC-ll August 1962
459-465
A method of diagnostic test generation
by A. B. CARROLL, lVI. KATO, * Y. KOGA, and
K. NAEMURA
University of Illinois
Urbana, Illinois
INTRODUCTION
A variety of diagnostic techniques1- S have been proposed and applied to error detection and location in
computers. The efficiency of the tests generated by them
varies from machine to machine depending on the scale
of the system, its logic organization, and the employed
hardware technology. The impact of highly integrated
circuitry is changing the trend in logical design of
computers.
The significant reduction of propagation delay per
individual switching gate and of the physical size of the
circuits has made it possible and frequently even
desirable to use a less sophisticated technique in the
logic design. The use of adder packages with' standard
carry lookahead and semiconductor scratch pad memories often results in a better cost/performance ratio
than development of the fastest carry propagation
technique and the most advanced instruction lookahead
control.
The design of the ILLIAC IV computer9 is one of the
recent examples in which modularity is preferred to an
excessive sophistication of logic.
On the other hand, the introduction of higher
integration technique has posed a problem to diagnostic
engineers. The failure modes of the circuits have become
more complicated and less obvious. Seventy to eighty
percent of catastrophic errors may still be caused by
mechanical failures at bonding and connections but the
other errors include such subtle faults as marginal
errors rising from relatively low noise margins of current
mode gates and unexpected shorts (low resistance)
between logically distant connections on a semiconductor chip.
This paper describes a new approach to the method
of diagnostic test generation for a computer built with
highly integrated circuitry.
The first half of the next section describes the
generation of test paths used to test registers and
transfer paths between them. The second half is
concerned with generation of input patterns for testing
combinational logic networks.
Techniques employed in logic simulation and location
of errors are briefly discussed in the following sections.
GeneraJ,ion of test cases
Path tests
A graph representation of a system is useful to
visualize the operation and data flows in it. Several
papers have been published on the use of graphs in
diagnosis of logical machines.6 In this section, we discuss
the generation of efficient tests for detection and
location of errors using a graph of the machine.
Let us assume that the system has been represented
as a directed graph, in, which nodes and arcs correspond
to some circuit blocks and signal lines. In addition, let
us assume the arcs in the graph can be enabled or
disabled independently. A graph is equivalently represented as a square matrix called "adjacency matrix."
Figure 1 shows an example of a graph and its
adjacency matrix is as follows:
No
Nl
Nt
N3
N4
N6
• Currently with Nippon Telegraph and Telephone Public
Corporation, Tokyo, Japan.
221
No
Nl
Nt
N3
N4
No
0
0
0
0
0
0
1
1
0
0
0
1
0
1
0
0
0
0
0
0
0
0
1
0
0
0
1
0
1
1
1
0
0
0
1
0
222
Spring Joint Computer Conference, 1969
o indicates the absence of the corresponding node or arc
There exist thirteen possible paths from the input
node No to the output node N I) as shown in Figure 2.
Let us define a row vector of Boolean elements for
each path, where each column denotes a node or an arc;
No
IJ!
P4
I
1
~:P7 I !.
o
'"v
o
o
o
o
o
1
1
1
1
1
1
1
o
o
o
Ps
1
1
PII
P IO
1
1
o
Pn
Pu
1
1
o
o
o
1
1
1
1
1
1
1
1
o
o
1
o
1
1
1
1
in this path. Now we have the following matrix with
respect to the graph in Figure 1. We call it path matrix
of the graph.
Al
At
Aa
~
As
As
A7
As
Aa
AlO
1
0
0
1
0
0
0
0
1
0
1
1
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
1
0
1
0
0
1
0
0
0
1
0
1
0
1
0
!1
1
.1
1
.1
i\
v
1
1
o
1
0
1
1
1
0
0
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
0
0
0
0
0
0
0
1
1
0
0
0
0
1
1
.L
0
0
0
1
1
0
0
0
0
0
0
1
1
0
0
0
0
0
1
1
1
1
1
1
1
1
0
1
0
1
0
1
0
1
0
1
1
1
1
0
1
1
0
1
1
1
1
0
0
1
jJ
INPUT
,~".
"'~:
~:~:
~
.
•
~~
\~~:
,~k:
\t~\~ 't'" \f 'r ,~
P1
;.
p.
P10
P ll
~ut
Figure 2-Possible paths
OUTPUT
Figure I-Example of a directed graph
To diagnose a machine for disconnection errors, we
should test paths to see if they successfully connect the
input and output. In the above example, if arc Ag fails,
Po, PI, P a, P 6, P7, P g, and P u still connect successfully,
but P 2, P 4, Pe, P s, P IO , and P I2 contain an error. Thus,
by comparing columns of the path matrix with the test
result, we can determine which node(s) and/or arc(s)
have errors.
If an error location can be determined by testing all
possible paths, it is said to be distinguishable. All
possible path tests may not be required to determine
where a single fault has occurred; i.e., we may be able to
reduce the number of paths from the complete set of all
possible paths in the original graph.
The following method may be used to reduce the
number of path tests; the resulting set of paths still
retain the ability to detect single failures.
Let us consider a graph with a single input and a
single output; if there are multiple inputs or outputs,
we can add a dummy input or output node and connect
it to the actual inputs or outputs so that the graph may
have only one input and one output. Now we produce a
tree from the original graph; starting at the input node,
we put down an the nodes which are directly fed by the
A Method of Diagnostic Test Generation
input node and draw lines corresponding to the arcs
between them. Level zero is assigned to the input node
and level one to the nodes adjacent to the input node.
The level one nodes of the example in Figure 1 are
Nt, N 2, and N 3•
This step is repeated until all nodes are covered. If a
node has already occurred on a higher level or previously
on this level, we define it as a pseudo-terminal node and
cease to trace arcs down from it.
Three pseudo-terminal nodes on level two are shown
in Figure 3. Whenever a path from the input has met a
pseudo-terminal node, we choose one of the routes which
go down to the output to complete the path. We obtain
six paths from the graph in Figure 1, as shown in
Figure 4. In the example the shortest path was selected
after the pseudo-terminal nodes.
Errors in node No and N s are indistinguishable. So
are the errors in N 2 and arc As, and those in X I and AI,
those in N4 and As, respectively. This was true also in
the original graph.
We call this method as the path generating method
hereafter in this paper, and we show that a set of paths
generated by the PG:\1 is a minimal and sufficient set
Ns
-LEVEL
0
Nz
-LEVEL
1
N3'
-LEVEL 2
223
of paths to detect and locate a failure in a network
without feedback.
Theorem 1. The set of paths generated by the PGM is
a minimal set that is sufficient for detecting and
locating any distinguishable single failure within the
graph without feedback.
Proof. If we insert a dummy node on each arc of the
original graph, we can discuss only the distinguishability of node failures. The indistinguishable nodes are
defined as follows: if there exist two nodes ni and nj such
that no path in the graph passes through exactly one
of the two nodes n i and n j, then these two nodes are
said to be indistinguishable. It is noted that all nodes
of the original graph are exhaustively included in the
paths generated by the PGM.
1
INPUT
No
OUTPUT
-LEVEL 3
CO DENOTES A PSEUDO- NODE
Figure 4-Generation of a tree from the graph (2)
Figure 3-Generation of a tree from the graph (1)
No
Nl
N2
N3
N4
N6
Al
A2
A~
~
A6
A6
A7
A8
A9
Alo
1
1
1
1
1
1
1
1
0
0
0
0
0
0
0
1
0
1
0
1
1
1
1
1
0
0
0
1
1
0
1
1
1
1
1
1
1
1
0
0
0
0
0
0
1
1
1
0
0
0
0
0
0
1
0
1
0
0
0
0
0
0
0
1
0
1
1
0
0
0
0
0
0
1
1
1
0
1
0
0
0
1
1
0
0
0
0
0
1
0
0
0
0
1
0
0
Figure 4.2-Path :Matrix
224
Spring Joint Computer Conference, 1969
If anyone of the paths generated by the PG1VI were
deleted, then there would exist at least one node
(corresponding to an arc in the original graph) which
was not included in the set of paths. This is obvious
because no arcs are repeated in a tree generated by the
method except in the route below the pseudo-terminal
nodes.
The indistinguishable nodes resulting from the testing
of all paths in the original graph do not become distinguishable nodes by testing the paths generated by
PG1'I.
Next, let us assume that the nodes ni and nj are
distinguishable by testing all paths with the original
graph. There should be at least one path which passes
through either one of the two nodes ni and nj. Let us
define a set {Pii} of all possible paths that pass through
both nodes ni and nl, and define a set {nii} of all nodes
on these paths lying between ni and nj, where the set
fnii} includes nodes ni and nj. Because ni is distinguishable from nj, there is at least one branch connected
between node nk &Jnij} and a node nt e{nii}' The path
through the node nt exists in a set of paths generated by
the PG~1 and this path does not pass through both
nodes ni and nj. Thus the nodes ni and llj are still
distinguishable by testing the paths generated by the
PGM.
The time-consuming procedure of reducing the set
of tests using a minimal cover technique can be avoided
by the simple algorithm and the theorem stated above.
The theorem is valid for a general class of networks
with feedback.
Wo
WI
W2
W3
W4
W~
Ws
W7
s
We-!l
Wg
c
W,o
W"
I
I
W'2
I
WI3
l
I
s
Z~
S I Y3
W'4
WI~
:
c I Y4
I
I
C
I _____ .JI
L
WI6
WI7
s
W1e
S
W"
c
C
W20
~------------
ZIO
Figure 5-Example of a combinational network
Combinational tests
Suppose each solid box in the network of Figure 5 is a
full adder and every pair of circuits is put on. a chip as
indicated by the dashed line. Let us consider how we
can test the logic function of a chip.
The following equations are relevant to the chip
inputs and outputs:
1. Equations for chip input signals
=
W
W3 4
W7
=
Ws
Xl
X2 =
X3
EB Wg EB WIO
X4 = WSWg
X6
X6
=
=
+ W4W6 + W3W 6
W12
W13
I
(1)
J
2. Equations for chip function
YI
y,
ya
=
=
=
Y4 =
Xl
EB X2 EB Xa
XIX,
X4
+ X2Xa + XIXa
EB Xfi EB Xs
X4X6
+ X5X6 + X4X6
+ (WO + W2)(W3 EB W4
EB W6» EB W6 EB Yl
Z4 = (WOw! + (Wo + W2)(Wa EB W4
EB W6»(W6 + YI) + YIW6
Z6 = Wll EB Y2 EB Y3
Za
=
(WOW2
Zs
=
=
WUy!
Z7
+ W9WIO + WSWIO
EB W14 EB WlO
3. Equations for external outputs
(2)
+ Y2Ya + WllYa
(WlaW14 + W14WlO '+ WlaWlO)
(3)
EB W17 EB WIS EB W19 EB W!O
EB W l6 EB Y4
In general, an output of a chip may feed an input to
another chip whose output feeds an input (possibly
through a few other chips) to the first chip. The
equations for chip inputs in such a case will contain a
term including the chip output variable.
Thus we define a "combinational logic network with
pseudo-feedback loops" as follows:
1. It has a (multi-output) combinaiionallogic func-
A :rvfethod of Diagnostic Test Generation
tion which describes the relation between the
external inputs (WI, W2, ... , WN) and outputs
(Zl, Z2, ..• , ZM)'
2. It is composed of a finite number of unit circuits
each of which has a (multi-output) combinational logic function to describe the relation
between its inputs (Xl, X2, ... , xn ) and outputs
(Yl, Y2, ... , Ym)·
3. It may contain pseudo-feedback loops; i.e., its
connection graph may contain any number ot
loops provided that none of these constitute
storage of internal states. Thus, the output values
of any unit circuit are uniquely determined by
the external input values of the network despite
the existence of loop8.
The unit circuits in the network may be of any size
and any structure, provided they satisfy premise (2)
above. Specifically, however, we are concerned with unit
circuits as a model of integrated circuit chips or portions
of chips, the total number of input and output Hnes
being limited within the order of 101 • The structure
of the circuit may be a net of at most 101"'2 of elementary
logic gates.
Various types of failures may exist within the logic
network. Some of them are of electrical nature, others
of mechanical. A considerable fraction of them are only
intermittent and cannot be detected except by chance,
while the rest persist long enough to be detected as
permanent failures.
It has been a convention in previous studies to
classify those failures by logical modes: stuck-at-O mode,
stuck-at-1 mode, other degenerate modes, and nondegenerate modes. Very few papers have treated all of
these modes. Techniques for detection and location of
more than one failure in a chip have not been extensively developed.
So that we may not confine possible failures to any
particular mode, we set the foIlmving assumptions,
which have been adopted (if not explicitly) by all
previous studies:
1. The failure is non-sequential; i.e., it may be any
transformation of the combinational logic function of a unit circuit but it doesn't change the
unit to a sequential circuit.
2. Only critical failures are of concern; namely, only
if they change the external logical function of the
network.
3. We will treat failures in any single chip; i.e., we
assume that failures don't exist simultaneously
in more than one chip, although the existence of
more than one failure in a chip is not excluded.
The assumption (1) above requires that every possible
225
combination of input values be applied to a unit circuit.
(In case a subset of all possible combinations is obtained
V\rith a narrower assumption on failure modes, the
following discussion can be applied to the subset.)
Then, the problem is how to determine external input
values so that a unit circuit can be given an arbitrary
input combination and that any change in its output
value can be detected at an external output. This is
formulated as follows.
First, obtain the equation f i for a chip input Xi
(cf. Figure 6), as follows:
1. Break up all the chip output lines, v!, ... , v m •
2. Insert dummy inputs Yl, Y2, ... , Ym to the
network to replace signals v!, ... , vm •
3. Write an equation f; for Xi in terms of external
inputs WI, ... , WN and dummy signals Yl, ... , Ym.
Now the requirement is stated in the following, where
the Boolean difference7 dJL/dti of a function JL =
JL (h, ... , t n ) with respect to ti is defined by JL (t l , ... , t n )
EB JL (t l, ... , ti-l, ti, ti+l, ... , t n ).
1. Any combination aI, a2, ... , an of values may be
assigned to chip inputs Xl, X2, ... , Xm; i.e., for
i = 1, ... , n'.
where Vj is an output from an error-free copy of the
chip under test and is a function of WI, ... , WN as
obtained from the: original network (Figure 6 (a».
2. Some of the external output values should be
changed by a deviation in signals Yl, ... , Ym.
Thus, for j = 1, 2, ... , m:
(5)
:3. Any pseudo-feedback loops should be logically
broken up to fix the chip input values in the
existence of an error.
For:
i = 1, 2, ... , nand j = 1, 2, ... , m
(6)
Thus, solving equations (4)-(6) in terms of WI,
W2, ... , W N we obtain a set of input values for error
detection.
A solution for the example in Figure .5 and equations
(1)-(3) is shown in Figure 7. Sixty-four input patterns
are required to test for all possible combinations of
inputs to the chip.
Spring Joint Computer Conference, 1969
226
t-:l
w1-----f
I
Wz
•
•
•
•
•
W
VI
Xl
L2
X2
•
•
•X.
N
Xi
= fI
•
•
•
•
0
•z.
O2
(WI » VIZ. • .•• WN )
01
01
0
Y1
04
vJ=a (Xl. XZ ••• -IX.)
;y (Wi.
Zit :: glt (WI.
0
WI • • • • ,WII)
WI.
(0) ORIG I NAL
all
• .W N )
06
NETWORK
s
Y2
C
Y3
S
Y4
0
0
W1
I
I
I
IL _____
Wz
0
•
•
0
WN
0
0
C
0
Yl
Xl
Yl
~z
ff~:
•
X.
Yz
•
•Y,.
•
•
I
=f,*(Wi. WZ • • • •• WN.Yl. Yz , •••• Y.)
Zit = (Wi. WZ , • • • ,W... Yl Y. , ... ,Y.)
XI
g:
(b) NETWORK
I
WITH
DUMMY
SIGNALS
Figure 6-Generalrepresentation of a combinational network
Location of errcYT'S
The determination of nodes and arcs relevant to each
path test is straightforward from the path matrix.
Translation from nodes and arcs to packages and wiring
then enables us to determine which physical components
of the machine affect a test result.
Location of single errors detected in path tests is
possible by comparing the columns of the path matrix
Figure 7-801ution to Figure 5
with each test result expressed in a vector form in which
a 1 indicates failure and a 0 success of the test. In effect,
simultaneous comparison of many columns with a test
result can be done by taking a logical product of the
matrix rows complemented if the result of the test
corresponding to the row is a success.
Multiple errors can be located, though in a less
straightforward way and with a lower resolution, by
selecting a maximal set of columns each of which implies
the test result vector.
Another method for locating errors consists of
organizing a branching tree of tests so that each
terminal of the tree corresponds to a distinguishable
error or a set of indistinguishable errors. The execution
of tests follows a chain of tests in the tree selecting
either a "success" branch or a "failure" branch after
each test case until the termination. 8
The following theorem is evident from Theorem 1 on
the minimality of path set generated by the PGl\1.
A Method of Diagnostic Test Generation
Theorem 2: When a set of test paths generated by the
PGl\I is developed into a branching tree, the number
of tests in the tree (which is the number of tree nodes
excluding terminals) is the same regardless of which
paths are assigned to the tests, provided that there are
no redundant tests.
By a redundant test is meant a test of a path which
passes through all nodes and arcs remaining to be
distinguished at the test point or 'which passes through
none of them.
Therefore, location of single errors by a branching
tree of path tests is an even more straightforward
procedure than the comparison of matrix columns. Also,
multiple errors (although perhaps not all of them) can
be located by an organization of test tree based on the
evaluation of a proper weight for each test.
Errors detected in the combinational tests may not be
located in an equally straightforward manner; however,
their locations are identified at least up to a logic block
and a further isolation can be done by manipulation
of a matrix similar to the path matrix.
While the equation (5) guarantees that any error can
be observed at some of the external outputs, a Boolean
difference dz k / dy j specifies the condition on the external
inputs under which any error at signal y j is detected at
the specified external output Zk. Therefore the matrix
can be obtained by evaluating the difference for each
pair of y j and Zk.
When a matrix manipulation is not possible or
realistic enough in practice, a test dictionary is produced
using the methods above and the maintenance engineers
can look up the most suspicious error positions listed in
it during the actual testing.
Logic simulation of the machine
It is a common practice to use a logic simulation
program to determine the correct respom;e of the
machine to each test input.
A logic simulator may also be used extensively in
debugging the logic design. Because diagnostic generation may proceed in parallel with logic debugging
(without waiting for its completion), the construction
of the simulator should he as exact as possihle to the
mechanic&.l organization of the logic. For discrete
circuitry computer systems, the fastest simulators used
to be compiled from a gate-level description of the
design, a gate in the machine corresponding to a few
machine instructions (Boolean or where not available,
arithmetic operations) in the simulation program. The
ordering of the instructions was a well-defined ordering
among the gates. The introduction of integrated
circuitry and higher integration into the computer,
227
however, brought in some new features in logic design
and simulation.
Logic design cannot always precede the package
design. Physical and mechanical limitations on semiconductor and packaging technology place significant
restrictions on logic design and it is not possible for a
machine to be designed completely in detail and then
partitioned. The logic of the machine must be described
in at least two levels-~the logic of evers package type
and the interpackage connections. Thus it is less
straightforward than it used to be to compile a gate-level
simulator.
For the same' reason any change in design may be
reflected in different ways in the simulator. Either a
logic package is modified, or a connection is replaced by
another, or both. A simulator can be much more easily
updated if the logic packages and connections can be
distinguished one from the other.
On the other hand, the turn-around time in designing
and manufacturing high density packages cannot be
neglected. The logic internal to a package may not be
changed as easily as the connections among packages.
The construction of the logic simulator may have the
same nature.
Because of these factors subroutines can be utilized
to describe the logic package. When a simulator is
created using a general-purpose programming language
(ALGOL, FORTRAN, or PL/I), a procedure can define
the relations between the inputs and outputs of a
package. Then the body of the simulator becomes a
sequence of procedure call statements, the actual
parameters associated with each call corresponding to
the signals incident to the package.
The procedure calls must be ordered properly so that
the propagation of control and data signals can be
followed. There are two problems arising in the ordering
of packages. They are:
1. To which level to assign packages containing
storage elements.
2. How to order the packages involved in loops.
The first problem can be solved by duplicating a
register package into two nodes-corresponding to the
loading and output selection functions of the pack agein the graph representation. Thus, the receiver and
register-output nodes are assigned the first levels, while
the drivers and register-input nodes are assigned the
last.
The packages involved in a loop (or a maximal
"circuit," or a "maximal connected subgraph") are
assigned the same level. The associated procedure calls
are put in a program loop and executed until the values
of inter-package signals in the loop are all stabilized.
228
Spring Joint Computer Conference, 1969
Such an assignment can be efficiently programmed in
the following steps:
1. Assign levels from the first level in an ascending
order and then from the last in a descending order
until the remaining nodes cannot be assigned any
unique level.
2. Using matrix operations on the adjacency
matrix, find all the maximal loops and reduce
each of them to a dummy node.
:3. Assign the remaining levels using the newly
developed dummy nodes in place of loops.
CONCLUSIONS
A method of generating test cases for diagnosing a
machine using high density circuitry has been described.
This method is motivated by the assumption that
computer organizations are becoming more modular and
the failure modes of high density integrated circuits are
becoming more complicated and less obvious.
A minimal and sufficient set of path tests can be
generated by a simple algorithm working on a graph
representation of the machine.
Combinational logic networks can be diagnosed by a
set of test input patterns generated by a procedure
described. There are three sets of equations which must
be simultaneously solved to obtait""1 input patterns; one
of them is a new requirement caused by the high density
of circuits in a semiconductor chip.
A logic simulator may also reflect the progress of
hardware technology. A Imv-cost simulator generator
has been developed which uses a general purpose
programming language as the simulator media, in which
the package logic is described as functional procedures.
Several methods of fault location have also been
described for path tests and combinational tests.
The Path Generating l\Iethod has been programmed
in Extended ALGOL on Burroughs B5500. Generation
of combinational tests were perfonned semiautomatically. A logic simulator generator has also been programmed on Bi).~OO. A logic simulator of the Processing
Element (PE) of the ILLIAC IV Computer was
generated by the program and has been used successfully
in logic debugging and diagnostic generation.
Path and combinational tests generated by the
described methods have been employed in off-line
testing of the PE. On-line testing will use another set
of tests produced by the same methods.
AClu~OWLEDG=VIENT
The authors wish to express their gratitude to Professor
D. L. Slotnick and certain members of the staff in the
ILLIAC IV project for their advice and discussions.
The algorithm of the Path Generating :\Iethod was
developed through discussions with ~\1essrs. W. L.
Heimerdinger and Y. l\latsushita of the University of
Illinois; programming efforts were done by Ylessrs. C.
Chen, J. E. ::.vEller, W. Sterling, ,and C. Tanaka.
This work was supported in part by the Department
of Computer Science, University of Illinois, Urbana,
Illinois: and in part by the Advanced Research Projects
Agency as administered by the Rome Air Development
Center, under Contract No. USAF 30(602)4144.
REFERENCES
1 J SESHU
D N" FREEMAN
The diagnosis of asynchronous sequential switching systen/'s
IRE Trans on Electronic Computers August 1962
T KASAMI H OZAKI
2 S HASHIMOTO
Fault diagnosis of comhinationallogical networks
Journal of Inst of Electrical Communication Engineers
Japan April 1964
'
3 D B AR:YlSTRO::--rG
On finding a nearly minimal set of fault detection tests fot'
combinational logic nets
IEEE Trans on Electronic Computers February 1966
4 W H KAUTZ
Fault testing and diagnosis in combinational digital cirCltitl::
.~
IEEE Trans on Computers April 1968
J P ROTH W G BOURICIUS P R
~CH~EIDER
Programmed algorithms to compute tests to detect alld
distinguish between failures in logic circuits
IEEt~ Trans on J..:lectronlc COn1pl.lters (}rtober 1967
6 C V ItAMAMOORTHY
~l
structural theory of machine diagnosis
Proc S J C C 1967
7 F F SELLERS JR M Y HSIAO L W
A. nalyzing errors with the Boolean difference
IEEE Trans on Computers July 1968
X H Y CHA~G
BEARSO~
A.n algorithm for selecting an optimum set of diagnostic tests
IEEE Trans on Electronic Computers October 1965
9 G H BAR~ES R M BROWN M KATO
J D KUCK D L SLOT~ICK It A STOKES
The ILLIAC IV computer _
IEEE Trans on Computers August 1968
Programmed test patterns for
muititerminai devices
by FRANCIS J.l\lcIXTOSH and W. W. HAPP
National Aeronautics and Space Ad,m:nistrati01I
Cambridge, Massachusetts
INTRODUCTION
The rapid development of micro-electronics towards
multiterminal structures demands corresponding
growth in understanding the potential and limitations
of multiterminal devices and networks. The increasing
sophistication of integrated circuits will impose a new
set of criteria upon network synthesis.
In particular, through the suitable arrangements of
terminals or accessible test points of a multiterminal
device, many distinct configurations may be realized. A
. multitenninal network like the transistor contains
several realizable configurations, typically a voltage
amplifier, a current amplifier, an attenuator, or a filter.
Hand enumeration will suffice in attaining all of the
configurations derivable from such a small network.
However, several thousand distinct functions can be
realized from a six-terminal network, and the scope of
network synthesis could well be directed to selecting
one of several million functions available from a multiterminal network. A computer program has boon developed to enumerate all of the allowable configurations
so that each may be identified uniquely and non-redundantly.
tions is possible so that
N(z, x, y) = H(z, x) .'1'(y, x - y),
where H(z, x) is related to the partitioning of z,
and T(y, x - y) is related to the number of trees
of a structure with x components. 2
c. a computer program implements the algorithms
contained in the previous papers to calculate
the nu..rnbers H, T, and N, but does not list these
functions. 3
An extensive bibliography is provided in the references cited.
Objectives
The objective of this investigation is the generation
and listing of the H(z, x) subnetwork configurations,
which result when a z-tenninal parent network is constrained to fonn x-terminal subnetworks. The computer program developed will generate and list explicitly all unique and non-redundant x-terminal subnetwork configurations of a z-tenninal parent network.
The assumptions under which the program is formulated
a:r:e:
Scope of investigation
a. the z-tenninal network or device asymmetrical;
b. the z parent terminals may be utilized to fonu
tenninals of the subnetwork, or may be left free
or uninvolved in the subnetwork configurations;
c. subnetwork configurations are arrived at through
the systematic shorting and opening of accessible
terminals.
Review of related work
Previous investigations of multitenninal devices
utilized combinatorial techniques to obtain algoritluns
for generation of network functions and failure diagnostics:
a. the number N(z, x, y) of x-terminal y-port subnetworks derivable from a z-terminal parent network was tabulated. l
b. the separation of variables as a product of func-
Based on this work future investigations are planned:
a. to develop teclmiques for dealing with the
symmetry of multitenninal devices and obtain a
229
230
Spring Joint Computer Conference, 1969
non-redundant listing of the H(z, x) configurations with specified symmetry constraints;
b. to provide a computer program for listing the
T(y, x=y) configurations, and subsequently obtain an explicit list of the N(z, x, y) configurations with and without symmetry constraints;
c. to· apply these listings to failure diagnostics of
multiterminal structures;
d. to select network performance characteristics on
the basis of subnetwork listings.
DEVICE
2
13"'112A
14"'121A
1S"'211A
16"'11A2
17"'12A1
1d"'21A1
19"'1A12
2U"'1A21
21"'2A11
22$Al12
23"'A121
24"'A211
3
2
I
12A
3
I
3
To illustrate the concepts to be used and the terminology to be defined subsequently more rigorously, the configuration H(4, 2) is examined in Figure 1. Six subnetwork configurations, illustrated on the left, are realiz-
IA2
2
I
2
3
I
I
2
,...------.1
L-
B
-----1'--__
A..L..-....L-_ - - - J
-
1
I.
NETWORK
i23
Illustrative example
1"'12AA
2"'12AC
3"'1A2A
4*1A23
S*1AA2
6*1AS2
7"'A12A
o"'A123
9"'A1A2
lO"'A132
11"'AA12
12"'A612
CODE
1l~
112
IJc
121
I}
3
I
I
-L
A
8
AI2
2
2
--r--lj
3
211
IJc
Figure 2-Code for H(3,2) configurations
1....-_---1
ll~-_~
~
__2
able from a device with z = 3 and x = 2 by utilizing
either:
two of the three terminals of the parent network
and leaving the third terminal disconnected, or
b. all three externally conne<;ting t\VO together t()
form one terminal.
tl..
25"'1112
26"'1121
27*1211
20"'2111
:1;...----1
29*2211
3u*2121
31"'2112
l.__----l
1L..1----I
Larger networks form thousands of subnetwork configurations and hence require a systematic coding procedure. One method iR illustrated in Figure 2 and
Figure 3.
~
__2
~----,b
Figure I-Print-oui of H(4,2) configurations
a. the z parent terminals are arbitrarily numbered;
b. each line (or word) represents a subnetwork in
code;
c. numerals refer to external terminals of the subnet.work;
Programmed Test Patterns for l\fultiterminal Devices
231
11fJi2
4~3
SYMMETRY
(2143 )
o
EXTERNAL
TERMINAL
• INTERNAL
TERMINAL
I
,~,
SYMMETRY
( 1432)
o
f~~::C
• INTERNAL
TERMINAL
UNIQUE
ONE- PORT CONFIGURATIONS
WITH COOE
Figure 3-Unique one-port configurations ~ith code
d. letters refer to the internal terminals, which are
not part of the subnetwork;
e. position of number or letter in a word indicates
the tenninal of the parent network represented
by the number or letter.
The coded computer print-out may then be applied to
a particular network device. The HC3, 2) configurations
are illustrated on the right in Figure 1. Given the COhlputer output for HC3, 2) and the parent network structure, each of the six subnetwork circuit configurations
is readily identifiable.
Algorithms for generating subnetworks
Terminology
• A terminal is an accessible test point in the parent
network, each terminal will become either an external or internal terminal in the subnetwork.
• A multiterminal structure is a network or deyice of
more than two terminals. The computer program
is developed for structures of up to eight tel'mlnals.
• An external terminal of the subnetwork is an accessible testpoint consisting of either a single terminal
of the parent network or a group of terminals from
the parent network constrained to form the single
external terminal.
• An internal terminal in the subnetwork configuration is a parent terminalCs) which is (are) left free
or uninvolved in the subnetwork and thereby COllstitute unaccessible testpoints in the subnetwork
configurations.
• An external configuration is a unique and nOIlredundant arrangement of one or more terminals
of the parent network at each terminal of the subnetwork.
• An internal configuration is unique and non-redundant arrangements of terminals not forming
part of the subnetwork in groups of one or more.
In diagrams the internal configurations are drawn
inside the system to differentiate them from external configurations.
232
Spring Joint Computer Conference, 1969
Separation into external and internal
configurations
The program is based on the following procedure:
a. the external configurations are defined by the
restriction of I terminals, x ::s; I ::s; z, to form x
external terminals;
b. the z-I terminals remaining are constrained into
groups of 1, 2, ... , z-I to form the internal configurations, each group representing a unique
and non-redundant configuration;
c. varying I in unit steps from x to z, enumerate and
store the external and internal terminal configurations for each I and z-I respectively;
d. integrate by appropriate combinatorial techniques the stored external and internal COllfigurations at each step 10 yield the desired
H(z, x) configurations.
To accomplish this, eight subprogram subroutines
are utilized in the program, three of which-EXTERN,
INTERN, INTEG-are called in succession by a small
master program, and which in turn utilize the other
five in appropriate sequences according to the flowchart. 3 Two techniques are of fundamental importance
to these subroutines:
a. Enumeration of Combinations in Binary Cod€
b. Disj'oint Loop Enumeration and Storage
These techniques will he discussed now.
Enumeration of combinations in binary code
The enumeration technique is based upon the subroutines BIN and lVIAIN which generate combinations
of P things taken Q at a time. Each combination is
generated as a series of ones and zeros, yielding C~" ones"
and P-Q "zeros". The terminal numbers under which
the ones fall defined terminals included in each particular combination with P digit-positions in all. By systematically moving the Q ones into all com hi nations of
the P positions, the resultant (P, Q) combinations are
explicitly listed and yield the number which is the
binomial coefficient of P and Q.
Each combination is then Htored in a so called" compendiom; form", a technique previously used in processing of combinatorial information.4.5 Treating each
combination of ones and zeros as a number of base 2,
the word is changed to decimal notation as, for example,
for P = 4 and Q = 2 in Figure 4. This is accomplished
by treating each combination as a Heries Xi i = 1, ... ,P,
p
and
performing the operation F(x) =
LXi. 2
i=1
i - 1•
1100
1010
1001
0110
0101
0011
- 1+2 - 3
- 1+4 - 5
- 1+8
9
2+4 - 6
- 2+8 - 10
- 4+8 12
li'igure 4-Transformation of P = 4, Q
decimal notation
=
2 int.o
Each decimal number thus created is saved as a single
subscripted integer variable in BIN and as a double
subscripted integer variable in MAIN.
This method of storage is advantageous for two reasons. The computer memory utilizes binary coding in
its storage of a decimal number : each combination thus
coded may be recalled from its decimal number.
Efficiency and economy also results by utilizing only Olle
storage position in memory per combination.
Disjoint loop enumeration and storage
The routine which enumerates and stores disjoint
loops exploits an isomorphism between the allocation of
external and internal terminals for a subnetwork and the
identification of disjoint loops in a flowgraph. If eaeh
loop of a flowgraph is coded in binary form in terms of
the nodes it contains, then disjoint loops can be ifientified by binary addjtion. 6.7.8 The resultant subroutines
calculate and store those combinations of loops which
have no nodes in common.
The logical operation .AND. compares two binarycoded decimal numbers. If two loops are disjoint the
resultant combination is defined as a second-ordf>r loop.
The number of disjoint combinations involved in the
union is defined as the loop order. Thus,a loop of order
m consists of m first order loops which have no nodes ill
common.
The loops are stored as a subscripted integer variable
which is made up ,A the subscripts of the integer variables under which the disjoint binary-coded numbers
are stored. Combinations of terminals correspond to
loops or combinations of nodes, each node corresponding to a terminal of the parent network. In the previoli~
example of (4, 2) the loops 12 and 3 are disjoint. Labeling first order loops sequentially, consider row six and
row one, a second order loop results which are stored
Programmed Test Patterns for Multiterminal Devices
233
as 601. Similarly, 11 and 5, 6 and 9 are disjoint binarycoded numbers, and are stored under their subscripts as
502 and 403 respectively. In this way the binary-coded
numbers and the combinations which they represent
are stored in a compendious manner and may be
efficiently recalled.
of which it is representative. By repeating the process
for each row of partition numbers, the matrix of external
configurations IETER (I, J) is formed.
Sequence of subroutines
The final subprogram subroutine INTEG is called
as soon as the matrices IITER (I, J) and IETER (I, J)
are complete for a particular IQ and 1. These matrices
are then integrated systematically as determined by the
ways of combining z terminals I at a time, and as
enumerated by BE\" in ones and zeros. The number of
ones equals I and the number of zeros equals IQ. For
a particular I external terminals and z - I = I Q internal terminals, the H(z, x) .configurations are listed
through the substitution. of entries of the IETER.
(I, J) matrix and IITER (I, J) matrix for the ones and
zeros, respectively, of each combination enumerated by
BIN.
The generation H(z, X) tor a particular I external
terminals and z-I internal terminals is described by
comment cards defining the function performed by
each subroutine and is given in a listing or the program. 3
A few additional comments appear in order.
Internal configurations
After the problem statement provides the program
with z and x, IXTERX is called for IQ = z - I terminals. This subroutine in turn calls BIN" to enumerate
and save the combinations of IQ terminals taken
2, 3, ... , IQ at a time in the stored binary code. The
combinations of IQ items taken one at a time are taken
into effect and enumerated later in INTERX. The
disjoint loops of the above are next calcualted by
INTEHX and stored. SPRINT is utilized to break
do:w-n the stored disjoint loops into their unique configurations and enumerate in numeric code the proper
internal configurations implicitly represented by each
stored loop. These configurations form the matrix
IITER (I, J).
External configurations
The suroutine EXTERN is next referenced for I and
x terminals. The partition numbers subroutine PART
is then called by EXTERN to return how I terminals
are restrained to yield x tenllinals.
For example:
P (4, 2)
=
[!: iJ
For each number in a row of partition numbers, the
combinations of I tenninals taken that number at a
time are enumerated and stored.
Once the combinatorial enumeration of a particular
row is accomplished, subroutine LPORD is utilized to
calculate the disjoint loops for those combinations of the
row.
Since redundant loops may be generated for a particular row if t\""O or more numbers in that row are equal,
this case is accounted for and only non-redundant loops
are enumerated. As each loop is calculated the proper
numeric code is generated for the external configuration
Integration of internal and external
configura tions
Output format for configurations
The configurations thus generated must be represented in a unique and convenient code. Previous workl,2
utilized upper case letters for external terminals and
lower case letters for internal terminals, identical letters
and type indicating those terminals of the parent network that are joined to form the subnetwork c<;mfigura. tion. Since a computer will only print upper case letters,
the lower case letters were replaced by numeric character. A variation of this alphanumeric code is used up
to a point just prior to print-out.
The pre-print-out fomlat for each configuration is a
series of positive and negative numeric characters.
Positive integers correspond to external subnetwork
terminals; negative integers correspond to internal subnetwork terminals. Identical integers and signs indicate
terminals of the parent network which are joined to
form the subnetwork configuration. This coding scheme
is perhaps the most applicable to a computer setup for
testing multitemlinal devices and for network analysis.
An adaptation of this fomlat is the substitution of
upper case alphabetic characters for the negative
integers, since this scheme provides for greater visual
clarity in identifying the unique configurations. A listing
of a number of subnetwork configurations is found in
Figures 5 and 6.
Applications
Identification of unique network functions
The computer print-out for H (4, 2) is given in Figure
1. These eoded subnet,vorks are relevant to testing and
·Spring Joint Computer Conference, 1969
234
HI
3 2)
h(
5 2)
1*12A
1.12AAd
,.1AC:
~*~~~ciJ.t
3*~1~
j.12tiAA
4*liAAt.
tl*i2A6C
6*lAZAL;
7*lA2t.lA
8. 1 LI2 .. ..1
9*lAZAA
10*lA2oC
1h1;\A20
1.2*lf,02A
13*10A2A
1'+*1AA2A
.. *11Z
~*1d
0*<.11
1~*1Hb2C
!::>b*dlAi:l
!::>7.11A2A
!::>e*12AlA
!::>9.dAIA
uU.llA2u
bl*12AlrJ
o2*"lAIlJ
'o3*liAA2
64*12AA1
0;'*.:1 AA 1
Ot>.11 ALl2
67.12AiH
ob*dAtH
o9*lA12A
70*1AZIA
71*2AllA
72*IA12b
73*i .. 2111
74*ir,llu
77*, .. 1111
7<:i*iA102
79*IAc.tH
oU*ZAlbl
BHIAAIZ
114*2111A
11tl*Z211A
llo • .::1~1A
11 hdlZA
llb*-111A2
119*112A1
120*1<:1A1
121*dlAI
122.221A1
123*212A1
12'+.211A2
1Z!::>*llAl':
12t>*llA21
j.27*12All
128*dA11
129*22A11
13U*21A,,1
131*21A12
132*IAllZ
133*lA121
134*lAZ11
135*",,111
!jb*2A211
137"Z,,1d
138*2A112
1.39*A1112
h1211A
2*12Ad
3*1,:.2A
10*1AAt.i2
1H1AbA2
Ib*lUAA2
19"'111AA2
2U*1A6C2
21*>ll,Ao
*;l.12dC
20*A1A,0
27*AllJ2A
2d*01A2A
29*,,1A.lA
3u*"lb2C
31*A1Ao2
.32*A1E'A2
.33*61AA2
d3*211All
0'''1 .. 612
141*A1211
142*A2111
lI+3..,A22lJ.
144*A2121
1~*211A
.3~*A1bC2
10*11112
17*12A1
18*<::1A1
19*1A12
20*1A21
21*2;..11
22*A112
23*A121
24* .. 211
25*1112
26*1121
27*1211
26*,111
29*i211
30*2121
31*2112
.30*AA12i.3
37*i.i312A
3tl*oA12A
39*AA12A
40*ALl12C
'+1*AAlti2
H(
* 2)
34*A1,,~2
42*Au1A~
43*tlA1A2
4,+*AA1A2
45*Ao1~2
46*AA812
47*A5A12
48*t:lAA1i
49*AAA12
50*AI;,C12
51*112AA
52*121AA
~3*,11AA
~4*1l2Ad
55*ldAti
7~*IA1"2
7o-1A2Al
8~*1AB21
Bb*<::AI:il1
d7*A1l2A
8d*A121A
89*,,211A
90*A1120
91*A121d
92*A21l1j
93*A11A2
94*AI2,,1
95*1I21A1
9b*Alld2
97*A121H
9b*A<:lBI
99*A1A12
100*A1A21
101*A2A11
102*A1B12
103*A11321
10**A2811
105*AA112
106*AA121
107*AA211
10&*Ao112
.L09*Abld
1l0.Ato211
111*1112A
112*1121"
113*1211A
14~*A2112
1 .. 6*11112
147*11121
148*11211
149*12111
1~0*2111l
151*22211
152*22121
153*22112
154*21221
15~*21212
156*21122
157*12221
~5e*12212
1~9*12122
100*11222
H( 4 3)
1*123A
2*12A3
3*1A23
4*A123
5*1123
6*1213
1*1231
8*2113
9*2131
10*2311
H( 5 3)
1*123AA
2*123AB
3*1ZA3A
4.12A38
!::>*12AA3
6*12Ab3
7*IA23A
8*1A23Eo
9*IA2A3
10*1A263
11*lAA23
12*1Ab23
1:3*A123A
1,+*AI236
15*A12A3
16*A1263
17*A1A23
18*A1823
19 .. AA123
20*Ai:H23
21*1123A
22*1213A
23*1231A
24*;::113A
25*2131A
26*23111>.
27*1l2A3
28*121A3
29*123A1
30*211A3
31*213A1
32*231A1
33*11A23
34*12A13
35*12A31
36*21A13
37*21A31
38*23A11
39*1A123
40*1A213
41*1A231
42*2A113
43*2A131
44*2A311
45*A1123
46*A1213
47*A1231
48.A2113
49*A2131
50*A2311
51*11123
52*11213
tl6*d3A14
~7*d113
~8*Z1l31
H(
!::>9*21311
00*23111
01.22113
02*22131
03*22311
04*d213
65*21231
06*23,11
67*.:1123
b8*21321
09*23121
70*21132
71*21312
72*23112
73*32211
74*32121
75*32112
t> 4)
1*123,+AA
2*1234AB
3.123A'+A
4*123A4b
5*123AA4
6*l23AEi4
7*12A34A
8*12A34b
9*12A3A4
10*12A3E,I+
11*12AA34
12*12Ab3,+
13*IA234A
l'U1A234li
15*1A2.3A*
16*11123b4
l7.1AZA34
li"IA~B34
19"'IAA23 4
20.1Ab234
<:1*A1234A
22*A1234B
23*A123A4
24*1.1236'+
':~*A12A34
H(
~
h 1234A
2*123A4
.3*12A34
"*1A234
5*Al,34
6*11<:34
7.12134
B*1231~
9*123 ... 1
10*2113'+
11*21314
12*213~1
13*23114
14*231 .. 1
15*23'+11
4)
20*A1263'+
27*AIA234
2tl.Alb234
29.AA1234
30*IIB123'+
j1*1l234A
32*12134A
33*12314A
34*12341A
35*21134A
30*2131 4 A
37*21341A
38*23114A
39*231,+IA
40*.::31111A
41*1123A4
42*1213A4
43*1231A4
4'+*1234A1
45*.::113A4
46*;:131A4
47*2134A1
48*Z311A4
49*Z314A1
~0*2341A1
!::>1*112A34
!::>2*121A~4
~3*1l231
!::>3.123A14
!::>4*123A'+1
54*12113
55*12131
56*12.311
~5*~11A~~
~7*Z13A41
!::>tl*,,31A11+
!::>9*Z31A41
oO*<:34A11
61.11A23'+
02*12A134
03*12A31'+
0,+*12A341
05*21AI3'+
06*,1A31'+
07*21A341
08*23A114
09*23A141
70*23A411
71*IA1234
72·1A2134
73*lA2314
71+*1112.341
75*2A1134
76*2A1314
77*2A1341
78*2A3ii'+
79*2A3141
&O*2A3411
b1*A11234
d2*A1a34
/)3*A1231'+
&,+*A1Z341
jj~*"21134
b6*A21314
b7*A213'+1
68*A2311'+
1:19*A23141
'.I0*A23411
91*111234
92*112134
9:3*112314
9'+*11<:341
95*12113'+
96*121314
97.1213'+1
98*123114
114*223114
115.223141
116*d3411
117*212134
118*Z12314
119.212341
120*232114
12h2321'+1
122*,3Z'+11
123*;::11234
12'+*d3214
125*.::13241
126*231214
127*231241
128*,,34211
129*211324
130~21312'+
131*213 .. 21
132*231124
133*231421
134*234121
135.211342
136*213142
137*213412
138*2311:'2
139*<:31~12
140*234112
141*322114
1'+2*322141
143*322411
144*321214
145*:;21241
146*324211
147*321124
148*321421
149*324121
150*321142
151*321412
152*324112
153*342211
1~4*~44::1a
155*;j4,112
99*1231~1
100*123411
1u1*Z11134
1LJ2*211::i14
103*211341
l(j4*213114
105*<:13141
106.213411
107*231114
1U8*<:31141
109*231411
110*234111
111*221134
112*221314
113*2213'+ 1
Figure 5-Short reference table for test patterns
network analysis since, as two-tenninal configurations,
they identify unique driving-point functions. The technique of generating the nunlber of external tenninals is illustrated in Figure 3. Configurations can be identified
which have' the same external configurations, but
differ in that their internal tenninals are joined or
left disconnected.
From H(4, 2) in Figure 1 it is feasible to generate
network functions from four-ports of known symmetry.
Two examples, Figure 7, define the problem to be
solved next; namely, to eliminate redundance due to
symmetry of the network.
Thin-film
Re
networks
Thirteen unique network functions are attained from
both device A and B in Figure 7. Each circuit configuration is represented by one of the thirty-one H(4, 2)
configurations, and may be identified by the letter A or
B next to the appropriate coded H(4, 2) word and under
the circuit it identifies. The eighteen coded words not
representative of unique network functions, do identify
redundant configuration::; due to rotation of the device
about its axis of symmetry. Redundant configurations
are designated by A and B under the appropriate circuit configurations.
Reference tables for test patterns
To test devices and systems with a small number
of terminals, say z < 10, reference tables to identify
unique test patterns are desirable. From the test pat-
Programmed Test Patterns for MultiterrrJnal Devices
U=--123011 ••
u"auaSi
n •• IAlUA
11"23.&,.
U"UU<311
In.....,U
U"·dSl.U
J"'"
...
na
U ••.,;I:lU_
:'.d~l.
u . .",z3.u
• I.",2U'
.a.,,)oo"u
.._",un
_lolIo"'.
)0012-"
"1.,t.l2~
".12""3
U"·dlll"
TieloU.,,",
1l0.cl'12"
Ul.lll,:.
"O.olblcl
.!.~,I"/.I
2h1Mol;"
.,.•• UlE!.
01""l'"
~
.. , ...o!
2.2e ....JIGI
2,.' .... "..
2s.-1112l8(
U1'e2U"ll
"'·.:""'U
...... "oi,..
a.z.... , .. ,)10
....... 2)-
J~ .... ,.,c.i!
,,,.o/,,,",l.
1l~.211"'"
"'.2UU"
~•• l'<""
27.j,.I2.'
" ...... 11oo:
1a.AUta"
1')oo1o>1.&21.l
....''''12'''''
'''12.''.'
"...,
7Ck;':~U
n.".I.UllI
'''111>2.
~.~ ....t
,-."..,,.
1~ •• 2"3C
... 12...,'
1l·1~'
'Z.l.....a'
U· ... I.ill&
.... Uoiltl
IN-zaU3
Ia.J.21AoI,l
121'.,Z3A&1
.2aoo.zllaaJ
'''''''oZllA_1
?O."I~X
IZ.U..."
l.)oolaa,.
,...ZlIIIA
2'U.ZUIU
IoN_un ...
14!1oooUlAAl
......1..,,.
IO_U")lK
,,·U.u.38
,0.1.2."
1'2·IUlIo
".~"2l.
'9.~U.~
lillr..lA2.U~
UMotl.....
11"01:12"..,
.hl"....
17. . . . .2»
12)oo;U.lA&e
IU_2n.,.
".'2""""
'-lolA'"
2»....2311.
'.,..,aAUlA
1.2... ,21 • •
I.U·12.)1;' •
235
,........ 12.. 13
,.~oi'.i! .. '1
~.;:J.i!"'1
Sts.-l22.U.
S,:r..3.Zli!ll
ooo.z.....sUl
sa".)2llU
"1I"Jl.C211
~31U2'
~.I.2'i"~
UI·4'2U,",
112.d13••
".:IU
• O"oi'"
~U2""S
..... 'c3/lov"
!ooo11l2.h:O
.... ,.i!"..:O
e.,.. ,..~
- " I )..... ~
~213/101.$
_21"'~1
ll"oi.n~!o
... Il,.....~
10.,4''''''''')
.'.oi.5l1W'!o
Ic!ooo...:"I""~
..... "I.. ~1
10• .:""U"~
7h2""'1!>61
'.i!·."'!ol"',
1""oiU""':;
,,... ,, .. S
'.)eUi:)l.il~
1·7.1.... .sa..~
1geoi,so,U').
.i!... ~,so,I~1
l,pZJ,I.'!ol
ll:r.""" .. !oU
l ..... I.'4')It!o
U900U.oZI)o1.S
1""lolll ...S
121·11.2:",",:.
U"·II.2:"'"SI
·!'eloisa.. SoI
l:O.oiU"!>l
1_... .lIl ..:.
,~.Il' .... '!o
, . . '... ,....I'!o
1ge1l.....)Io:,
2<>.14'....lIt::o
"1.U.2.h!J4
U.U.2.h!>6
l').,&2)e.1.!O
.1.4'I.)Io"~I
~1""'loIo .. ~
'2"."ll, .. :.
127• .i!.SU"~
12...... " .. 1'
Il"k.o")I"~'
1""•••""').
1.51-..:"""'1:01
1»*l."',U
l'l"ll ... "..~
'"... . 12I.Jot$
1):O•• 12.l1"S
.l,...,.2lel!o
Uh&Il""!o1
.hoi",":"'U
l .. ,.""lJ"l~
1 ...
l"!o"i..2JolI .. ,.1
d,l .. 2J.i!"1S1
.U-l·
•.u"::'U
oiO.s..1U.)Io!o
2~)·32 ..... I~~
IJ1 ....... ' ...'
1.)o)",,'4'C"
1.we...:.I.::6<.
1.... )<01:..1
l".!I)4oA
hloi"".:.o.t.
G·loi.)oo,,~
"~,,,'''''I-
_·,1.5 .. " . .
.. h~I''''),.1II
_~Jl"'~
14'''1.i'.5M~
12'J.lc,so,,II:'"
IZ".U""ol!olo
lZ')..ll"....""
Il .. , ... ,..U.!ou
1')..l~,"!>lIo
1(•• loi,....".,
"......,.,
Idel.iJoOoou'"
'''·I ...
' ' ' ' !>O
1_,:l'I',lot.oi.
'''''I"I''''=-e
BO*loiU,,!IoIo.
loi"· .. I"...::'I ..
1J8·dl.
IJJ· .. Jl ....::.b.
',.. ... Jl ...!>.!
llt>4oijliU!oI..
131 .... ,..' .. :.401
2~·1"_J·"'''''
Z".U""":Ida
~·I4' .. "" .. :'O
••·loi.""':-
Uh .. sa"!>I"l
Ul.l:· ... " .. ~ll
,"lelll14'.5-::;o
1.... IA2'Jt>.I,.~I""~
I-"'.... '~.....
1"''' ... ··la~.
1.." ... ~I ..
1" •• ""I.l.."
".i
"7... J"4'~11
• .11001 ... .11>0:..1111
....
.').."",
.. ......
~IIJooo~
1..... '2"JOo')e
1 .. ~·I~lil' .. ~
l&oeU."".IooI'.rlo
UI7.Ia.:""~I ..
1'itoo ... Alll"':.o
~I .. l'';ot;l
l ......... U .. ~ ...
1t,I'..... 31 ..!>bl
1'Ie...... .)IIII!>u
l'r'l>.l.""'U.
' 1!0· ...
~lH)·l.,..I,.,1
').
.II............:..
3ij·12.U"'!oo
_d"'l~
d1 .... ,..~I ...
..a.oi I "':"'1
.... 2JU..!:>Ao
9\>· .. JI"l~
' ..... '01.,51.0<.1.:...
~I,)).l."..,..'l
1~.·U.1l. .. !obl
1""'cU"Jto.!Io
1"""1"...1:..,
I.!..t.":'I ..
"O".illl2JI"
.l~llol"""'~
So·lAl~:.o
1~1"'1"""~1
oi,)',lOlt'''.)IoSlj,I
dO.It.2II""'!oo
.:UaA.!I'»oo!to
oil""&iI""S.
Sha.u:JAot.s..
""lAl~
9o
'1Ml.12.1~
lUl.1.i,. ....!)co
10".123/101.::'"
IO"Il"'~.""
IU"·l.""":o.Io01
ilMl·"I3I ...:..
:.0... 12"":"
ag,a..I.JIt!ooAl.
lU1·d,so.~
•• ll.jIi,!OO
.O'hoil.)t1~l
~.AIZ.~:.o
))e.. 'Itl"..~
11o..i!JlIOlA!ao>
111·2""1.:'"
:O-I.11Jl.lOl'S.o
~!o·""12"'~
1::o9ot"""':!>II.
ll>O ... ".... '!o16'
I1l.~""""'l"
IU·~.$I"~I
~tl""4'I""~I"
cl"'I..i!I.JIt,.,
... 1...a.tU"I:!oa
lI7·".UI~!oI ..
.. 1••
:..1
1..1:,. ..
",1·oi~11
2"lIU]Io')o
.. cO ••"S"l!o16
",U"A2:]oolSOI
.:..a.A2.31t)11.
"",le",""!ol.l
,u...0\2]oo:!>all
1O~.2U.)ttol.S.
.. T."I2""'»
...,.... 12Joe
h •• l.ilAJol~I.
1.. 7.1.i!."'561
....... .I.iSl1"::""
".l1.,dh,:..
"'''.Ulh~h
,,"'''I~'h:.flo'
oilOO.,oi'''II:;'
.... I·I",..I~I.
oi"i·,,,JooI~'
oi_"'''''''':'I1",
oi .... ·loi,..~lol
• ":"'t.:lco
191 .... ljot.l,.,
lw· ..... I,..~'.
4'100·""::"'IJI
..... 1.211JI .. ')o
.: ... ·~Il""l:..
" ..... 211"":.10
.:.o.... U"":.e.1
.. ~1 • .21111"'!oo
",!W • .:ll'''ISo
... :0').2131":01.
:I:I.I'lI."2A
4'.7.~!w".l
~9b·~121l"~
".~ ... "1"32b1
~"7e"'12'h:;'
,').!ooo~"":.o.I1l
~'Ige.i!1'<'''''':!>1 •
J,oG • .i!,2.)eoo:.,
JO'.",,,",I''':;'
lOl.l.l21"1;"
38"'.2lil"~I ..
It>0 .... 1,..:...21
.lotol·JJII":>Zct.
JOIo"ol.1l2'''S.l
.5O~.212"lI!oo
.)Oboool.s.a"l;l..
.. ..,.ill' ..!>I.
" .... ~.51h~
.. Zh»"'!oll ..
...
..
. ,
.:7!o.2"1~161
... 7b... .)Io1~11
d7 • .I:.1It').llIo
... 7/t.l"..~11.1
~·,w.I~1
e.i!c>.""ll.~
"l1eJoil"I~l1>
..... .sd..~.".
...
""',J,i'.--.al
.. lI&e,J'U
....Rall ..:..
. ,.. 3aZl.1~
.)Me.t.aa'.Sh
,,"",'''''a,.$601
MGe).Ull11S.
)91·.i2200IS1e
,w,i.J.22"ISOI
::>9Soe2l.1~
::>97.11""1
.''',),l4o!t.,I2a
),....iIJI ..:..• .I:
.s.o·4'.)IoU'!ooi
.M'e.ZlIItUtJAt,l
Je2 • .i:"l~U
=>"2.21"'81
::09le2l.18'
,..,s·"'''''1'-21
....~n
....... U . .!>ltol
.....2·.l...
.... .,.3,2..:.11W
....... ~ll
."!>e.)lOl!otolU
... _~'I!oe
ll.... II ... AI,
31".l"I&to
""'·2".1
olh.i!.U .. l
."'·1.11.,-,
.. "...I ....ll
_li.1A2.U
.,.1&2......
cu .. ·.:.".I ...
.uhl.ll'''C~
loll..... h"2
lu~.u.I"C~
"1~UC1"'"
I
A,h.I" .. l"
~l42'o::"ll
"u.Joo2lZ.'!Ie.
":O.)e)ro2.12Sole.
...
"'.Jb.,
..n.u.1..
.uc.eU..
..ooe.l.lIl.lI.S6
a.ool,2.11oo1!oto
",.i'i'·II"""::ot.
.:.... c2~UI..,.
... h24'JI.IS.
• O)eJ.lfo.il~lh,
~..se211.h!otol
.50'."1... ' .....
........ oltIIZCI
!O~2.l1.i:Utl
"""IlI.U,
~:.o.oiU"llo
!o~"' .. U..:1'
-_.
.,..7.1 ..... 11
....e2.. UlII
....... 24.20111
..::.t..2"',8ZI
..)I·,u.'III.i!
~.1""112
ll6.)e.2"'UI
),IO.JoOl2C.lI
~U"'I"
..:u~.oil ... CI
·,'1·".... lll
.i!dO.l"I~'"
~ld·"""'I4'1
se.1II2.Kq
•• s..l.AItlloolC
U9e11082A(..l.
,2-IIII8.iIIItA.
Itol.lbKZ-.o
........,
' ....... 0URC8
1~11oK_
'.'.tlt6A2llC
l .... l.cA211a
.-..u.c:
l'h•
,9l.IMC:Me
19)elAC1t.1:.
'900.1"".
'9:!>.I~
I'''.'''~
l .....IIlINIaol
.i:1I"'~
",.,.....,..
.. 0•• ,*2Dl
.:_·1.......
dgeIMIIC"
.:Io•• .tIIaiiIItaD
dl.'1.8CIoiO
J.l ...
·'MICOafI
a
"~.""21!0.2' ..
...0.34-21:0.,1
_1 • .)tIZ:0121 •
....
._._--
I~'.'''a../Ul
~~.".2:..z1'
")'."'~.II
I~w.w:. . .
1""'1~
lllCl.1A&62M
•••• 1~
laiel...,..,.
.:00.11tAo\l8I
u.o.ueclI,M
' ..... oiCI21"
I"'.~
''''''ldC&au.
1''''I&M2eto
1-..........
1!>ge,IiI8C.!/JI(J
al'.lI.1U,
112.1&8C:,z.u.
17)eldMiAC
'77.'~
.,..- .-.-- -....'l5oe'fIIUAdC
Ue..I&ll2ACB
13'... &(oi....
"".I':'I..i!AI:*
l .... ll»&.t~
lJ~·A02Ui
..... It2I.
::>7:0.ll"lzr
!o7•• UIolI1'
.17·,iIINIIJCO
"'l.i!&llCoWl
""l.t.HCO"
'1I ..·.I.Ul
'01 ... ~211
~12""'4'''11.
~r,
5rf>el~O.
S'·laa.ucg
o"I'·.uUIl
,"QIu.2U
">C>IleU"la'
'!o11a*12"U.
~1'.""b.c1.
l,,""UAto(2
74'S ........ " l
•• '''U,U.z.
~'.II''''''
~I"'''lall;>
:'1~·""'121
........ U ...l
"::'-"UA21
1>9b... U.lI
~'~l
.. u·."uu
.......
":".).a..i!oIoI1oo':AA121
o::olIC
~
..,...."":iI.11
JI't,5oe~l'o
,J94o.3l'2OI!o1.1
~I".
.. .l~ ... I~1
.... 9000~n •••
.:7ged"~l"l1
,,,..s.
U7e112,s,_'!oo
..
"""JoO~ iUIl"
.. n·""!>ofd.1
."..",..~
.:.......!""'!.ltolU
".,.UII.)Io$o
........i!.o1.11..»
~.'.2 ... 1""'.rIo
" .... 2"'"..~ ...
d~·llloi""!oo
~".i!U4'1I1
.. 7"·,5C.U
lO'."U810/
70Z."11112,
o..s· .. JI"~Ib>
"...~,..,.u.z.
~.,..l~
,.s-.. u.,
~7"ll.1111
"U·.l2"~.uI·
.IO~.2l'>1J':020
"':''''oil''''~1
.. ~ • .i:I"'~" ..
_~)e.2'!o'.z.
"10.J.i!.12I!oo
"'I.J2"U~' ..
"la·U",lOj4,1
"1e.·~1'''l!*
.. !ri· ...
....... 21..5<0:"11
.2.'1 .... Jlll~
_~·"'l:.o.lll
)79.oil. . ,.-
.I:O"J./."~.11
»'·. . ,..I!ooll
....,..d....'.
.."'."1 .......
JPl"I"~.
... ~hlZ ... U·
....... lI
... 2"''''1''~1
!'c>\t• ..:I.tS(,1
1&,.. ..... ",•
".U,,",.((
.'·.!I.u.~7
:."I·oil.. I· •
,.w •• 11 .....
~ .. 4'·' .... I ...
' .... 1 ....... "
11·loi'·"·
• '.loIoI·I· .. t
'''.I4')to~11
I::'·U""'I
."11 • .s.:"7
,,6"':"'.i!I:'lc
111.';::1.)001)1
:..,.,. . . '1..:
........"" ...
.. 1.5.u I2A ••
1...... 1.&(2
".Il"'~'
9000112"':..'
10·1.4'1)e:",
'hl4')'.:"7
IZ·'2)d ••
U*lOlAAAA
12*12AAllB
13*12A8"B
11o*12A80A
U,-12AUCO
16·1A2AilC
17.1A2IlAC
111-1"2I;1CA
19*IA2dBC
20-lAlBCB
2hU2BCC
22*lA2AAt>
23-1A2A"A
211-1A2I:1AII
2!)*lA2dlld
20*U2AAA
27·1A2AbU
28-1A21M8
29*IA2uUA
30_1A2BCO
31-111A2uC
32_U82AC
33-1A82C"
3'+_11182UC •••
3~-lAB2Ctl
36_lA&2CC •••
37.UA2AB
3i1_1AA2UA
.)9*IA02AA •••
110. 1 AB'?iJd •••
'thlAAZAA
"2-1AA2&6
"3-UB2Ad
.. "-lA82UA
/i::>-IA82CO
.. b.1AAUlC
'I7-1AElA2C
"8-lA8C2A
,,9-1AbIl2C •
!>O.lABClII
't:i7*A1tld12
1158*AIB821
.. 59-Albtl22
.. bO*A1AAI2
"bl*AlA"21
.. b2*AlAA22
/ib3aAl1:!C12
'Ib""'16C21
/ib!)_AIBC22
.. 66*AA1128
"b7"'AA1218
"68*AA12211
'I69-AiU12A
1170.AI3121A
.. 71 *AIl 1 0!2A
,,72-AbI128
1t7,)-AI>I0!1U
.. 7/i"'iH22d
't7!)*U112A
.. 7b*AA1,IA
'I77*AA122A
.. 78_A8112C
1179*A0121\,;
..80utH22C
1181&,\AU1l2
oI82*AA121H
IIIt3*AA12~2
,,8/i*AUll/oO!
,,85*A012"1
'I8b-1otI12A2
II~H*AOlla2
/iItS*AtU2tl1
1t89*AIU2U2
'I90.AAl1,.2
1191"AA12Al
.. 92_AA12A2
.. 93*AIHIC2
.. 9/i*Ad12Cl
.. 95_AB12'2
,,96-AAlIU2
.. 97*"AI621
/i91t*AA1822
"99-A8141.2
!)00aA81A;.!1
~OhAalA22
~02*AB1612
503."u1821
!>0"-Alltu22
505.,.A1II12
50b*"A 1 A21
507.4AIA22
!)08*A81C12
509*AulC21
5H'-AiHC22
511·AA8112
512_AA1l121
513*AAB122
:':11"-10610112
U~"'laB2b
~8.1A8A21;1
~9.lAI;B2A.
bO-lAO'20
61*lAAUC2
62-1A8AC2
63.lABCA2
6"-lABUC2
65.1ABC1)2
66*lASCC2
67.1AAAu2
68-1AAuA2
09*lA8AA2
7o.lABBtJ2
71*1AAAA2
72-lAA882
73* 1 AbAI12
7"*lABbA2
7:':1*lABCD2
70*A12AbC ••
77*AI2BAC ••
78-A128CA ••
79_A12bliC ••
80-A12UC8··
8hA12s'C ••
82-AI2AAU ...
83-A12AbA ••
b/i-A12tlAA ••
85-A12UBu ••
8o_Al2AAA ••
87*,,12"1;>11 ••
88-A12UA6 ••
82!>*AuC122
!)2b_lU2AA
!)27_1121,u.
~211-1211AA
!)29U222AA
!)30-U22AA
!>31*1212AA
~32_122UA
!l33*1112Aa
53"-U2lAli
1lb-AIAA2A
117.A1Atl2S
US-Ai-bA2b
119_AI61l2A
120-AlbC2U
l<:1-AIASC2
122.AIBAC2
123.AIBCA2
1211*A18dC2
12:hAIUCU.1
l;.!b-AlhCC"
127.AIAA02
128-AlASA2
129-"18AA2
130-AlbuS.1
1 31-A lAAA2
132_AIA8U2
133-A1BAb2
13"-AIB8A2
135-A16C02
130-AA179H1A22S
580*12A128
!>8h1.!A'10
!>82-UAIA2
!)il3*11A'?Al
!)90* 11 A2dl
::>91&12AIBI
592_12A2U2
~9~*12A201
59b-11AA12
597*11AA21
!)98*12AAll
599* 12AA22
bOO*11AA22
bOh12AA12
002&12AA21
603.1~AiU2
565_U2Aa2
5b6*121A82
~67*122A81
b2~.1A12Al
568*11A12A
:>6b2*112AIl1
~63*121Abl
~&"_122Atl2
~72_llA22A
~0"_A8A1A2
0:05-Aoolu,
206-AO\AlA2
207*"AtJ182
208.ABAIU2
209eAOBlA2
210.AuCIU2
21UAAbC12
212_AUAC12
213_AUCA12
21""'88C12
21!>UBCd12
216-AUCC12
217_AAAti12
218 ... ABA12
219_AUAA12
220*"tJb812
22h/OAAA12
222*"A8612
223_AtiAtl12
22""'BbA12
22~*A6C012
··
··
··
·
···
···
··
···
···
···
···
··..
····
··
··
·
····
b31*lAlltl2
·..
bl2~lA12bl
b33-1A211H
b311*lA2lb2
b3!>-IAI2B2
b3b·1A2lu2
b37*lA22iH
b38_UIA12
639_UIA21
6,,0*lA2A11
0"1_11121022
6"2.lAIA.1.1
b .. 3*U2AI2
b""*IA2A21
b"~.lAlIH2
b"o-lA1i.l21
b"7*lA2u11
b,,8_lA2822
~89011Alti2
00"011AB21
b05_10!Abll
bObo12AtJ22
o07-11AIl22
bOb_12A812
bD9*12A821
bl0-1A112A
6U-IA121A
bI2*lA2UA
b13.1A222A
6111_1AI22A
b15HA212A
blb_U22lA
617*1A112d
018.1A1210
bI9&1A211U
b20*lA2Utl
02h1A12,8
b22_lA212U
&23-lA221s
b2"-lAllA2
559.121AA2
lO~~!:A.lle2
,,03_AA61A2
58~*12A2A2
~93-11A2U2
:>IIb"1l2Altl
!)119*121Altl
:>50*1221.26
55hU2A28
:;52*121A28
55:5*I22AI8
::'5"·111AA2
55:>*112101.1
!)!)&*12lAAl
557-1.2.;1""2
19a*ABClA2
199_ABBIC2
200UdC182
20hAtlCIC2
::'8'1-1~AlAl
5910* 1210 Itl2
~"7&111A28
197*~AIC2
586_UA.1A2
::'87*12AIA2
::'88-12A.1A1
5~!>*1211AU
51+1a112AlA
!>II2*"lAIA
5113-122A2A
!)II"*112A2A
5115*121A2A
5"0"122AIA
18~.AuCl"tJ
18b.AUC12C
187*AAA1,u
188-AA812A
189_AbAl;.!A
190UBB12U
19hAAA12A
192-AA812U
193.AtiA1
536_122lAu
:>37*1120:1.11
!>38_1212A8
~39*1221Ad
~"O.111A.:A
167 . .UIAC2
168*AtHCA2
169*AIlIUC2
HO-AtHCli2
17hAtUCC2
172*UI1182
173. . AIUA2
17.. UIlIAA2
175_AS16U2
176*AAIAA2
177*AAIBB2
178-AIHA62
179*11ulBA2
180_AtnC02
18hAAiH2C
182-ABA12C
183u8C12A
1811*AUB12C
6119*IAl~22
b50*IA2Ull
b51-lA2821
052-1AA112
:>53*lAA121
b5"_IA4211
..5!>&1AA222
b50.1AA122
657*IAA212
058.1AA221
b59*lA1l112
bbO-1Ab121
001_1A8211
00.1-1A822,
b63*lA1>122
bbl+.1A1:>212
ob5*1A8221
b60*Al112A
u67aAU21A
bu8*A1211A
b&9_A1222A
b70_AU22A
b71*A1212A
b72_A1221A
b7.3 .. A~1.l.2!l
b711*A11210
b75aA12118
676_A1222B
b77aA1122t1
b78*A121213
b79.A1UI8
b80*"111A2
b8hA112Al
b82_A121Al
1>83*,,122A2
u. 08"_AI12A2
••• b85_A121Al
b86.A122Al
b87*,,111112
b88-AU281
....
···
··
22b&1l2AA8
;.!27*121AAIl
228-122AA6
229* 112I1BA
~30*121IlBA
23h122ABA
232*11.2AU8
,,3').121ASU
23,,* 122AUIl
23!)Hl,AAA
236*121AAA
.. )7-12cAAA
.. 3S*1l'AIlC
0l39.121AI>C
2110-122ABC
2'11*11A2A8
2112*12AlAd
o:.. 3*12A2Ab
2'1"*11A2sA
.1"5.12AIllA
"II6H2A2uA
2'17*11A268
2118*12AIBd
2 .. 9*12A288
250-11A2AA
25h12AIAA
~52·12A2AA
25;3"'llAZbC
25"·12AI8C
255*12A28C
2Sb-UAA2U
,,57-12AA1B
25h12AA2"
0:59-UA02A
.2f>Oeli!A!HA
"blH2"82A
262-11A828
263-12AIHb
26'+_12A828
265H1AAZA
26b*12AAIA
207H2AA2A
2bll-llAU2C
,,09-12AbIC
270_12A62C
271-11AAU2
272_12AAdl
273*1"'1.82
27"_llAUA2
d5*12AdAl
276-12AUA2
277-11AlJu2
278.12AS61
279. 12A6U2
~80.11AAA2
211lal;'!AAAl
282-12AAA2
o89*A121bl
b90_A122u2
b9hA112b2
b9c-A121b2
b93-A122bl
0911*" 11 A12
b95-AllA21
b9b.A12Al1
b97-AI2A22
1.>98-A11A22
099*A12A12
700-A12A21
701·AUd12
702-All,,21
703*AI2d11
70 ..... 12822
705-AI11322
7Ub_A12u12
707*AIO!U21
708*AIA112
709_AIA121
710-AIA211
71hAIA222
712_AIA122
71,)_AIA212
71".,.lA221
71!)-AIU112
71b-A13121
717aAlbll1
718*"18222
719*AlBI0l2
720.AI8212
721*AIB221
722-AA!!!2
723uA1121
72/i-AA1211
725&AA1222
72b-AA1122
127*AA1212
728-AA1221
729*AtH112
730*"tJ1121
73hAdl,u1
732-A.,1222
733*"U1122
73"aA81212
735_A81221
736-11112A
737.11121A
738-11211A
739*12111A
7"0*12222A
7,,1-11122A
"'2.11212A
7'1~*11221A
7""*1211lA
",5.1.112lA
7116_122114
....
"8~*UA8C2
2811*12A8Cl
c85*12ASC2
28b*1II12AB
287*lA21AB
289*lAlluA
290*lA218A
291*lA22BA
292-lA121lB
293*1A211>S
29".1A22dS
295HA12AA
296-1A21AA
297*IA22AA
298_1A12UC
299*lA2111C
300*1A220C
301&1AIA28
302-1A2A18
303*lA2A2U
30"-lA182A
~1i1-1A2UIC
~1&1AA128
332*IAA21S
333*IAA226
33"-lA812A
335*1AB2lA
336*IA822A
337*1Atll2a
338_lA1l211l
339-1A622d
3"0*lAA12"
.."
···
··
3!>hlAB2A2
352.1ABIB2
J53*IA8261
3511*111821;12
355-1AAIA2
35b*lAA2Al
357.1AA2A2
358.1AIlIC2
3~9*lA82Cl
360*lAB2C2
361&IAABI2
362.1AA821
3&3*1"A822
30"*lA8A12
36::'*1A8A~1
·
·
·
~27_1A2AA2
328.1AII1C2
329*1A211'1
.530-1A28C2
311~*lAIl12C
3~IJ*1AB2AI
~O:':l*IA261A
315HA282C
.)16-lAU82
317_1A2AOl
.3H!elAZA8Z
319HA16A2
320*lA20Al
32hlA28A2
322*lAIBB2
323_1A2u81
32"-1A2tl82
325_lAIAA2
326.tA2AAl
,),,2*lAA22A
3"II_lAB21C
",,5*1IIB22C
3"6*lA11IB2
311 7*1 AA2!l 1
3"8.IAA2.!2
3"9*1ABIA2
~88*lA22AS
30b*lA2u2A
30 7& 1III02B
308-U281B
309*IA2U28
310*lAIA2A
Jl1=lA2A1A
312*IA2A211
313_1A1tl2'
~'+hlI1A2111
···
···
··..
·
1'11*12221A
7"6"12212A
7119_12122A
750-1122210
751$1111102
7!>2U112Al
7~3*U21Al
75"_1211Al
75!>.1222A2
756.1112A2
157U121A2
758-11UAl
7!)9H211A2
7bO-1212Al
7bh1221Al
7b'-1.!22Al
763-1~21A2
7611_1212A2
765*U21A2
7bb.111A12
7b7*UIA21
768*112A11
769-121A11
170.1221022
77hl11A22
772-112A12
773_112A21
77"-121AI2
775&121A21
770.122A11
777_122A21
778-122A12
779*12lA22
780*112A22
78hllA112
782*UA121
703*l1A211
78"-1210111
78~*12A.122
78b-llA122
787H1A212
788*11A221
789-121\112
790_12A121
791*12A211
792-1210221
793*12A212
79"_12Al"
795*UA2U
796HA1112
797_1A1121
798-1AI211
799&1102111
bOO_1A2l22
"OU1II1122
bD2_lA1212
b03HAl221
6011*1102112
366*lA8A22
367*IABd12
36a*I"8U21
369"'lABBU
370*lAAA12
~7hlUA21
372_1AAA22
.)73*IABCI2
37"_lA8C21
')75HAbC22
316,*A112AB
.J77-A121AB
.)7hA122AS
379*AI12811
.)80*A1216A
381·A122BA
382_AU2US
383·"12180
38".,.1226u
.)1I5*A112AA
38b-A121AA
387*A122AA
3811*All2.!C
J89eA121BC
390_A122dC
~9hAllA2tJ
392_A12A1U
.)93_A12A2S
39".A11U2A
395*A12E11A
3%*10 1202A
397*11111326
J98*A12BIU
···
~
·
·
·
··
·
···
···
··..
~99*Ala82B
"00*AllA2A
II0hA12A1II
"02*A12A2A
II03*Allb2C
II01l*A12BIC
II0~*A12b2C
"Ob*A11Ab2
.. 07"12AS1
II08.A12A82
.. g9*AllBA2
"10-A12SA1
U1*AI2SAl
"12*A11BB2
1113. . 12BBI
II111*,,12BB2
1I15. . 1lAA2
1016*A12AAI
il17*A12AA2
1118&,\118C2
U9*A12SCI
"20*A12BC2
112hAIA128
1122-AIA218 '
-,,23aA1A228
112II*AIBI2A
.. 25*MB2lA
"26*1. 1822A
1027""'18126
112&*AIB218
il29""18228
1130*"IA12A
/i31*AlA2lA
"32-AIA22A
/i33eA1B12C
"3"*AIB21C
!i35*A1822C
1136-AIAI82
,,37*A1A21:11
'I38*AIA282
1139*AIBIA2
""0_AIB2Al
""hAIB2A2
""2 ... 18162
"/i3*,,IB281
"""*,\182B2
" .. 5eAIA1A2
""6-AIA2Al
lL,,7_A1A2A2
",,8-AIBIC2
""9 ... 182Cl
..50*AI62C2
"51"'141112
1152*"lAU21
"!0.3_.U~22
"5"*AI8A12
"55*Al6A21
"56 ... 1BI.22
ilO~HA2121
800*IA2211
807*lA2221
1I08_1A2212
609-1A2122
810*IA1222
811&Al1112
&12*,,11121
813*"11211
11111-1012111
1I1!)*Al2222
1116*"11122
il17*A11212
b18-A1l221
1!19-A12U2
820_A12121
1!21*A12211
822 ... 12221
1!2"eA12212
8211-A12122
825_A11222
112b-111112
<127-111121
826-111211
f:l29d12111
830-121111
831·12U22
a32-111122
833*111212
8311_111221
1135-112112
836_112121
11.)7*112211
638*121112
1139.121121
b"00121211
6"I*1l2111
a"2*122221
tI,,3*122 0 &
"-J
IOBOUND
(2)
where
TIMELEFT-is the time left in the current quantum
and
~,
IOBOUND -is a status word in the PSA that
indicates whether the user is
awaiting the completion of an I/O
operation.
To Page Access Word
Figure 6-PAGETABLE and PAGETIME
When a page of memory is needed for swapping purposes, a search is performed on PAGETABLE to find
the page with the smallest value. Value is infinite if the
system bit is set or zero if the occupied bit is not set.
In all other cases, a function is evaluated which is the
sum of
PAGETIl\1E - clock
+ Value (I)
(1)
where
If no PSA satisfies condition 2, the RPSAPTR advances until a PSA that is not IOBOUND is found and
sets that program to run another quantum.
It is clear that a user who requires extensive swapping
will contribute significantly to the flow of page traffic
Virtual Memory Map
page access
non-reentrant
o
I
clock
is a set of status bits from P AGETABLE
is the current reading of the real time
clock
page
1
and
Value
is given by a function that maps bit configurations into time values.
PAGETIME is set to clock + 1 hour whenever a page
is referenced and is shifted right one position every
hour to prevent overflow. The values in PAGETIME
do not age linearly because of this shift; however, the
function is continuous and is not inaccurate in the
region where the clock is set back one hour and PAGETIME entries shifted.
A user's reference to his virtual memory occurs upon
detection of an illegal write interrupt, and the system is
then table driven based upon the above tables and the
virtual memory map (Vl\1M) in the user's PSA. Each
word in the VMM is either a page access word or a
reentrant
page access word
I
page
B'iu:ure 7-Page access word
08-3
to and from the disk. IVloreover, such a user will receive poor service if the page traffic flow is heavy .
In order to cope with this situation, a more sophisticated scheduling arrangement is required. This kind of
extension to the scheduling algorithm should be adaptive in nature, that is the system should recognize the
existence of a problem situation and proceed to 'tune
itself up.' Further, detection of the problem condition
as well as modification of the scheduling tactics must be
easily computable if an undesirable increase in system
overhead is to be avoided.
At present, 08-3 includes an initial version of a demand scheduling strategy called the debogging algorithm. This algorithm governs the allocation of processor memory so as to minimize page traffic flow in the
presence of varying user requests.
Conceptually, the algorithm can be viewed as a high
priority pointer that is cycled around the user queue
independent of the RPSAPTR. If a user is designated
the high priority user, then his in-core pages increase in
value, and he is automatically placed second in line in
the swapping queue for requested pages.
In effect, the debogging strategy tends to delay users
whose page requests are heavy with respect to current
page traffic flow, and then run such users with greater
priority for a period of time during which they can
occupy a substantial amount of core.
In particular, the algorithm governs the behavior of
the following independent categories of events:
1. Advancing the high priority pointer
2. Delaying troublemakers, and
3. Rehabilitating former troublemakers.
These categories are now described in greater detail.
The high priority pointer, HPP, is advanced to the
next user whenever one of the following conditions is
satisfled:
K 1 influences the rate at which the HPP will shift to
the next user if the current user is busy swapping. K2
is simply a constant that governs the cycle rate of the
HPP.
If any of the conditions 3, 4, or 5 is satisfied, then
WCT: = SQ: = QCT: = 0
PRj: = 0
(i = 1, ... ,n)
(6)
(7)
wher~
SQ
-is the avera,ge length of the swapping
queue
QCT
-is the number of useful quantums of computing (i.e., time not spent in the idle
loop).
and
The second category concerns the troublemaker. A
user is a troublemaker if only the mass storage wait bit
of'his IOBOUND word is set, and if
.. (8)
where
K3
-is a constant that determines the nunlber of swap requests a user must generate
in order to qualify as a troublemaker.
The last troublemaker is defined as the troublemaker
that is located the greatest distance from the HPP in
the direction of pointer rotation. A troublemaker is
delayed by setting the delay bit in the IOBOUND
word of his PSA. The last troublemaker will, in fact,
be delayed if:
(SQ ~ K4) & (SQ ~ K5)
The user logs off
247
(9)
(3)
where
The user becomes I/O bound
(4)
SQ
-is a counter that contains the current
length of the swapping queue
SQ
-the average length of the swapping queue
K4
-is a stabilizing factor
K5
-determines heavy page traffic flow.
(5)
where
WCT -is the amount of wall clock time that has
elapsed since the HPP was advanced
PRj
-is the page request word in the ith user's
PSA. PRj is incremented by one each
time the ith user requests a page
and
If condition (9) is satisfied then
a.nd
K1, K2-are constants.
SQ: = SQ: = QCT: = 0
(10)
Spring Joint Computer Conference, 1969
248
The final category _provides' for the rehabilitation of
former troublemakers. A former troublemaker is a user
whose delay bit is set. The closest former troublemaker
is defined to be the former troublemaker locat~d the
least distance from the HPP in the direction of pointer
rotation. The closest former troublemaker may be rehabilitated by clearing his delay bit. This will occur when
(QCT ~ K6) & (SQ
< K7)
(11)
where
K6
-is a stabilizing factor
and
-determines relatively light page traffic
flow.
The effect of the preceding debogging strategy is to
match available processor memory· to user demands.
If this cannot be done, then an obvious troublemaker
is delayed, and, after a period of stabilization, the situation is sampled again to determine whether an acceptable match has occurred. If not, then another troublemaker is delayed, and so forth, until a match is
achieved. Conversely, jf user demands are not overloading the swapping queue, then former troublemakers are rehabilitated, one at a time. Of course, if
several users require large quantities of physical memory, the recidivism rate will be high.
System performance
System performance measured in terms of system
overhead tends to be quite good. If the total number of
user hours for a month is compared to the total amount
of billable CPU time for that period, it turns out that
the system spends slightly more than 65 percent ti..me in
an idle loop. Of course, this might indicate that the system is heavily I/O bound; however, test measurements
indicate that this is not the case.
In another test, switching time was measured by
loading the system with a sample job mix. Jobs were
chosen from three categories:
1. Compute bound
2. 65K swap bound
3. I/Obound
The 100 millisecond quantum was then reduced until no
useful computing took phwe. This break-even point
occurred at four milliseconds.
ACKNOWLEDGMENTS
The authors are indebted to Steven K. Sullivan for his
incisive comments, useful criticisms, and system programming support.
REFERENCES
1 J DAVIS
A brief description of OSCAR (Second Revision)
asu Computer Center cc-68-45
2 J MEEKER
RADAR
OSU Computer Center cc~8-30
3 F DAYTON W MASSIE
OS-3 teletypewriter editor manual (Revised)
OSU Computer Center cc~8-17
Virtual memory management in a
pagil1.-g environment
by NORMAN WEIZER and G. OPPENHEIMER
Radio Corporation of America
Camden, ~ew Jersey
INTRODUCTION
The Spectra 70/46 Time Sharing Operating System
(TSOS) is designed to be a combined time-sharing
and multiprogramming system that will support up
to 48 conversational users or a combined total of 64
batch and interactive tasks processing simultaneously.
. The memory management subsystems of TSOS
maintain complete control of main core memory, the
drum backing store and the virtual memory facilities
of the entire system. The virtual memory management
subsystem controls the allocation and release of the
backing store space, the organization of the 2 million
byte virtual memory and the characteristics (the control-bit settings) of the allocated virtual memory space.
Hardware description
A short description of the relevant spectra 70/46
Processor! features is presented here to provide a background for the discussion of the virtual memory management subsystem. The 70/46 is basically identical
to the spectra 70/ 45 ~1od II Processor2 with the addition of a flip-flop implemented hardware translation
memory. The dynamic translation facilities of the
70/46 are provided by this translation memory and
the special functions implemented in the read only
memory.
The translation memory (TM) contains 512 half
word elements each of which represents a single virtual
page. The page size used within TSOS is 4096 bytes,
and thus the virtual memory is a linear space3 of two
million bytes.
Each half word element in the translation memory
is composed of a set of control bits and a physical
page number, shown in detail in the Appendix. The
control bits indicate whether the page has been modified, whether it has been accessed, whether it may
be modified, whether access is restricted to privileged
users and whether the page is in memory. If a referenced page is in memory the physical page number
is used in conjunction with the 12-bit displacement
field of the virtual address to determine the physical
address. If the page is not in memory the hardware
generates a paging queue interrupt, and the software,
utilizing a hardware special analysis function, determines the page (s) required and causes the page (s)
to be brought into main memory.
The 24 bit virtual address format is shown in Figure 1. It represents the address formulated after all
address arithmetic has been performed.
The Page and Displacement portions of the virtual
address constitute the 18-bit address field and are
generated by the 18-bit address arithmetic. If the sum
of the least significant 18 bits of the base register,
an index register, and a displacement field of an instruction would normally cause a carry into the 19th
bit of the address field, this carry is lost and an address
wrap around to the lower boundary of a segment takes
place, thus providing a modified form of segmentation.
The segment, unused, and D bit fields of an address
can be changed in the base registers by using the normal
binary addition capabilities of the processor. TheD bit is used to obtain direct (untranslated) addressing
capability while in the 70/46 or translation addressing
mode. * Only privileged Control system functions
can use this facility.
.
The nine bit field formed by the segment and page
bits of the virtual address forms the index which is
used to determine which of the 512 translation memory
elements corresponds to the addressed virtual page.
* The Spectra 70/46 is also capable of being run in a 70/45 mode.
In the 70/45 mode no address translation takes place and the
address space is limited to 262K bytes.
249
250
1 bit
D
Spring Joint Computer Conference, 1969
2 bits
3 bits
6 bits
IUnused ISegment I PAGE
12 bits
Displacement
Figure I-Virtual address format
The six page bits contained within the indexed Tl\1
entry (see Appendix) are concatenated with the 12
low order bits of the virtual address to form the 18
bit physical address actually used by the processor
to address memory.
Two memory protection capabilities are provided
in the 70/46. The first capability is provided by a set
of protection key locations associated with main core
memory. These keys are only used in the 70/45 mode
of processing, although they are also operational in
the 70/46 mode. The second capability is provided
by the translation memory implementation and is
only available when in the 70/46 mode. A nonprivileged
routine in the 70/46 addressing mode, or a privileged
function not using the direct (untranslated) addressing
capability, cannot address information unless a translation memory element for that task allows translation
to that memory location. In this way, unless the entries
for two users are simultaneously loaded into translation
memory, no user can access the private information
of another user. Also, the control bits of the translation
memory entries prevent nonprivileged access to unauthorized information and also prevent modification
of code which is executable only.
The backing store for the 70/46 is a fixed head drum
of either 800 or 1600 tracks. The track capacity of
the drum is approximately 5000 bytes. By assigning
a single 4096 byte page per track, the 3600 RPM drum
can accommodate 60 page transfers per second. The
time to transfer a page between core and drum is approximately 13.65 msecs, thus leaving about 3 msecsfree time between the end of one page transfer and
the beginning of the next. This free time (gap time)
is an upper bound on the amount of processing that
may be performed between page transfers if the full
drum transfer rate capability is to be realized.
All of the I/O operations, including the paging transfers, use untranslated or direct addresses. This requires
that the virtual to physical address conversioilmust
be made before an I/O is initiated. Also, any pages
involved in an I/O operation, including those which
contain the I/O control information, must remain in
core during the duration of the I/O operation.
Paging algorithm
..A...
demand type paging algorith..1U3 is implemented
in TSOS.4 This algorithm limits the number of tasks
simultaneously competing for the processor and main
memory by using a "working set"5 like concept in
the scheduling of tasks.
When a task in made "active" (i.e., is allowed to
compete for processor time and main memory) the
counter of available main memory pages is decremented
to set aside the number of pages it is anticipated the
task will require. This number is equal to the number
of pages used by the task during its previous activation
period.
Rather than fully swapping a program's working
set into memory or allocating specific memory pages
for the task at activation time, however, only those
pages required by the task's first instruction are actually pre-paged into core. During a task's active
period, its pages in core are normally considered nonpageable. * When a task is deactivated, the counter
of available main memory pages is incremented, and all
of the task's pages in core are placed on the page-out
queues.
When a task is blocked by a paging queue interrupt,
pages are chosen from the page-out queues and the
appropriate drum transfers are initiated. During the
period in which the required pages are being brought
into core, other active tasks are placed in control of
the processor.
Memory management design considerations
In general a memory management subsystem for
a multi-access system should have the following char.acteristics :
1. Protection-no user should be able to destroy
2.
3.
4.
5.
6.
the data beionging to another user or to the
system as a whole;
Privacy-without authorization, no user should
be able to access the data belonging to another
user or the private system data;
Shared Code Use-several users should be
able to simultaneously use the same physical
copy of commonly used routines or programs;
Flexibility-the full memory management capabilities provided by the hardware, consistent
with the protection and privacy considerations,
should be made available to the user programs;
Ease of Usage-the memory management facilities should be provided to the user in a manner which allows them to be easily used;
Low Overhead-the use of the memory man-
* An exception to this rule occurs if a single task requires more
pageable main memory space than is available in the system.
Virtual Memory Management in Paging Environment
agement facilities should add as little overhead
to the system as possible, consistent with the
other characteristics;
7. Integrity of Design-the memory management
subsystem should not be designed as a unit
separated from the remainder of the operating
system. It must be designed as an integral
part of the overall system but with clearly
defined boundaries and interfaces. The clearly
defined boundaries and interfaces prevent a
great many problems in the implementation
and debugging phases of operating system
development. (The method used to develop
the scheduling and paging algorithms for TSOS
is described in Reference 4.)
8. Modularity-the memory management· subsystem should be designed as a set of modular
routines. There should be simple and sharply
defined interfaces between the various routines
to simplify implementations and debugging
problems.
In the following sections a description of the TSOS
Virtual Memory Management Subsystem is provided
and an attempt is made to show how all of the above
criteria were met within the hardware environment
described above.
Virtual memory organizatian
The two million bytes of virtual memory are divided
into two equal units. Each user of the system is permitted to use the first one million bytes for code and
data areas related strictly to his own task. The second
one million bytes are reserved for Control System
functions and shared code.
In terms of the use of the translation memory this
means that the first 2.56 entries are used for private
user task information. Each time a nmv task gains
control of the processor the previous task's translation
memory entries are stored in main memory, and the
new task's entries are loaded into the translation memory. During this entire process the upper 256 entries
in the translation memory are unchanged.
This organization of the virtual memory, aside
from reducing the overhead entailed by the loading
and unloading of the translation memory, permits
the Control System to be written using virtual addressing and at the same time to have full access to
all user areas. Since the task in control of the processor
has its entries loaded into the translation memory
while it is running, the task's memory is directly
available to the Control System through the translation
mechanism. (The converse is not true, in that the
251
Control Program pages are privileged and the pages
containing shared code are executable only, preventing
user code from accessing Control Program information
and from modifying shared code.)
If the virtual memory were not divided as it has
been, and the full two million bytes had been made
available to each user, the Control System would have
had to use direct addressing to a much greater degree
and would ht:we required much more code to be resident,
or the loading and unloading of the translation memory
would have been appreciably greater.
Backing store allocatian
Although each user task has a private one million
byte virtual memory, the memory is not actually
usable until it is dynamically allocated by means
of the memory management macros; that is, until
a realtionship is set up between a page of virtual memory and a page of backing store. In a conventional
processor this is analogous to saying that the address
space (which is normally equal to the physical memory
size), is not usable until the program is loaded into
memory. And then only the assigned portion of the
total address space (memory) may be referenced.
Within TSOS user pages are allocated when a program is loaded and when additional space is dynamically requested. When a page is allocated, a translation
memory entry is initialized for it and a drum track
is assigned. This track is associated with the page
on a permanent basis, i.e., until the page is released
and the translation memory entry is no longer valid.
The relationship between the backing store track
and the page of virtual memory is maintained even
while the page is in main memory for the following
reasons. The number of pages of main memory is small
compared to the number of pages on the backing store.
Therefore, the marginal gain in drum tracks available
to the system through the use of a dynamic assignment
system would be small. General utilization of the drum
tracks in this manner would also increase the probability of binding the system intolerably should the
drum become saturated.
From another viewpoint, the fact that there is only
a single page per track means that schemes which
reassign drum tracks to core pages that must be written out, so as to optimize drum utilization in a multiple
page per track environment, are not applicable in
the environment of TSOS.
In summary, until a virtual page is requested and
backing store assigned to it, the virtual memory space
it represents is not usable. Any attempt to access an
unallocated page is detected by a combination of hard-
252
Spring Joint Computer Conference, 1969
ware and software and is treated as a program addressing error.
Virtual memory classification
To regulate the use of virtual memory, and to simplify its request, particularly within the Control System,
virtual memory is divided into six somewhat arbitrary classes. The address assignments for the six
classes are shown in Figure 2. The characteristics
of each class are described below.
Class 1 Virtual M emory is occupied by the resident portion (kernel) of the Control System.
All Class 1 pages are privileged and nonpageable.
There are no drum images of these pages. At
present there are 10 Class 1 pages in TSOS.
Class 2 Virtual Memory is occupied by the non-
resident portion of the Control System. All Class
2 pages are privileged and pageable and may
be marked as executable only, depending upon
the nature of the routines occupying them. There
is a drum image for each of these pages.
Classes 1 and 2 virtual memory are preallocated
at system generation. The boundary between these
two classes (CILIM) may be varied from system to
system. dependent upon installation requirements.
Class 3 Virtual M emory is occupied by the dynamically acquired resident portion of the Control
System. All Class 3 pages are privileged and nonpageable. There are no drum images of these
pages. This memory class is used for task control
blocks, terminal I/O buffers and certain system
work space. It is also dynamically released when
the requirement for resident space iessens.
Page
Number
0
Each
User's
Class 6 Virtual Memory
C6 LiM
~
Class 5 Virtual Memory
256
C1 LIM
Virtual
Memory
Class 1 Virtual Memory
Class 2 Virtual Memory
~
C2 LIM
Class 3 & 4 Virtual Memory
511
Figure 2-Virtual address space assignments of
virtual memory classes
System
Virtual
Memory
Class 4- Virtual Memory is occupied by the non-
resident work space dynamically acquired by the
Control Program and by the shared code called
by the users of the system. All Class 4 pages are
pageable and have drum images. The Class 4
pages used by the Control System are marked
privileged, but those used for shared oode are
marked nonprivileged.
Virtual memory Classes 1 through 4 constitute the
system virtual memory. As a group these four classes
must be contained within the one-million bytes of
address space available to the system. They reside
in the upper one-half of the translation memory and
are not changed (swapped) in the translation memory
as control is passed from user to Uh'er.
Virtual memory Classes 5 and 6 constitute the user's
virtual memory. Together these two classes are limited
to the one million bytes available to the user. They
occupy the lower one-half or the translation memory
and as control is passed from user to user the Class
5 and Class 6 translation memory entries for each
user are swapped out of and into the translation memory. This means that any data stored in a user's Classes
5 and 6 Virtual Memory cannot be accessed using
virtual addresses when that user's entries are not
loaded into TlVI. (This, in turn, means that the system
must use direct, non-translated, addressing to access
user memory for a user that is not in control of the
processor.)
Cla"ss 5 Virtual Memory is occupied by dynamically allocated pageable areas acquired for the
specific user by the Control System. These pages
may he marked privileged or nonprivileged. They
are used for task dependent information such as
task dependent virtual memory tables, protected
file control blocks, program loader data, data
maintained by the interactive debugging language
and I/O buffers acquired for the task by the system.
Class 6 Virtual Memory is occupied by dynamically allocated pages acquired by the user for
his code and work areas. The pages of Class 6
memory are under control of the user task.
The boundary between Class 5 and 6 memory
(C6LINI) is completely variable and depends upon
the requirements of each individual task. Normally
Class 5 memory occupies the 16 pages fronl page 240
through 255, and Class 6 memory occupies the 240
pages from page 0 through 239. Each memory clas~
is allocated contiguously such that a page of Class 5
Virtual Memory Management in Paging Environment
memory is never bounded on both sides by pages of
Class 6 memory or vice-versa.
Shared code
N onprivileged 'shared code offers the potential advantages of savings of main memory and backing
store space plus a reduction in the paging rate. However, additional memory management control logic
is required to realize these advantages. In systems
with true segmentation, the segment is nomlally the
unit which is shared and shared code may be used by
attaching the called segment to the virtual memory
of the calling task. This degree of generality in a system with a linear address space requires more control
logic than the potential advantages warrant.
With a linear address space it seems preferable
to allocate some of the address space for shared code
and to take this space out of the system's area of virtual
memory. This procedure eliminates the need for any
overhead producing special actions when a task using
shared code gains or loses control of the processor.
I t also permits the same algorithm to be used for paging the Control System and the shared code, simplifying the design and implementation of the paging
subsystem and thus reducing system overhead.
The major disadvantage of this approach is that
the (virtual memory) space for the shared code must
be allocated for every user, whether or not he uses the
shared code. However, it is felt that the low overhead,
ease and flexibility of use, and ease of implementation
more than make up for the loss of some address space.
In TSOS the system administrator determines for
his specific installation what major routines will be
considered eligible for sharing and makes this determination known to the system by means of a special command. He may choose only RCA supplied software
such as the File Editor, and the Interactive Fortran
compiler; or some user designed programs; or any
combination of the two. Upon the first call for one of
these shared routines the loader allocates the amount
of memory needed to load this routine. This memory
is allocated as nonprivileged, execute only, Class 4
virtual memory. Upon succeeding calls for the same
routine, the loader establishes links between the shared
routine and the calling task without the need for reloading the shared program in any form.
During execution each user of the shared routine
uses the same physical (and virtual) copy of the routine
as all other users.
Macro caUs
The acquisition and release of virtual memory and
253
the control of the characteristics of allocated virtual
memory are the major services perfomled for users and
other Control System functions by the virtual memory
management subsystem. These services are requested
by means of macros which generate standardized
linkages and parameter lists. These linkages may be
either Supervisor Call instructions (SVCs) or standardized branching conventions, both of which provide
clean interfaces, an invaluable aid in the debugging
phases of complex system development.
The macros are named REQM (request memory),
RELM (release memory), and CSTAT (change memory status). There are two forms of each macro, one
which may be used by nonprivileged and privileged
(Control System) routines, and the second which is
restricted to privileged routines only.
The nonprivileged forms of the REQM and RELM
macros permit the user to request and release Class
6 memory in multiples of one page, with a maximum
of 64 pages per call. If the address spaces and backing
store space is available, the requested memory will
be allocated in the first unallocated area (lowest
available area in the address space) large enough to satisfy the request; or if the user so ~pecifies, the memory
will be allocated starting at a specific address.
The nonprivileged form of the CSTAT macro allows
the user to change the status of any page in Class 6
memory to read-only or read-write. The CSTAT macro
also provides the mechanism for users to request that
specific Class 6 pages be made pageable or nonpageable. *
The privileged fonus of the virtual memory macros
allow Control System routines to operate on any page
in Classes 2, 3, 4, 5 and 6 virtual memory. The option
of the CSTAT macro which changes a page's status
to read-only or read-write is available for all memory
classes. The option to make pages pageable or nonpageable is available only for memory Classes 2, 4, 5
and 6. This option of the CSTAT macro is the most
heavily used as it permits the Control System to lock
into (unlock from) main memory pages which are
(were) required to be resident for I/O operations. **
The privileged forms of the REQ:NI and RELM
macros permit Control System functions to request
and release Classes 3, 4 and 5 virtual memory. Classes
* Provision exists within the system, in certain well defined
situations to permit users to use this option of the CSTAT
macro. The limit of the number of pages that a user may make
nonpageable is established based upon system-wide parameters
and conditions set at task initiation.
** All
I/O is done with nontranslated addressing and thus commands must contain physical addresses and buffers must not be
moved until the I/O operations complete.
254
Spring Joint Computer Conference, 1969
1 and :2 virtual memory are structured at system generation. In addition to the full page allocation capability
of the nonprivileged version of the macros, partial
page allocation is provided in the privileged versions.
Partial page allocation
Many Control System functions require different
sized areas of memory during their execution. This
memory may be required specifically for a single task
or it may contain system wide information. Memory
space which need not always be resident and which
is required for a single task is acquired as Class 5 memory; system wide information which is pageable is
stored in Class 4 memory and user dependent or
system dependent infonnation which is nonpageable
is stored in Class 3 memory.
To conserve address space, better utilize main memory and reduce the paging rate for Control System
pages, Classes 3, 4 and 5 memory are allocatable in
partial page units. The units of allocation are 8n bytes
where 2 ::; n ::; 509.
Any request for larger size areas are al10cated in
full page increments. Any size area may be requested,
but during the allocation process the size allocated is
rounded up to the next larger standard size. This standardization, making all allocations multiples of a single
quantum size, eases both the allocation and garbage
collection processes employed.
Each page allocated is treated as a separate unit
so that no partial page allocation crosses a page boundary. This serves two purposes. First it eases the record keeping involved by limiting the number of areas
considered in a single operation. Second it prevents
dynamically acquired I/O buffers from being allocated
across page boundaries.
The latter is significant in that otherwise it would
be necessary to page contiguous virtual pages into
contiguous main memory pages, and this wou1d vastly
complicate the paging and physical memory management subsystems.
To manage the partial page allocation two linked
lists are maintained in each subdivided page. One list,
termed the main list, links all of the areas on the page
in address order. The second list, termed the free list,
links all of the unallocated areas in area size order,
with the smallest area at the head of the Jist. The links
of both lists are eight bytes long. The entries in the
links include a free bit, which is used to indicate unallocated areas, a size field, forward and backward link
fields and a two byte integrity field used by software
to, check that the link was not destroyed by some other
software routine.
In addition to the faemory links, partial page tables
are also maintained by the system to manage partial
page allocation. Two of the tables are maintained in
Class 3 memory to control the Class 3 and Class 4
faemory partial page allocations. There is also a corresponding partial page table in each user's Class 5
memory which is used to control the Class 5 partial
page allocations for that user. The entries in each table
are identical. They consist of the virtual page number
of the page to which they correspond and the size
of the largest free area on the page. There is one entry
for each page which is subdivided for partial page allocation.
The placement of the memory links on the same
page as the partial page areas presents the possibility
of malfunctioning system components destroying
the links. However, rather than proving to be a. hindrance, this link placement proved to be a great aid
in system debugging. This is due to the fact that the
memory management routines will often be the first
system function to find the destroyed link. This, in
turn, helps to avoid the problem that some other system function will malfunction, because it uses an adjacent area which was also destroyed, allowing many
bugs of the type which would only occur at widely
scattered intervals to be more easily tracked down.
.l'Jerr.my management tables
A relatively complex table structure is required to
support the memory management functions of T30S.
These tables support the physical memory management
and paging subsystems along with the virtual memory
management subsystem. They are used primarily to
maintain allocation status infonnation for the major
memory resources-the core pages, the drum pages,
the system virtual address space and user virtual address space.
The allocation status information for drum pages
and for system virtual memory pages is maintained
in bit-per-page maps cal1ed the Paging Drum Memory
Map and the System Virtual Memory Map. These
tables are used when the request memory (REQM)
macro code must find an unallocated drwn page during
the allocation of a page of pageable virtual memory
and when it is necessary to detennine the address- of
free pages during the allocation of system virtual memory. These tables are also used during the corresponding
RELM (release memory) processing.
The core status data are maintained in two tables
cal1ed the Physical Memory Map and the Physical
Page Allocation Table. Each entry of the Physical
Memory Map indicates whether the page is free or
aJIocated, the memory class data for nonpageable
pages and certain reservation inforrnation. The Ph)~-
Virtual Memory Management in Paging Environment
ical Page Allocation Table contains the drum address
(for pageable pages), the I/O count (the number of
I/O operations in process or scheduled into this virtual
page), link space for the page out queues, and the
address of the Virtual Page Toole entry for pageable
pages.
The System Virtual Page Table is a two part table.
The main portion contains the core image of the entries
loaded into the translation memory for the system
virtual m~mory. However, when the pages represented
by these entries are not in core, the cylinder portion
of the backing store address is maintained in these
entries. The secondary part of the table is used to store
the drum track portion of the backing store address.
The above described tables are maintained in Class
1 virtual memory. They are system wide tables. In
addition, there are four private tables maintained for
each user. They are the Block Address Table and the
associated User Virtual Page Table which are maintained in Class 3 Virtual Memory, and the User Virtual Memory Map and the Class 5 Partial Page Table.
The Block Address Table entries for each user are
maintained within the Task Control Block (TCB).
The TCB contains the master infonnation about each
task in the system. The Block Address Table entries
of a task are used within a special function to cause
the User Virtual P .1ge Table entries to be loaded into
the translation mealory when the task is to be given
control of the processor, and conversely when these
entires are to ce stored in core when control of the
processor is removed from the task. The space used to
store these entries is maintained in System Virtual
Memory to guarantee their accessibility by the Control
System at any time. Otherwise, they would be accessible only when the user was in control of the processor.
The User Virtual }Iemory J\lap parallels the System
Virtual Memory Map and is allocated in the user's
Class;) memory. The Class 5 partial page table is also
allocated in the user's Class 5 memory. It is used to
('ontrol the partial page allocation of the user's Class 5
memory.
SU1IMARY
The salient h'l.rdware features of the system described
are: a linear a::ldress space of 512 pages of 4096 bytes
each; a main memory of 64 pages; a single level page
per track backing store of 800 or 1600 pages; and the
use of a 512 entry translation memory to effect the
virtual memory of the system.
The facilities controlled by the virtual memory
management subsystem described include the organization of the virtual memory, the subdivision of the
virtual memory into classes, the management of the
255
shared code within the system, and the allocation of
backing store and of partial pages.
Within the context of the hardware structure, the
major aspects and advantages of the described software
system are summarized below.
The partitioning of the virtual memory to concurrently accommodate the system and a single user reduces
translation memory swapping overhead and provides
the system code with full accessibility to all user code,
while still pennitting the system code to be written
using virtual addresses.
The division of the virtual memory into classes
structures the use of the virtual memory, regulates
its use and simplifies the request and release procedures,
especially within the Control System.
The incorporation of sharable code wit~ in-,he system
virtual memory affords its direct accesblbllity to all
users, pennits a single page table to be maintained
for the code, and allows the same paging algorithm to
be applied to shared code as is used for system code;
but it requires all users to give up the same amount
of virtual memory for the shared code, whether or not
they use the shared code.
The allocation of backing store only when a page
of pageable virtual memory is allocated enables more
users to be run concurrently with a given level of backing store than if the backing store was allocated for
the entire user virtual memory, regardless of the user's
ntent to utilize his entire virtual memory.
The maintenance of a relationship between a virtual
memory page and a track on the backing store, even
when the page is in memory, is justified based upon
the real probability that the page may not be modified
and therefore will not have to be written out-if the
backing store association is maintained while it is in
memory; and the added consideration that the ratio
of drum tracks to memory tracks is such that the marginal gain in drum tracks available to the system from
reassigning pages in memory is extremely small. The
drum characteristic of a single page per track is also
a factor in this regard.
The provision for partial page allocation for other
Control System functions, while it increases the calls
on the virtual memory subsystem, provides for better
utilization of memory and easier development of reentrant code.
REFERENCES
RCA Spectra 70/46 Processor Reference Manual
2--RCA Spectra 70/35 45 55 Processor Reference Manual
3 B RANDELL C J KUEHNER
Dynamic storage allocation systems
256
Spring Joint Computer Conference, 1969
CAe M Vol 11 No 5 May 1968297-306
4 G OPPENHEIMER N WEIZER
Resource management for a medium scale time sharing
operating system
CAe M Vol 11 No 5 May 1968313-322
5 P J DENNING
The working set model for program behavior
CAe M Vol 11 No 5 May 1968323-333
APPENDIX
The translation memory
The Translation ~1emory is 512 half-words in size.
Each entry in Translation Memory has the format
shown in Figure 3.
The meaning of each of the control bits and the
physical page number in the translation memory entry
is given below:
P = Parity bit (invisible to the software).
vV = vVritten Into Bit: indicates when set, that the
page addressed in memory by this translation
halfword has been written into. This bit is
automatically set by hardware and reset by
software.
G = Accessed Bit: indicates, when set, that the
page addressed in memory by this translation
halfword has been accessed (read, or written
into). This bit is automatically set and reset
by hardware. Attempted but unsuccessful
access to a page does not set this bit.
1 bit
~I
1 bit 1 bit 1 bit 1 bit 1 bit 1 bit 3 bits
WiG
6 bits
1 bit
I I I ElM I::.1~~I~bsERI H I
u
s
Figure 3-Format of a translation memory entry
U = Utilization Bit: indicates, when set, that the
addressed translation word can be utilized.
This bit indicates, when reset, that the addressed translation word cannot be utilized
(i.e., this virtual page is not in core) and a
Paging Queue Program Interrupt occurs. This
bit is set and reset by sottware.
S = State Bit: Indicates when set, that the addressed translation word is nonprivileged.
When this bit is reset, it indicates that the address page is privileged and can only be accessed by a program operating in the pri'vileged
mode (i.e., a portion of the system software).
When this bit is reset and a nonprivileged
program attempts to access this page, a
Paging Elror Program Interrupt occurs. This
bit is set and reset by software.
E = Executable Bit: indicates when set, that the
page addrest3ed in memory by this translation
word can be read as an operand or instruction
but cannot be written into. When this bit is
reset, all forms of access are allowed for this
page. If a program attempts to write into a
page with this bit set in the translation word,
a Paging Error Interrupt occurs. This bit is
set and reset by software.
M and H bits are used when the 2048 byte virtual
page mode is used. Under TSOS only the 4096 byte
virtual page mode is used.
Physical Page Number: when the U bit is set, these
six bits contain the six most significant bits of the actual
physical address of the page represented by this T.M.
entry. The full physical address is obtained by concatenating these six bits with the low order 12 bits of the
virtual address. \Vhen the U bit is reset no meaningful
information is contained in this field.
An operational analysis of a
remote console system
by HERBERT D. SCHWETMAN
and JAMES R. DELINE
The University of Texas
Austin, Texas
INTRODUCTION
The Computation Center of The University of Texas
at Austin provides remote console access to a CDC
6600 computer through a system called RESPOND.!
RESPOND was written by Control Data Corporation
and has been in operation at The University for more
than two years.
The paper gives a brief description of RESPOND and
the capabilities provided the user. This is followed by
a critical evaluation of the performance and reliability
of the RESPOND system based upon experience
gained in its use. A survey of user reactions is presented
next. Finally, the cost of providing this remote batch
entry service is estimated in terms of percent of system
resources used and system maintenance required.
A description oj RESPOND
The RESPOND system was installed on the CDC
6600 at the Computation Center on ~larch 10, 1967 ,
by the Special Systems Division, Control Data Corporation. This was the second implementation of RESPOND on a 6000 series computer, * and the first under
the SCOPE 2.0 operating system. This version later
became the framework for Control Data's standard
6000 series system-TTY RESPOND.2
A RESPOND terminal is typically a Model 33 or
35 Teletype, with or without punched paper tape
capability. From this terminal a user may log into the
system by providing his password and the account
number to which his computing activities will be
charged. He may then enter data into the system via
the keyboard or paper tape and may create a file by
• The first implementation was at Rechenzentrum der TechHochschule Aachen, Aachen, Germany, on a CDC 6400
m January 1967.
~chen
giving this text a name. Such files then become a
member of the user's private file catalog. Files may
also be introduced into RESPOND from other sources.
Card decks and magnetic tape records can be copied
into files in the user's file catalog.
RESPOND appends a sequence number to each
incoming line of text and, by referring to these numbers,
the user is provided with a limited text-editing capability. A line or group of contiguous lines of text may be
displayed at the terminal by referring to the name of
the file and specifying the desired lines. New lines may
be-inserted in~o the body of the file at any point, and
undesired lines may be deleted by reference to their
sequence number. Two or more files may be merged,
with the new file given a name different from the others.
At the user's option, these files may be copied to
punched cards or printed output at the 6600 site, may
be submitted as programs and data to be run by the
6600, or may be saved by the RESPOND system for
use at a later time. Files which are no longer wanted
may be deleted by the user from his file catalog; those
files which remain are periodically dumped to rmgnetic
tape. In addition to holding all user files, this tape
holds public files, which are accessible as read -only
files by all users, and a list of passwords for all authorized users. This tape is copied to disk storage each
morning when RESPOND is placed "on the air" and
is used to restore the system when RESPOND experiences an unrecoverable failure.
RESPOND files of program source text may be
submitted for compilation and execution. In this
environment, a RESPOND job consists of one or more
RESPOND files, the first of which is a SCOPE control
card file. The contents of this file are identical to the
control card record which would be used if the program
were to be run in the normal (over-the-counter) batch
257--------------------------------------
258
Spring Joint Computer Conference, 1969
environment of the 6600. Thus, the same compilers,
assemblers, utility and object-time subroutines, deck
structures, and error messages provided in the normal
batch mode are available to the RESPOND user. As
will be pointed out in a later section, there are some
advantages and disadvantages to this feature.
Once a set of files have been sub;mitted for execution,
they are locked from further user access until the job
has been run. The user is not able to interact with his
program once it is placed into execution, but he is
permitted to create, peruse, and submit for execution
other files in his file catalog.
After the program has been run, RESPOND wiii
collect those files specified by the user which were
created as a result of a program execution. Typical of
these files is the standard output file which or'dinarily
will contain listable output from a compiler and, in the
case of a subsequent load-and-go, the results produced
by the compiled program. These files are converted into
RESPOND format and are placed in the user's file
catalog. Other special-purpose files may be left with the
operating system for on-site disposal, such as plot and
microfilm files, or magnetic tapes created during
program execution. A user/computer-operator message
facility is available to permit close cooperation on
magnetic tape requirements, log-out times, etc.
The commands of RESPOXD can be divided into
five groups. The frequency distribution of the usage of
these commands is given in Table I. It is interesting to
note that use of commands in the EDIT group far
outweighs command usage in the other groups.
Table I-Command frequency distribution
EDIT group
_______ 61% STATUS group
9%
Clear _________ 10%
FIst (Fast List)
5%
Status ________ 3
Delete ________ 10
List ___________ 1
Load ________ 9
File ___ ______ 9
BATCH Group ________ 9%
Show _ ________ 9
Submit ________ 6%
Copy _________ 2
Enter ________ 8
Compile ______ _
Display ______ 6
Format ______ 0
Assemble ______ 0
UTILITY Group
12% MISCELLANEOUS ____ 9%
Break _________ 7%
Login ________ 6%
Logout _______ 3
Errors _________ 2
Set ___________ 0
Save _________ 2
Message ____ _
3,775 Commands in Sample
The RESPOND system environment
The CDC 6600 computer at The University of Texas
at Austin consists of a high-speed central processor
with 131,072 60-bit words of central memory and 10
peripheral processors, each with 4,096 12-bit words.
All memories have a 1.0 ~sec cycle time; the central
memory has 32 independent banks permitting an upper
limit of 10 memory accesses per micro-second. The
peripheral processors can read and write the central
memory as well as their own private memories and may
address anyone of the twelve high-speed input-output
channels. The central processor has no input-output
instructions.
Jobs can be entered into the 6600 from card readers
within the Computation Center, from any of five
remote computers which communicate via broad-band
telephone lines, and from RESPOND. On a typical
weekday, about 2,500 jobs are processed by the central
computer, of which some 300 originate at RESPOND
consoles.
The SCOPE operating system at The University of
Texas at Austin requires a resident of 13,000 words of
central memory and occupies two of the ten peripheral
processors. In addition, SCOPE will call upon
the remaining eight peripheral processors from time to
time to service users' I/O buffers in central memory,
load jobs or library routines from the disk, service the
card readers by placing incoming jobs into the input
queue, schedule jobs for loading into central memory,
and attempt to keep the print, punch, plot, and microfilm queues empty.
Central memory is dynamically broken into seven
logical areas called control points. User programs are
assigned to these control points for processing, with the
central processor servicing the program in central
memory of the highest priority which does not have any
incomplete I/O buffers. In practice, one of these seven
control points is required to service all of the unit
record equipment; a second control point is occupied by
the central processor portion of the RESPOND systAm.
The central memory requirement for the former control
point varies between 512 and 8,192 words, while the
latter requires 14,600 words as a minimum and in':'
creases as a function of the activity at the remote
terminals. The maximum available central memory for
user programs is approximately 103:000 words.
Programs read from the card readers are placed in
the input queue on the disk and are assigned a central
memory access priority of two octal digits. The first
digit varies inversely as the time limit requested and
the second varies inversely a,~ the central memory
space requested. Both requests are" extracted from the
job card which is the first card of the control card
record for the program. Jobs submitted from RESPOND terminals are constrained by policy to a time
limit of 127 seconds and central memory limit of
32,768 words. Since 97 percent of all jobs run at the
Computation Center run in less than 127 seconds; the
Operational Analysis of Remote Console System
RESPOXD time limit is not unduly restrictive. While
these job card parameters could result in a modest input
queue priority had the job been entered through a card
reader, RESPOND assigns to all of its jobs a very high
priority.
The central memory scheduling algorithm is based
upon the following criterion: if a control point is
available, the highest priority job in the input queue
whose central memory request is less than or equal to
the current unused central memory is brought to a
control point. Once there, the job runs to completion,
and its disposable files are collected and routed to the
proper output devices. Since RESPOND jobs are given
a very high input queue priority, they are normally
assured of rapid assignment to a control point.
One peripheral processor is dedicated to servicing
the RESPOND communication line multiplexer, which
can accommodate up to 64 data sets. This peripheral
processor polls all active lines eleven times per second,
packing input characters into the appropriate central
memory buffer and placing output characters on the
line for transmission to the remote terminal. At the
present time 15 AT&T 103A2 data sets are available
through a rotary switching scheme. This dial-up
feature permits optimum usage of the available modems
and also permits a recorded audio message to be returned to the user if he should happen to dial up when
RESPOND is inoperative.
In addition to the peripheral processor required to
service the multiplexer, RESPOND occasionally requests other peripheral processors to assist in file
merging, job submission, etc. Also, small percentages
of certain transient system peripheral processors are
required for job scheduling, job processing, and a
dozen or so other system functions.
259
Every time a RESPOND job is submitted to the input
queue, a DAYFILE message is generated. At some
later time, the job is assigned to a control point and
another DAYFILE message is issued. Since the time of
issue is entered along with the message into the DAYFILE, elapsed time between these two events can
easily be measured. The selection of the statistics was
greatly influenced by similar studies of other remote
console systems. 4 ,5,6
The central processor portion of RESPOND is
activated by SCOPE once every 500 milliseconds.
During the few milliseconds it is active, RESPOND
services all terminals which have completed an input
message in the past one-half second. Generally, this
servicing can be completed and a response placed in
the terminal's output buffer in one "duty cycle";
however, several cycles may be required for the more
complex commands.
Figure 1 is a graph displaying the probability density
curve of the "system response time." This response time
is defined to be the elapsed time between a user supplied
carriage return (end of message) and the beginning of
the first output character from RESPOND.
Figure 2 shows the probability density curve of
"user response time" or "think time." Think time is
defined to be the time between the system response or
"go ahead indication" and the next user input character.
Think time is not really a measure of system performance but is provided in order to allow system designers to see an example of user performance. The
~
-
.15
~
Evaluation of performance
The performance discussed in this section refers to
physical characteristics of RESPOND/user interaction.
The measurements made of this aspect of performance
are of (1) system response, (2) user "think time,"
(3) delay in processing of jobs in the SCOPE input
queue, and (4) a history of RESPOND reliability.
The architecture of the 6600 makes possible easy access
to these measurements, since the peripheral processors
are independent of the central processor and may be
called upon to monitor RESPOND's progress from
time to time. 3
The response time statistics were gathered by a
subroutine in the multiplexer servicing program, which
is resident in a peripheral processor. The processing
delay statistics were gathered by post-processing of
the SCOPE chronological log (called the DAYFILE).
00
Z
~
.12
0
~
-<~
.09
~
c:Q
.06
c:Q
0
~
i:l.! .03
°0~----.~2-----.·4----~.6----~.8----~1.O~--~12
SYSTEM RESPONSE
TIME
Figure 1--8ystem response time
(SECONDS)
Spri~g
260
.18
.15
Joint Computer Conference, 1969
r
1.0
I
~
>-t
.12
E-4
r.n.
Z
.1
ril
o
>-t
~ ~
.06
.03
co
o
.r
~
~1"~
.01
-
....':,.....
~
o o~----~----~----~----~----~--~
2
4
6
8
10
LARGE
~
SMALL CORE
CORE
MEDIUM
CORE
--------- ---- ----~
12
THINK TIME (SECONDS)
Figure 2-Think time
.001
~--
o
"typical" RESPOND user
in Table II.
IS
further characterized
__
~
10
____
~
20
____
~
30
____
~
40
INPUT QUEUE DELAY
____
~
50
_____
60
(SECONDS)
Figure 3-Input. queue delay
Table II-The typical RESPOND Userl
Time at Console __________________________ _
Number of jobs submittted _________________ _
Computer time ___________________________ _
Number of commands input ________________ _
Number of lines of data input ______________ _
Number of lines of data output _____________ _
Number of disk accesses ___________________ _
Average think time ________________________ _
15.25 minutes
1.12 jobs
8.1 seconds
19
29
71
43
5.5 seconds
Figure 3 indicates the input queue delays for submitted jobs. The small core curve represents the delay
for jobs requiring between 0 and 8,192 words of central
memory, the medium core curve for jobs between
8,193 and 24,576 words, and the large core curve for
jobs between 24,577 and 32,768 words. These curves
were derived from more than 28,000 RESPOND jobs
observed over a 9-month period of time. Although these
curves represent delays primarily due to a temporary
unavailability of sufficient central memory in which to
run the job, it can be seen that the operating system
is rather insensitive to varying central memory requirements.
As was demonstrated in a survey of user reactions,
the most important single attribute of a remote console
system is system reliability. One of the most exasperating events in man-machine interaction is for the man
to spend time keying in a text and then for the machine
~o "lose" it. Thus, in spite of almost instantaneous
response time and a multitude of user-oriented conveniences, an unreliable system is of little value.
RESPOND reliability has been uneven at best.
The types of system failures include RESPOND
bugs, SCOPE failures which cause RESPOND to
malfunction, and hardware failures. Currently, there
is a restart capability which permits recovery from
many of these failures. This restart permits a user's
files created prior to his most recent SAVE command
to be recovered. Thus all failures result in some loss of
files, but in most cases, the losses are minimized.
Other failures cause the loss of all files created since
the time of the last dump of RESPOND files to magnetic tape which, in the worst case, is four hours.
Figure 4 is a history of all RESPOND failures from
September 1967 to January 1969. The ordinate of the
graph is the ratio of the number of failures per thousand
RESPOND jobs submitted. It should be noted that
this ordinate is a logarithmic scale. Currently, the
ratio of unrecoverable failures (dump tape reload) to
recoverable failures (restart) is about 1 :10.
Operational Analysis of Remote Console System
261
to do the things it should do, and improvements that
could be made to the system. In the first category,
the single biggest complaint was the unreliable nature
of the system in saving user files from one session to
the next. A new user quickly learns (usually the hard
way) that newly created files should be copied to punch
cards, magnetic tape, paper tape, or the printer as a
precautionary measure. These files can then be reintroduced as RESPOND files with minor inconvenience to the user. Table III presents a tabulation
of users' ratings of RESPOND's reliability.
100
Table III-Users' ratings of RESPOND's reliability
1~~~~~~~~~~--~~~~~~~
SON
67
D
J
F
M
A
M
J
J
·A
SON
68
D
J
69
DATES
Figure 4-History of RESPOND failure rat.e
Certain sYstem failures include those which involve a
failure in the communication equipment. As initially
installed, RESPOND made no check of the modem
status. In some cases, a telephone line was inadvertently disconnected, but the user's password
remained logically "in use." With the installation of
the dial-up network, this created a serious problem,
since a user could no longer select his point of connection to the multiplexer. A local modification added
a test for "modem connected" status to the multiplexer
servicing routine and automatically initiated a LOGOUT if a disconnected modem was found. This modification has virtually eliminated all RESPOND
failures due to communication equipment malfunctions.
User reactions
Initially, RESPOND passwords were issued only to
faculty and staff personnel and selected graduate
students. This was due in part to the novelty of the
system and a feeling of a lack of need on the part of
many potential users. More recently, the user population has grown to indude graduate students in many
disciplines and certain undergraduate classes as well.
Presently, there are 142 active passwords outstanding
with 1,194 files in their file catalogs.
A questionnaire was recently distributed to .all
RESPOND users. They were asked to comment on
their usage of RESPOND, to give their opinions of
the reliability of the system and to suggest improvements which they felt could be made to the system.
Complaints from the user population can be easily
broken down into two groups: failures of RESPOND
Rating
Percent of Responses
Excellent ___ _______ _____ ____ ______ ____ __ __ __ _ 2.3%
Good________________________________________ 18.2%
Fau_________________________________________ 41.0
Poor ________________________________________ 29.4
Unusable ____________________________________
9.1
Two highly desirable features of RESPOND are the
control card compatibility with the batch system and
the availability of the entire system library to the
RESPOND user. These features eliminate duplication
of programming and system maintenance in the applications software area and permit a user to easily
switch between normal batch processing and RESPOND without fear of system incompatibility. A
summary of programming languages utilized by users
who answered the questionnaire is given in Table IV.
Table IV-Programming languages utilized by RESPOND users
Programming Language
Percent of
Users Responding
FORTRAN _________________________________ 98%
ALGOL ___________________________________ - _ 22
LISP________________________________________ 22
COMPASS ________ _____ ______ ______ ____ _____ 20
Other _________________________________________ 5
L6 ___________________________ :_____________
2
SNOBOL ___________________________________
2
The improvements which were suggested included
the implementation of a context-oriented text editor,
provision for a conversational or interactive capability,
and modification of some of the system-wide services
to limit the amount of printed output for RESPOND
users. The first and third suggestions are particularlr
262
Spring Joint Computer Conference, 1969
important when the remote console in use has a slowspeed printer. The most consistently suggested improvement was that reliability and dependability be
improved. The group making this suggestion stressed
the idea that RESPOND is a useful tool in their work
but that this usefulness would increase as system
integrity and dependability improved.
Those who had the most praise for the system were
those who otherwise would have had limited access to
the 6600. They tended to have longer sessions at their
terminals and were quite creative in their handling of
multiple files. One graduate student claimed he completed his research for his doctoral dissertation a year
early due to his access to a RESPOND tenninal.
~
c,:,
<
en
::;J
0
en
en
~
0
0
• Often, the remote console system is just taking up
"slack" in the system resources.
• The remote console system can ease the load on the
nonnal batch processing portion of the computation center.
It cannot be denied that system interference, the
occupation of valuable memory space and a control
point, and the use of one dedicated peripheral processor
by the remote console system represent tangible costs.
Table V shows the utilization of various system resources over a period of one month.
Table V-RESPOND utilization of system resources
Maximum Average Minimum
Characters of disk storage
required for RESPOND files __
Central memory words required
by RESPOND ______________ 29,800
Percent of available central
processor time used by
RESPOND* ________________ 6.9
Percent of available peripheral
processor time used by
RESPOND* ________________ 18.1
14.5xlQ&
22,100
14,600
4.7
0.39
14.1
12.5
The next two figures illustrate the demand made of
certain system resources as a function of the number of
* These figures do not include time required to run the programs
submitted from RESPOND terminals. The peripheral processor
percentages include the dedicated peripheral processor which
services the multiplexer.
1.5
~
Il.t
...:I
<
~
E-t
Z
~
0
z
The cost of providing a remote console capability
within a multiprogramming system is difficult to
detennine due to the following considerations:
I
I:t:
E-t
Gosi
r
wL
~
0
~
~
Il.t
1.0
~
.5t-
J
0
2
4
6
8
10
12
NUMBER OF ACTIVE USERS
Figure 5-Central processor usage
active users. Figure 5 indicates central processor time
used by RESPOND. This measurement does not
include the periods of dump tape loading and unloading,
which averaged 0.62 seconds per file. With no users
logged in, the central processor portion of RESPOXD
requi,res 1.94 milliseconds to complete a duty cycle.
Since duty cycles are initiated once every ,100 milliseconds, an overhead of 0.39 percent of available central
processor t.Lrne is obt.ained. Figure 6 reflects RESPOND's requirements for additional central memory
workspace as the number of active users increases.
Since the amount of workspace required by a user
depends upon the nature of his activity, no simple
fonnula can be given which will anticipate central
memory reqJ.lirements.
The file structure for RESPOND files stored on the
system disk is designed to permit rapid access to
individual lines of text. The SCOPE file system has
as the basic allocatable item a half-track, which is
48 64-word sectors. ** RESPOND breaks down each
half-track assigned to it into 6 disk blocks of 8 sectors
each and keeps a record of both the half-track number
and block starting sector.
Each disk block, then, is 5,120 characters in length,
** Originally 50 sectors, the SCOPE half-track was reduced to
48 sectors in order to achieve a multiple of 8 sectors per halftrack as required by RESPOND.
Operational Analysis of Remote Console System
48
263
100
en
E-4
~
::s
<
<
0
E-4
40
~
::>
0
....
........
0
~
32
=::>
~ ~III
....
~
~
~
0
~
----------
24
0
::s
~
>C
16
~
z
~
~
U1
60
~
0
40
E-4
Z
r£l
0
8
~
20
ff
~
<
~
=::>
E-4
t3
80
0
0
4
6
8
10
o
12
o
4
8
12
16
. 20
NUMBER OF ACTIVE USERS
DISK BLOCKS PER FILE
Figure 6-Petl.k central memory usage
Fi~ure
and the file structure is such that any coded file requires a minimum of three disk blocks while binary
files require a minimum of two disk blocks. Coded
files are made up of one file header block and an arbitrary number of sequence number and text blocks.
Since binary files have no sequence numbers associated
with them, they do not require sequence number
blocks. It has been observed that many RESPOND
failures occur in the mapping operation between the
SCOPE and RESPOND file structures described
above.
Figures 7 and 8 show how user files are allocated
on the disk by RESPOND. The portion of the file
which contains useful data is plotted against the number
of blocks required to contain that file. As the size of
the file increases, the allocation efficiency of this file
structure appears to stabilize near 85 percent. As Figure
8 indicates, however, the number of files which enjoy
this allocation is a negligible percentage of the total
number of user files. Since two-block files can only be
binary files, the distributions shown in Figures 7 and 8
are slightly distorted. The data used in these figures
represent 1,194 files distributed over 142 users. Ninetyone percent of the files were coded and nine percent
were binary.
Aside from costs in terms of system resources, a
remote console system can add other costs to the operation of a computation center. When such a system is
. first installed, it is very likely that several local modifications will be needed in order to tailor the operation
7-Disk file storage efficiency
100
80
,,,
,,,
,,,
,,,
,
60
40
20
a
a
4
8
12
DISK BLOCKS PER FILE
Figure 8-File size distribution
16
264
Spring Joint Computer Conference, 1969
of the system to the particular user's environment.
As usage of the system increases, demands for additional features, extended capability, and higher
reliability will be voiced by users. Finally, like any
other large, complex system, it is certain to have at
least one remaining "bug" in it at all times. 7 For these
reasons, the talent of a systenI programmer thoroughly
familiar with the operation of the system will be
required throughout the life of the installation.
A remote console system also demands the attention
of the computer operators, a fact that is often overlooked in cost forecasts. It is estimated that at The
University of Texas Computation Center, the computer
operators spend about 1/10th of their time on tasks
directly related to RESPOND. These tasks include
replying to user messages on the master console,
handiing magnetic tape for some RESPOND jobs,
loading and dumping RESPO~D files, and intervening
in the event of system failures. Since the remote
console users are on-line, the computer operators must
be prepared to service these demands in a punctual
manner. They sometimes view this responsibility as
a hindrance to thejr normal batch processing duties.
se:\I~IARY
A remote console system whieh has been in operation
for more than 20 months has been analyzed. rrhis
analysis covered system performance, system reliability,
user reaction, and cost. The study pointed out the
following:
• System reliability is of paramount importance.
• A remote batch entry system such as RESPO:XD
is very useful for many types of applications.
Expanding its capabilities to include interactive
processing and context-oriented text editing would
make the system appeal to a larger class of users.,
• It is extremely important that the remote cons~ole
system and the operating system be compatible
in as many areas (e.g., file structure) as possible.
RESPO~D's utilization of standard system software is considered a strong point in its favor.
• The cost of providing such a service is more than
the expenditure of system resources such as
processors, core memory, and mass storage. It
also includes the talents of system programmers,
computer operators, and a person to provide
iiaison between the remote users and the computation center.
REFERENCES
E A PEARSO~
RESPOND, a user's manual
Computation Center The University of Texas Austin 1967
2 TTY RESPOND reference manual
Control Data Corporation Publication nr 60189300 1967
3 D F STEVEXS
System evaluation on the Control Data 6600
Proc International Federation of Information Processing
Societies CO~GRESS 68 C34
4 A L SCHERR
Time-sharing measurement
Datamation Vol 12 No 4 22-26 April H)66
5 G E BRYA~
JOSS: 20,000 hours at the console-a statistical summary
Proc F J C C 1967
6 R V BUTLER
The Langley Research Center remote computing terminal
system: implementation and first year's operation
Proc 21st ~ational ACM Conference 1966
7 E \V PULLE~ D F SHUTTEE
.lfUSE: A tool jor testing and debugging a multi-terminal
programming system
Proc S J C C 1968
A model for core space allocation in a
time-sharing system
by MAURICE V. WILKES
The University Mathematical Lahoratory
Cambridge, England
INTRODUCTION
In a time-sharing system that is intended to serve a
number of console users simultaneously, there are two
related, but distinct, functions to be performed. One
is time slicing, which is the allocation of bursts of processor time to the various active programs according
to a suitable algorithm. The other is core space allocation which arises because, in a modem multi-programmed system, there will be space in core for more
than one active program at the same time. If, as will
normally be the case, there are more active programs
than can be accommodated in core, some of them must
be held on a drum and brought into core periodically;
this is swapping. Confusion has sometimes arisen between time slicing and swapping, since, in the early
time-sharing systems, there was only one active object
program resident in core at any time, all the others being
on the drum. In these circumstances, swapping and time
slicing go together; when a program is in core, it is receiving processor time, and as soon as it ceases to receive
processor time it is removed from core. In a multi-programmed system, however, space allocation and time
slicing can proceed independently. It is the responsibility of the space allocation algorithm to ensure that,
as far as possible, there is always at least one program
in core that is ready to run. The time-slicing algorithm
is responsible for dividing up the available processor
time between the various programs that are in core.
Models can play a similar part in the discussion of
computer systems as they can play in scientific theory.
Practical situations tend to be highly complex, and a
model serves the purpose of isolating and focusing
attention on those features that are relevant to the purpose in hand. Since a model is simple, it can be defined
precisely, and hence made to serve as a suitable basis
for analysis, mathematical or otherwise. A model has
essential features and non-essential features, and one
object of analysis is to determine which are which. A
model of a software system is not a blueprint for an
implementation; a given model may, possibly, be implemented in a number of quite different ways. The
implementer may depart from the model, for example,
by adding features which spoil its simplicity but increase
the running efficiency. In such cases, the analysed performance of the model gives a lower limit to the performance of the system. On the other hand, the implementer may be faced with practical limitations that the
model maker could ignore, and these may lead him to a
variety of compromises and sacrifices to expediency.
The model
This paper is concerned with core-space allocation
for object programs only, and it is assumed that the
supervisor is provided with a separate allocation system
of its own. Practical reasons why this is desirable derive
from the fact that a good deal of information is available about the likely behavior of supervisor processes.
Some routines in the supervisor are needed so frequently
that they must be kept permanently resident in core; in
the case of others; it may be known that, when they
have finished running, they will not be needed again for
an appreciable time, and these processes, therefore, are
best called down on each occasion when they are required. A system of requesting and keeping priorities
specially adapted to the administration of the core
space available for supervisor processes has been described by Hartley, Landy, and Needham;l this system
lends itself to use in the case where, as in the model to be
described, the amount of core space actually available
to the supervisor varies dynamically from minute to
minute. One of the responsibilities of the supervisor is
handling input and output, and provision of the necessary space for buffers is dealt with by the space alloca265
266
Spring Joint Computer Conference, 1969
tion procedure associated with the supervisor. There
will be several further references to supervisor space
scheduling, but the subject will not be discussed in
detail.
In describing the model, it will be assumed that there
is only one processor in the system. There is, however,
no reason why there should not be more than one. The
issue hardly affects the problem of space allocation,
although it does, of course, affect the design of the timeslicing algorithm.
There is some difficulty in arriving at a nomenclature
that is not ambiguous or misleading to describe the flow
of work through a time-sharing system that is handling
both a foreground and a background load. In the case
of a batch-processing system, one can think of the work
being presented a.s consist.ing of a series of self-cont.ained
jobs, each of which may pass through a number of stages
variously known as job steps, phases, or tasks. If the
same point of view is adopted in relation to a timesharing system, then an on-line session at a console consists of a single job; a user, however, is more likely to
think of himself as creating a number of separate jobs,
some of which may run independently, and some run
interactjvely. A distinction must also be made between
programs that are run on behalf of a user, and programs
that are run on behalf of the supervisor; the former are
sometimes called object programs. This paper is concerned with the work in the system at a given time and
not with the life history of individual jobs according to
any particular definition of that term. The termsjob and
object program will, therefore,' be used more or less interchangeably to refer to tasks or sub-tasks requiring to be
done on behalf of a user and existing in the system at a
given moment.
Swapping and resident regimes
Object programs that live on the drum and come in
and out of core for periods of activation may be said to
operate in the swapping regime; as pointed out above,
such programs do not necessarily have the use of the
processor for the whole time that they are in core.
Programs that remain in core, and receive bursts of
processor time at intervals, may be said to operate in
the resident regime. In the present model, all programs,
when first loaded, are operated in the resident regime,
and those that survive for more than a short length of
time pass into the swapping regime.
The explanation can be followed by reference to Figure 1. The lowest area of core is known as the swapping
area, and is the area into which programs currently
operating in the swapping regime are transferred in
order to be eligible to receive processor time. In the
simplest mode of operation, there is only one program
n
CORE MEMORY
RESIDENT
SUPERVISOR
NON-RESIDENT
SUPERVISOR.
BUFFERS.
SUBSYSTEMS
VARIABLE BOUNDARY
-------- }-----{
'\
PIPE LINE
SWAPPING AREA
~
DISC
OBJECT PROGRAMS LOADED
ACCORDING TO PRIORITY
RULES AS SPACE BECOMES
AVAILABLE
L.o.----.I}----l_
DRUM
Figure 1
at any time actually loaded into the swapping area, but
more elaborate modes are possible. Above the swapping
area comes the pipeline. This is large enough to contain
several of the maximum-sized programs that are acceptable to the system. Programs enter the pipeline at
the top and work their way down in the manner that
will be described. * If they survive long enough, they
eventually enter the swapping area. The top boundary
of the pipeline is dynamically variable, and is indicated
by a dotted line. Above this comes an area for holding
sections of the supervisor that are kept on a drum or
disc and brought into core only when they are needed.
The same area is used to provide buffer space for the
supervisor, space for lists maintained by the supervisor,
and space for sub-systems that are subjected to supervisor-type scheduling, rather than to object-program
type scheduling. Finally, at the top of the core, there is
a region reserved for sections of the supervisor that are
permanently held in core.
An object program starts its life by being queued on
the disc, along with other object programs that have
* References to programs being moved down the pipeline do not
necessarily imply that in an implementation programs should be
physically moved in core. A system in which a similar effect
were obt2.ined by software devices or by paging hardware would
be a valid implementation of the model.
A :Model for Core Space Allocation
been created either by a user or by the system. When
space becomes available at the top of the pipeline, one
of the waiting object programs is selected for loading by
the pipeline loading routine in the supervisor. The pipeline loading routine is designed to favour short programs
while ensuring that long ones are not indefinitely delayed, and, at the same time, to give effect to the differing priorities that may be attached to object programs, either as a result of administrative decision or
by system requirements. When an object program
enters the pipeline, it is given an upper limit for space
(including space for data) that it may occupy, but no
actual allocation of space is made at this moment
beyond that immediately needed. Thus, a program of
length 4K words that it is known will ultimately require
another 8K for data is given an upper limit of 12K, but
receives no more than 4K of physical space when first
loaded into the pipeline.
When in the pipeline, object programs receive slices
of processor time as determined by the time-slicing
algorithm. Object programs that do not survive long
enough to enter the swapping regime can leave the
pipeline in various ways. They can become dead or
dormant, the difference between these two states being
that a dead program is needed no more and can be
abandoned, whereas a dormant program must be transferred to the disc for possible reactivation, or post
mortem examination, if required. An object program
can also leave the pipeline as a result of going into a
console wait; a discussion of what should happen in
these circumstances will be reserved until later.
When space in the pipeline becomes free as a result of
an object program leaving it, programs higher up in the
pipeline are shifted down to fill the vacant space. This
can result in space appearing at the top of the pipeline,
in which case the pipeline loading routine can either
load a new object program at once, or wait until additional space has become available. On the other hand,
one of the other object programs in the pipeline, above
the one that has disappeared, may be waiting for additional space, in which case the space now available (or
as much as is needed) is given to this object program,
any surplus being passed upwards for allocation to
another waiting object program or to be made available
to the pipeline-loading routine. One may think of a
bubble of space passing upwards and either being absorbed or partly absorbed on the way, or reaching the
top. If an object program survives long enough to reach
the bottom of the pipeline, it is eligible to pass into the
swapping area. The rate at which object programs are
withdrawn from the pipeline controls ultimately how
much space becomes available to the pipeline-loading
routine and hence the rate at which new object programs are loaded.
267
The efficient operation of the system requires that
the pipeline shall contain a sufficient number of object
programs, or jobs as they will now usually be called;
there is no point, however, in increasing the number of
jobs beyond the point at which there is a high probability that, at any instant, there will be at least one job in
core that is ready to run. The criterion here is the number of jobs in the pipeline, not the total core space that
they occupy. The amount of space needed in the pipeline will, therefore, vary from second to second, according to the average size of the jobs. When there is
space to spare, it is better to give it (temporarily) to
the supervisor rather than to load redundant jobs. The
supervisor will be able to make good use of the space
for purposes already mentioned, such as holding nonresident routines. and temporary buffers. In the model,
therefore, we assume that the pipeline loading algorithm
is designed to keep the number of jobs in the pipeline
constant.
The pipeline has the effect-and this indeed is its
purpose-of filtering out jobs that run for short periods
only, since these will leave the pipeline before they
reach the bottom. Since they never reach the swapping
area, the overheads of swapping are avoided altogether
in the case of such jobs.
Jobs that are interacting closely with a console will
typically run for short periods, and go into frequent
console waits. Such jobs are, therefore, most suitably
dealt with by the pipeline technique, rather than by the
swapping technique, and, of the various strategies
available, the following would appear to be the best
calculated to give a high standard service to such jobs
without interfering with the smooth running of the
system as a whole.
A highly interactive job enters the pipeline in the
manner that has been described with no special privileges; it will not, in fact, be known to the system at this
time that the job is highly interactive. The job may be
expected to reach a console wait while it is still in the
pipeline, although there is no reason why it should not
run long enough to enter the swapping area. The
essence of the strategy proposed is that, when reactivated by a response from the console, the job should
re-enter the pipeline at the top. A job reaching a console
wait is, therefore, immediately removed from the
pipeline and, on reactivation, is returned to the queue
of jobs waiting to enter. In order, however, that it
should not be subject to the delays that normally occur
at this point, it is handled according to special rules;
what these are depend on the importance attached to
giving the best possible response to jobs while they are
interacting with a console. An advantage of the model
is that it enables one to see what is the cost of the
various steps that can be taken to this end, both in
268
Spring Joint Computer Conference, 1969
terms of the employment of system resources and the
effect on the throughput of other types of job. One step
that will naturally be taken is to provide that a console
wait job shall be placed on a separate queue and given
priority over jobs waiting on the regular queue to enter
the pipeline. Further improvement can be obtained by
implementing this special queue on a drum instead of
on the disc; in the model, the drum used for this purpose
would be shown as separate from the drum used for
swapping, although, of course, in an implementation,
the same physical drum might be used for the two
purposes. A further step that could be taken to improve
the response after a console wait would be to design the
pipeline loading algorithm so as to keep in hand a certain amount of space at the top of the pipeline for the
accommodation of console-wait jobs when they are reactivated. The more space kept in hand, the better will
be the service given to highly interactive jobs, but the
greater wHl be the cost to the system. The balance to be
struck is a matter for management decision in any particular case.
Since an interactive job returns to the queue of jobs
waiting to enter the pipeline when it comes to a console
wait, it is treated by the system as though it were a new
job, although one having special priority. In what
follows, therefore, the term 'job' will for brevity be used
to denote either an entirely new job or an interactive
job that has been resuscitated after a console wait.
Jobs may be held up waiting for other forms of peripheral action, such as disc or magnetic-tape transfers. The
former are of brief duration, and the jobs concerned
continue their progress through the system . .:\Iagnetic
tape waits, however, are of relatively long and uncertain duration; they have a good deal in common with
console waits, and it can be argued that they should be
dealt with in a similar way.
Time-slicing algorithm
The core space allocation system ensures that, at any
given time, there are sufficient object programs in core
to make effective multiprogramming possible, and that
any programs resident on the drum come into core often
enough to be able to receive processor time at appropriate intervals. The time-slicing algorithm determines
how the processor time is allocated to the various
programs that happen to be in core and are free to run,
whether they are in the pipeline or in the swapping area.
I t may be assumed, although this is not strictly necessary, that time is shared between the pipeline and the
swapping area in a fixed proportion. Time is given to
programs in the pipeline in small slices; the smaller the
slice the better, provided that program changing over-
heads do not account for a significant fraction of the
total time. X ote that a program temporarily resident in
the swapping area will not be active during the whole
time that it is in core. Like programs in the pipeline, it
will receive time in small slices; it will be returned to the
drum when the total amount of time that it has received
since being loaded reaches a certain figure, chosen to be
high enough to make the overheads of swapping worthwhile. This figure would be greater for long programs
than for short ones since the swapping time depends on
a program's length.
Swapping re1Jime
If the allocation of processor time to jobs in the
swapping regime is a fixed proportion of the total time
available, then the rate at which jobs terminate depends
only on their average expectation of life at the moment
they enter the swapping region; in fact, the rate at
which jobs terminate is I/il, where il is their expectation of life, calculated on the assumption that there
would only be one job in the swapping regime. The
rate of termination of jobs is, in particular, independent
of the number of jobs in the swapping regime. Thus,
the swapping regime may be likened to a hopper from
which objects are extracted at a given mean rate.
Since the rate of entry and the rate of abstraction are
subject to stochastic variations, the number of jobs in
the swapping regime will fluctuate about a mean, even
if the mean rate of abstraction is equal to the mean
rate of ent~y. The problem of investigating these variations may be tackled by the methods of queuing theory.
The simplest method of core space allocation for the
swapping regime is to bring one program into core at a
time; the time-slicing algorithm has then only one program in the swapping area to be concerned with.
Almost as simple, if the hardware permits, is the wrap
around method in which the section of core constituting
the swapping area is addressed modulo n, where n
(in practice a power of ) is the number of words
it contains. Each new program brought down starts
where the previous one left off and if the programs are
short several can be in core at once. A maximum-sized
program will, of course, occupy the whole swapping
area. The time-slicing algorithm can be designed to
take- advantage of the fact that there may be more than
one program in the swapping area at a given time. The
result is an improvement in the average efficiency of the
multiprogramming.
Once a program has entered the swapping regime, its
troubles as regards acquiring core space are over, and
it can occupy as much core (up to the maximum permitted to any program) as it requires.
A Model for Core Space Allocation
The pipeline
If the number of jobs in the pipeline is held constant,
then the methods of standard queuing theory are not
applicable. An approximate treatment is, however,
offered in the Appendix. For a given rate of abstraction
of jobs from the pipeline this enables the distribution of
age of those jobs to be computed, and also the rate at
which jobs must be loaded to keep the pipeline full.
In order to carry through the calculations, it is necessary to assume a form for the statistical distribution of
job life. In one particular case (the Poisson case) the
treatment becomes exact. This is the case in which the
(lxpectation of life of a job is independe.nt of its age.
The practical effect of the pipeline is to filter out short
jobs before they can enter the swapping regime. It is of
interest to know the expectation of life of jobs emerging
from the 'pipeline since this determines their behavior
in the swapping regime, namely, how long they are
likely to remain in it, and how many times they are
likely to be swapped. In the Poisson case, the probability of a job reaching the end of its life in an interval
5t is independent of its age, and its expectation of further life is also independent of its age. In this case, the
expectation of life of jobs entering the swapping area
will be equal to their expectation of life when they enter
the pipeline. If, however, the probability of a job
rea.ching the end of its life in 5t increases with a.ge, so
that a job that has survived an initial period is unlikely
to continue for a long time, then the expectation of life of
jobs entering the swapping area will be less than
their initial expectation of life. If this is ~o to any
marked degree, the effectiveness of swapping is open to
question, since very few jobs will survive more than onf'
swap, and an increase in the length of the pipeline
sufficient to allow all johs to finish while stil1 within it
would he' more' suitable'.
I mpleJlu>,ntatioli
It has alrE'ady been mentiollcd tha,t systrm~ in which
programs are not physieally shifted in tore, but in whi('h
similar effects are achieved by other means, are to be
regarded as valid implementa.tions of the model herp
described; the model is, ill fact, much more general than
the description given above may at first sight suggest.
Essential features, however, art' (1) tha,t WhPll a job is
first loaded it is givpn a period of continuom; residpncp
in (~ore before a regime in whieh regular s,vapping to and
from a drum is initiated, and (2) that spa.ce is given to fl,
program piecemeal as it needs it and not all at oncE'.
These objectives can be achieved by a dircet imple'mentation of the shifting described in thp model or by
making nsf' of a hard·warp paging sy-stpm. In relation to
269
the latter case, the discussion given here is really a
discussion of the way in which the paging algorithm
should be designed. The objectives can also be achieved
approximately if programs on first loading are so located
in core that enough contiguous space to meet their ultimate needs can be earmarked for their use. Until such
time as they need the space, it can be made available to
the supervisor for accommodating non-resident rou.j.;...,.,..",
nn;J f",~ h".1!{',..~;...,.~ 1
tJU.Lvo a.uu lV.L UU1!\:;.L.L.L.L~.
Overall control of the system
One of the objects of establishing a model for core
space allocation is to enable the control problem for the
system as a whole to be formulated. The problem of controlling a time-sharing system has much in common
with control problems met in the process industries, and
this fact will be brought out by describing a closely
analogous problem connected with the control of an oregrading plant.
In an industrial plant, there are commonly a number
of purely local control loops presided over by controllers
that operate independently of the main control system.
One sueh control loop-eonnected with the balance
between foreground and background jobs-can be
identified in the time-sharing system under discussion.
.Tobs that are ready to enter the pipeline wait on one of
a number of queues on the disc. In the simplest case
there will be separate queues for foreground jobs and for
background jobs, the latter including background jobs
initiated from consoles. There is, in addition, a queue
for jobs waiting to be reloaded after a console wait.
.J obs are loaded into the pipeline according to rules
designed to give priority to jobs waiting to be reloaded, and otherwise to favor the foreground to the
extent determined by operational requirements. These
rules can be designed in such a way that minor shortt.erm variations in the foreground load can be accommodated by varying the ra.te at which background jobs
are fed, thus avoiding the need for significant variation
in the rate of flow of jobs into the pipeline. This is a
piece of local control of a straightforward kind. Longer
term changes-up or down-in the foreground load reINCOMING ORE
•
.
••••• •
SCREENING PlANT
·•
•
Figure 2
270
Spring Joint Computer Conference, 1969
main to be dealt with by the overall control mechanism,
which will forcibly log out a proportion of the users
(after giving them a warning) when the load is heavy
and allow extra users to log in when the load is light.
The closely analogous problem that will be considered
is that of controlling the ore-grading plant illustrated in
Figure 2. Lumps of ore of varying sizes enter a screening
plant and the smaller ones fall out. The larger lumps
continue and pass into a hopper from which they are
extracted at a constant rate by a conveyor. The screening plant corresponds to the pipeline and the hopper to
t.he swa.pping area. Ore is fed to the plant from an external source, and the rate of flow can be controlled,
although response to control signals is not rapid. This
corresponds to adjusting the number of console users of
a time-sharing system in the manner just described.
The input parameter:;; on which control of the oregrading plant must be based are ,(1) a measurement of
the amount of the material in the hopper, and (2) a
measurement of the amount of material that has piled
up at the entry to the screening plant. There must be
two output signals from the control system; of these,
one is used to control the rate of flow from the screening
plants to the hopper, and the other is sent to the ext.ernal source of supply and used to control the rate of
feed of ore into the plant. The design objectives of the
control system are, in the short-term, to make use of the
storage capacity available in the hopper to prevent any
appreciable piling up of material at the entry to the
screening plant and, in the long-term, to adjust the rate
of arrival of material so that the system operates
smoothly and efficiently with as little material as
possible in the hopper.
Time delays are a common cause of instability in the
operation of a plant if the control system is not carefully designed. In the time-sharing system, instability
could occur on account of the fact that changes in loadthat is, ehanges in the number of userR logged in-cannot he made instantaneously. If, for example, the control mechanism, faced with an increaRe of activity on
the part of the users currently logged in, were to overestimate the number that must be warned off, the
sYRtem would, at some later time, be found to be underloaded. Over-correction of this situation would, in turn,
give rise to eventual overloading, and the system would
proceed to oscillate between one extreme and the other.
On the other hand, the use of a eontrol mechanism that
aehieved stability, and avoided overloading, by being
unduly cautious in allowing the number of on-line
users to grow when the system was underloaded would
obviously result in the system running below capacity
most of the time as far as service to on-line users was
concerned. These are typical problems encountered in
control engineering, and it is suggested that the designers of time-sharing systems could learn something from
their colleagues working in that discipline.
REFERE~CE
D F HARTLEY B LANDY R M )l"EEDHAM
The structure of a multiprogramming supervisor
The Computer Journal 11 No 3 p 247 )l"ovember H)68
APPENDIX
A nalysis of pipeline
The following approximate analysis applies to the
case in which the number of jobs emerging from the
pipeline is small compared "'.vith the number of jobs
entering.
Let P(f) be the probability that a job entering the
pipeline has a life* greater than or equal to f and let
p(f) = - ap(f)/af
p(f) of
IS
the probability that the job finishes in the interval Of, i.e.,
between f and f + Of. The expectation of life of a job
entering the pipeline is then
1=
lr¥J t p(t) dt
o
By integrating by parts it may be shown that
given by
t
=
lr¥J P(t) dt
t
is also
(1)
o
Consider a pipeline containing n jobs from which no
withdrawals are made, but in which each job is replaced
by a new one as soon as it finishes. The probability of a
job selected at random at a randomly chosen instant
having an age greater than or equal to f is then
A(f) = (Ill)
f~ 'P(t) dt
t
The probability that the oldest of the n jobs existing in
* For
this purpose, a job reaches the end of its life ",-hen it becomes dead or dormant, or reaches a console wait. In this Appendix, time is true elapsed time and the distributions take account
of the fa('t t.hat p]'()('essor time is heing shared among a number
of jobs.
A Model for Core Space Allocation
the pipeline at a randomly chosen instant has an age in
is Qn(C) 0( where
0(
Q,,(C) = (lIt)
~
ac
271
pipeline during a period To and the number, W, withdrawn during the same period:
)[t - WL = nTo
[1 - A (C)]r'
or
In practice, a job selected as being the oldest of the n
jobs in the pipeline at a random instant is withdrawn
and replaced by a new one. If the rate of withdrawal is
small compared with the natural death rate of jobs in
the pipeline, it may be assumed as an approximation
that Qn(C) still gives the age distribution.
Let the extra life that a job withdrawn at age f. would
have had if it had remained in the pipeline be J.I.. Then
the expectation of total life C + J.I. is given by
E(C
+ J.I.)
=
foo t
[pet) IP(C)] dt
(
= - [l/P(C)]
foo
t [ap(t) / at] dt
t
+
= f
f A(t) /P(C)
on integrating by part and using (l)' Thus E(J.I.) =
A(t)/P(t)
If this value for E(JL) is averaged over the distribution
Qn(t) , we have the expectation, L, of the amount by
which the life of a job in the pipeline is shortened by
being withdrawn:
!
1
+ WL)/t
If pet) = exp( -at) (the Poisson case) then it is well
known that the expectation of life is independent of age.
In the above notation, as may easily be verified,
The theory then becomes exact, and we have
N = nTol!
+W
The number of jobs that finish in the pipeline is
independent of the withdrawal rate, and if more jobs
are taken out then a similar number of extra jobs must
be prtt in. The expected life of a job on emergence is the
same as its expected life on entry.
I t may be observed that no job can remain in the
pipeline for more than n sampling intervals. The
approximation given by Qn(t) to the age distribution of
jobs in the pipeline, subject to withdrawal, may be
improved by redefining A(t) as follows:
A(t) = (lit)
f
nT
pet) dt
t
00
L = f
1\ = (nTo
[Qn(t) A(C)/P(t)] dC
o
It is now possible to arrive at the following relationship between the number, N, of jobs entering the
where T is the average interval between withdrawals.
The results of a series of simulations suggest that, with
this refinement, the theory is sufficiently precise for
most practical purposes.
Picture-driven animation *
by RONALD M. BAECKER**
National Institutes of Health ***
Bethesda, Maryland
INTRODUCTION
"Animation is the graphic art which occurs in time. Whereas a static image (such
as a Picasso or a complex graph) may convey complex information through a single
picture, animation conveys equivalently complex information through a sequence of
images seen in time. It is characteristic of this medium, as opposed to static imagery,
that the actual graphical information at any given instant is relatively slight. The
source of information for the viewer of animation is implicit in picture change: change in
relative position, shape, and dynamics. Therefore, a computer is ideally suited to
making animation' 'possible" through the fluid refinement of these changes.' ''l1
The animation industry is ripe for a revolution.
Historical accidents of available technology and knowledge of visual physiology have led to the evolution of
the animated fihn as "one that is created frame-byframe.' '1 The prodigious quantities of labor required
for the construction of twenty-four individual frames
per second of fihn have led to a concentration of animation activity in the assembly-line environments of a
few large companies, an artificial yet rarely sunuountable separation of the artist from the medium, and
extravagant costs. 2 In conjunction ·with other tr~nds
in American society, the result is usually what the
English critic Stephenson describes as "the respectable
sadism and stereotype of commerce."l Yet he offers
this hopeful prediction in concluding his 1967 study,
A nimation in the Cinema: There seems every reason
to look forward to changes which would make it possible
for the creative artist to put on the screen a stream of
images with the same facility as he can now produce
a single. still picture."l This paper explains how a
creative, artist, aided by a computer, can define a
stream 6f images with the same facility as he can now
produce a very few still pictures.
Although the computer's entrance into animation
has been a recent one (1964),3-4 the growth of interest
and activity has been phenomenal.6-8 Experience to date
strongly suggests that the following Rtatements are true:
1. The animated display is a natural medium for
the recording and analysis of computer output
from sirhul~tions and data reduction, and for
the modeling, presentation, and elucidation of
phenomena of physics,· biology, and engineering. 9- 15 Depiction through animation is particularly appropriate where simultaneous actions
in some system must be represented. If the
animation is the pictorial simulation of a com..
plex, mathematically-expressed physical theory,
then the film can only be made with the aid of a
computer.
2. The computer is an artistic and animation med'ium, a powerful aid in the creation of beautiful
visual phe~o'mena, and not merely a tool for the
drafting of regular or repetitive pictures. 16-19
3. The formal modeling of pictures by complexes
* Work reported herein was supported in part by Project MAC,
an M.LT. research project sponsored by the Advanced Research
Projects Agency, Department of Defense, under Office of Xaval
Research Contract N"ONR-4102(Ol), and by M.LT. Lincoln
Laboratory with support from the u.S. Advanced Research
Projects Agency.
** This paper is based on a thesis submitted in partial fulfillment
for the degree of Doctor of Philosophy at the Massachusetts
Institute of Technology, Department. of Electrical EJ:lgineering.
*** Division of Computer Research and Technology.
27:3
274
Spring Joint Computer Conference, 1969
of algorithms and data facilitates the continued
modification of a singlearumation sequence and
the production of a series of related sequences.
This paper discusses ways in which man, aided by a
computer in an interactive graphical environment, can
synthesize animated visual displays. It is widely recognized that such an environment facilitates manmachine communication about still pictures. 2o- 22 The
paper seeks to:
1. describe the role of direct graphical interaction
and sketching in computer animation, resulting
in the process we sh8JI call interactive computermediated an?,mation; and,
2. develop a new approach to the specification of
picture dynamics,. one which exploits the capacity for direct graphical interaction. The result
we shall call picture-driven animation.
A nimation in an interactive comp1..l.·ter graphics
environment
The role of direct graphi'cal interaction in the
synthesis of animated visual displays
Three aspects of the role of direct graphical interaction in computer graphics are particularly relevant
to computer anilllation:
1. The availability of immediate visual feedback
of results, final or intermediate;
core: control of the changing spatial and temporal
relationships of graphic information.
Factoring the construction of an animation sequence
facilitates the effective use of feedback from early
stages to guide work in later stages. Working on individual small subsequences helps overcome the serious
practical problems of computer time and space that
could disallow rapid enough calculation and playback.
We know from the computer graphics of still pictures
that the computer sjmulates not only a passive recording agent in its ability to retain images, but an active
medium which transfOl~ms the very nature of the sketching process. This remark applies trivially to computer
animation; one may construct a sequence of drawings
to comprise the individual frames of the film, the static
images existing at single instants of time. Picture
change that extends over entire intervals of time is then
synthesized as a succession of individual (temporally)
local changes that alter one frame into another.
This paper goes further, for it explains how the
computer can be a medium which transforms the very
nature of the process of defining picture change, of
defining movement and rhytlun. Dynamic behavior
is abstracted by descriptions of extended picture change.
These descriptions may themselves be represented,
synthesized, and marupulated through pictures, both
static and dynamic. Thus dynamic control can be exercised globally over the entire sequence. What results
is one new conception of what it means to draw an
animated film.
2. The ability to factor picture construction into
stages, and to view the results after each stage;
and,
3. The ability to sketch pictures directly into the
computer.
The power of immediate visual feedback in animation
is striking. The computer calculates, from its representation of a dynamic sequence, the individual frames
of the corresponding "movie." Like a video tape recorder, it plays it back for direct evaluation. A small
change may be made,. the sequence recalculated, and
the result viewed again. The cycle of designation of
conunands and sketching by the animator, followed by
calculation and playback by the computer, is repeated
until a suitable result is achieved. The time to go once
around the feedback loop is reduced to a few seconds
or minutes. In most traditional and computer animation environments, the time is a few hours or days.
The difference is significant, for now the animator can
see and not merely imagine the res'ult of varying the movement and the rhythm of a dynamic display. Thus he will
be led to perfect that aspect of animation that is its
The components required to realize an interactive computer-mediated animation system
Interactive computer-mediated animation is the process
of constructing animated visual displays using a system containing, in one form or another, at least the
following eight components:
Hardware:
1. A general-purpose digital computer.
2. A hierarchy of auxiliary storage. This is listed
separately to emphasize the magnitude of storage
required for the data structures from which an
animation sequence is derived and for the visual
images of which it is composed.
:). An input device such as a light pen, tablet plus
stylus,23-24 or wand,25 which allows direct drawing to the computer in at least two spatial
dimensions. The operating environment must,
upon user demand, provide at least brief intervals during which the sketch may be made in
real time. The animator must then be able to
Picture-Driven Animation
275
draw a picture without any interruption.
Furthermore, the computer must record the
"essential temporal information" from the act of
sketching. Sampling the state of the stylus 24
times per second often suffices for our purposes.
4. An output device, such as a standard computer
display scope or a suitably modified TV monitor,
which allows the direct viewing of animated
displays at a rate such as 24 fra...tnes per second.
This is essential to enable the interactive editing
of animation subsequences. The final transmission of a "movie" to the medium of photographic
film or video tape can but need not use the same
mechanisms.
Software:
5. A "language" for the construction and manipulation of static pictures.
6. A "language" for the representation and specification of picture change and the dynamics of
picture change. We shall introduce in this paper
methods of specifying: dynamics not possible
with traditional animation media and not yet
attempted in the brief history of computer
animation.
7. A set of programs that transforms the specifica;tions of picture structure and picture dynamiCs
into a sequence of visual images.
8. A set of programs that stores into and retrieves
from auxiliary memory this sequence of visual
images, and facilitates both its real time playback for immediate viewing and its transmission
to and from permanent recording media.
Figure I-An interactive computer-mediated animation console.
The author is sketching with the stylus on the tablet. There
is a CRT for viewing dynamic displays, a storage scope
above it, a typewriter, knobs, toggle switches, and
a telephone so that an animator may summon help
Figure 1 portrays a suitable environment for interactive computer-mediated animation. Figure 2 is a
block diagram of such a system.
A scenario illustrating the use of an interactive
computer-mediated animation system
To illustrate the process of animation in an interactive computer graphics environment, we present a
scenario. The example, chosen for its simplicity, is an
extended version of one actually executed with the
GENEralized-cel animation SYStem. GENESYS is a
picture-driven animation system implemented on the
M.I.T. Lincoln Laboratory TX-2 computer. All capabilities purported to it are operational or could be made
so by minor additions. The written form of the interactive dialogue has been adjusted to increase its clarity.
We want to see a dynamic sequence of a dog dashing to
his dinner and then dining: The dog runs towards a
Figure 2-Block diagram of a minimal system for interactive
computer-mediated animation. The parenthesized numbers
refer to the system components defined in the paper.
bowl. Wagging his tail, he lowers his head and laps up
the milk. Several slurps of the milk are to be shown
before we cut to the next scene.
How we do it:
ANIlVIATOR(A): CALL GENESYS;
GENESYS(G): HELLO. GENESYS A WAITS YOUR
CREATION;
GENESYS either types or displays this response.
276
Spring Joint Computer Conference, 1969
A: FORMMOVIE DINNERTIME;
The animator either types the command name
'FORMMOVIE', hits a corresponding light-button
with the stylus, or writes an abbreviation of the
conunand name to a character-recognizer. 26 He
then types a movie name, 'DINNERTIME'.
G:FRESH;
No such movie exists in the animator's directory.
Hence, work begins on a totally new one.
A: FORMBACKGROUND;
A. wants to define a subpicture that will be visible
in all frames of the sequence.
G: SKETCH IT, MAN;
A: .....
A. sketches the bowl, drawing with the stylus on
the tablet. What he draws appears inunediately on
the display scope.
G:OK;
A: FORMCEL #1 in CLASS BODY;
An initial version of the dog's body·is to be made a
unique subpicture, or eel.
He sketches it, and soon adds one version of the
legs, tail, and head, each as a unique eel in a unique
eel class. Now, a coherent dog, unmoving, appears
on the scope.
A: BIND BODY, LEGS, TAIL, HEAD, TONGUE;
This guarantees that any translational motion
applied to the dog will drive the body, legs, tail,
head, and tongue together. Thus the dog won't
disintegrate while moving.
Figure 3-A static dog glides towards a bowl. The sketches are by
Mrs. Nancy Johnson of \Valtham, Massachusetts
A: FORMCEL #2 in CLASS LEGS:
A. sketches the legs in another position, that is, he
defines the second cel in the class 'LEGS.' This
may be followed by several more positions. The
images are ones that are useful in synthesizing
running and hopping movements.
A: TYPESELECTIONS from LEGS;
He types in a sequence of choices of one of the
positions of the legs. Each succeeding choice selects
which cel is to be displayed as the dog's legs in the
next frame. Of course only one set of legs is visible
in a frame.
A: PLAYBACK;
Now, as is portrayed in Figure 4, the legs move
G:OK;
A: SKETCHPCURVE BODY;
A. now sketches the path of the desired motion,
mimicking the movement with the action of his
stylUS. Hop . . . hop . . . hophophop . . . goes his
hand. The act of mimicking a continuous movement is called a p-curve.
A: PLAYBACK;
Playback the current version of the movie. Hop . . .
hop . . . hophophop . . . glides the rigid dog across
the scope towards the bowl. Four frames from such
a motion are shown superimposed in Figure 3.
Figure 4-Now the dog hops to the bowl
Picture=Driven Animation
while the dog hops to the bowl.
Further refinements to the leg motion are made.
This includes the resketching of one eel. The tail
and head movements are similarly introduced. The
sequence then appears as is shown in Figure 5.
Three tongue cels are sketched.
A: TYPESELECTIONS from TONGUE;
For most of the sequence, the zeroth tongue is
selected, that is, no tongue is visible. A single lap,
or slurp of the tongue is synthesized from the three
tongue positions, and is introduced at the appropriate time in the movie. The leftmost image of
Figure 6 shows the extended tongue.
A: TAPRHYTHM SLURPINTERVALS;
A. can feel or intuit the rhythm of the desired slurps
better than he can rationalize it. Henee he goes
tap ... tap ... taptap ... on a push-button.
A: REPEATPATTERN FROM frame 59 THROUGH
frame 64 of SELECTIONS from TONGUE atINTERVALS of SLURPINTERVALS;
Assume that the visual slurp occurs in frames 59
through 64. The pattern of tongue selections which
yields the slurp is repeated at intervaLg deterrojned
by the tapped rhythm.
A: PLAYBACK;
Now the dog goes hop ... hop ... hophophop ...
slurp . . . slurp . . . . slurp slurp.
The movie is essentially complete; minor refinements may now be made.
A: EDIT X WAVEFORM of BODY;
M~~ .acceleration in the hopping movement would
better portray the dog's eagerness for his dinner.
Henee, A. call~ forth a display of the dog's X coordinate versus time, and resketches part of the
waveform so that there is more horizontal acceleration.
A: EDIT FRAME 44;
Assume that the dog reaches the bowl in frame 44.
Viewing the sequence in slow motion, A. notices
that the dog's position at the bowl could be improved. He alters its location in frame 44 using the
knobs under the scope.
Figure 5-Eager for dinner, he wags his tail
A: FIX X and Y of BODY AFTER/rame 44;
The path descriptions are further modified so that
the dog again holds a fixed position, once it has
reached the bowl.
A: PLAYBACK;
A: SA VE DINNERTIME;
The movie is saved, available for further refinements
at any time.
G: DINNERTIl\'IE IS SA VED. GOOD BYE.
Implications of the scenario
Figure 6--S1ul'p goes his tongue. lapping up the milk
1. Approximately 100 frames have been generated
278
Spring Joint Computer Conference, 1969
from fewer than 20 eels. Only very limited
tools have been used in eel construction, specifically, programs that accept direct sketches and
that enable selective erasure of picture parts.
Nonetheless, great power results from the animator's ability to control and evaluate dynamic
combinations of a few static images.
2. Immediate playback enables interactive experimentation to achieve desired visual effects. The
actions described above, including considerable
trial-and-error, may be completed in well under
one hour, even if all cels must be constructed
anew.
3. A variety of static images, analytical graphs of
picture action, depict the time dependence of
dynamic picture parameters. An example is the
waveform representing the dog's -changing
horizontal position. Viewing such static representations aids the understanding of existing
animation sequences; resketching or editing
them changes the actual dynamic behavior
accordingly.
4. The animator may in real time mimic aspects of
dynamic behavior. His movement and rhythm
are recorded by the system for application in
the movie. This occurs when the hopping of his
stylus motion is used to drive the dog, and when
the tapping of a push-button is used to detennine
the rhythm of the slurps of the tongue.
5. Three aspects of dynamic behavior appear in
the example: path descriptions, or conceptually
continuous coordinate changes; selection descriptions, or recurring choices of cels from a cel
class; and rhythm. descriptions, or temporal
patterns marking events. The pictures (3) and
actions (4), through which direct control over
dynamics is exercised, are representations of
thE'Re thl'E'P kiud~ of gloha.l de.'{cript1·ons of dynam.ic.c.;.
6. Global operations (3)-(4), which alter dynamic
behavior over entire intervals of time, may be
supplemented where necessary by local operations, which adjust individual frames. An example is the positioning of the dog near the bowl.
The specification of picture dynamics
Three old approaches to the definition of picture
dynamics
We may distinguish three old approaches to the
synthesis of a sequence of frames:
1. The individual construction of each frame in
the sequence;
2. The interpolation of sequences of frames intermediate to pairs of critical frames' and
.....
'
,
.). The generation of frames from an algorithmic
description of the sequence.
A~imation sequences have traditionally been syntheSIzed through the individual construction of frames.
Th~ i1lusion of a continuum of time is attained through
rapId p~ayback of discrete instants of time. This approach IS the only one applicable to the construction
of pictures that defy regular or formal description, and
that require unique operations on each frame. Yet
the cost is excessive and continues to rise dramatically,
f~ster th~n the GNP.27 Salaries in large studio 'operatIOns typIcally consume half of the cost, for commercial
~~~tion ,is .a complex interaction among producers,
rureC'{;ors, aeslgners, layout artists, background artists,
key animators, assistant animators, inkers and colourists, checkers, cameramen, editors, and studio managers. 2 It is this division of labor, this dispersal of the
creative process, which separates the artist from the
medium.27 Another major weakness of conventional
frame-by-frame animation is that -there are no efficient
methods of making changes to a movie stored on photographic film or video tape. We discuss elsewhere what
role the computer might assume in frame-by-frame
animation. 28
The technique of interpolation has long been used
to cut costs and reduce the burden of picture construction which is placed on the key animator. Interpolation
occurs when the key animator asks his assistants to
fill in the pictures intermediate to a pair of critical
frames. It has been suggested that part of this process
could be mechanized.29 We do not consider further that
problem in this paper.
The generat.ion of a sequenl'.e of frames from a formal
algorithmic description is a process characterized by:
1. the need to use a computer, for it is the only
animation medimn which can follow and execute
with ease a complex algorithm;
2. generality, that is, applicability to a large class
of regularly-structured pictures;
3. representational power, or the compactness
with which interesting animated displays may
be formulated; and,
4. flexibility and adaptabiJity, or the ease with
which a variety of alterations may be made to
a movie expressed as an algorithm.
The fonn of the expression has to this date been a
written program in a picture-processing language such
as .BEFLIX,3-4 or a sequence of directives in a typewrIter-controlled command language such as CAFE.30
Herein lies another strength of the approach and also
Picture-Driven Animation
a fundamental weakness. On the one hand, many
programmers, scientists, and ~ngineers, previously not
animators but fluent in this new "language," can now
produce dynamic displays.31 On the other hand, an
animator trained in traditional madia and techniques
is forced to learn a completely new "language," a
completely new way of thinking.
One new approach to the definition of dynamics
-picture-driven anmlation
Picture-driven animation is a new process that augments harmoniously the animator's traditional techniques, that reflects and extends the ways of thinking
to which he is accustomed. Within his intuitive "language" of pictures and sketching and mimicking, he may
synthesize both components of frames, called eels, and
generative descriptions of extended picture change,
called global descriptions of dynamics.
Global dynamic descriptions are data sequences,
whose successive elements determine critical parameters in successive frames of the movie. Algorithms
embedded in a picture-driven animation system combine cels and dynamic descriptions to produce visible
picture change. The animator defines and refines pictorial representations of dynamic descriptions. These
data sequences then "drive" the algorithms to generate
an animated display. Hence the process is called picture-driven animation.
The process is powerful because it is easy to achieve
rich variations in dynamic behavior by altering the data
sequences while holding constant a few simple controlling
algorithms. The data sequences precisely determine
the evolution of recurring picture change, within the
constraints set by a choice of controlling algorithms.
We next introduce the three kinds of global dynamic
descriptions, some useful algorithms for whi~h they
may be driving functions, and some useful methods for
their static and dynamic pictorial representation and
construction. The following classification will be helpful:
A global dynamic description is either
a movement description, which is either
a continuous movement description = a path
description, or
a discrete movement description = a selection
description; or,
a rhythm description.
Path descriptions
Consider those alterations of static pictures that
consist of modificatjons of continuously variable parameters, such as location, size, and intensity. Their
279
instantaneous values determine the picture's appearance at a given moment. Thus the static picture may be
animated by specifying the temporal behavior of such
parameters. A representation of the temporal behavior
of a continuously variable parameter is called a path
description.
The movement of a fixed-geometry picture (eel) in
GENESYS is described as the change of two coordinates with time, and is represented by a pair of path
descriptions. Their specification may be used to synthesize the drifting of a cloud, the zooming of a flying
saucer, the bouncing of a ball, or the positioning of a
pointer.
Since the behavioral descriptions of the parameters
apply to entire intervals of time, the animation is
liberated from a strictly frame-by-frame synthesis.
The computer is a medium through which one can bypass
the static or temporally local and work directly on the
dynamic or temporally global. Movement is represented
as it is perceived, as (potentially) continuous flow,
rather than as a series of intermediate states.
Path descriptions, in fact, all dynamic descriptions,
may be defined by one of six general approaches:
1. The sketching of a new pictorial representation
of the description;
2. The editing or rdfinement of an existing pictorial
representation of the description;
3. The direct algorithmic specification of the data
sequence;
4. The indirect algorithmic specification in terms
of existing data sequences;
5. An indirect algorithmic specification as a
property of a constituent picture in an existing
.
. sequence; and ,
...
ammatlOn
6. A coupling to a real physical process in the
external world, such that it transmits a data
sequence as (analog) input to the computer.
Interesting couplings may be to particle collisions, the atmospheric pressure, or, in the case
of (1) and (2), a real live animator.
We shall in this paper be concerned with techniques
implementing the first two approaches only. Sketching
is useful when one knows the general shape and quality
of a motion rather than an analytical expression for a
function that determines it. ::\iodifications of the HketcheH
are frequently invoked after one views the eurrent
animation sequence and determines how it is inadequate.
There are two related kinds of pictorial representations of all movement descriptions, static and dynamic.
Both kinds may be introduced with a single example.
Consider the motion of a figure that goes from one
280
Spring Joint Computer Conference, 1969
corner of a square room to the diagonally opposite
corner by walking along two adjacent walls. We shall
ignore the vertical movement and consider only motion
of the center of the body in the two dimensions of the
plane of the ground. He first walks in the direction of
increasing X coordinate, then in the direction of increasing Y coordinate. We further assume that he begins
from a standstill, accelerates and then decelerates to
the first corner, pauses there for a brief interval while
he turns in place, and finalIy accelerates and decelerates
to his destination.
One complete description of this planar movament
consists of the functions of the X and y. coordinates
versus time. These are depicted in Figures 7 and 8.
Such representations of changing picture parameters
are called waveforms. Time is depicted, in the waveionn, along one spati.al dimension. The wavefonn's
construction requires movement of the stylus along that
dimension; the display records and makes tangible
this movement.
Alternatively, both spatial coordinates could denote
the two spatial coordinates of the movement. A natural
correspondence is established between the X(Y) coordinate of the floor and X(Y) coordinate of the me-
dium of the representation (paper, scope face, etc.).
Figure 9 depicts such a parametric curve representation
of the movement. It illustrates with clarity the figure's
path on the floor.
Yet the dynamics of the motion are hidden because
the temporal dimension is only an implicit coordinate.
This rectified in Figure 10. A stream of symbols is used
instead of a continuous trail to depict the path. Characters are spaced along the path at short, uniform
intervals of time, such as every 24th of a second. Dynamics are apparent in the local density of symbols.
Observe in particular how they cluster where the figure
pauses.
The dynamic construction of a path description is a
user-driven animated displayz:n which the timing of the
stylus's movement is preserved by recording its position
in every frame. A tangible representation of the stylus
path is the display of a sequence of characters spaced
equally in time. We shall call a parametric curve dynamically sketched in real time a p-curve. The p-curve
corresponding to Figures 7-10 is depicted in Figure 11.
We have attempted to convey in a single static image
that the p-curve is a dynamic display. Each 2-dimensional p-curve determines two path descriptions. Thus
the hopping of the dog in 'DINNERTIME' may be
synthesized by "hopping" with the stylus along some
path on the tablet surface, that is by mimicking the
desired dynamic.
Figure 7-The X coordinate waveform of a movement
Figure 8--The Y coordinate waveform of a movement
Figure 9-A parametric curve representation of the same
movement. The rhythm of the movement is not visible
Picture-Driven Animation
281
In some cases one may need only one of the path
descriptions. To depict the fluttering of a. heart, we
may assign the X coordinate of the p-curveto a parameter determlnihg the siize of the heart, and then flutter
the pen back and forth horizontally. Any vertical
motion that results is uninterclsting and can be ignored.
A path description, in sununary, defines dynamic
activity that consists of potentially continuous and
arbitrarily fine alterations of value. The reader should
not be misled by the choice of the word "path". What
is meant is a path, or sequenee of values, through an
arbitrary "continuous space", through a mathematical
continuum. One application or interpretation of this
path is the representation of a movement through the
location-spaee of an object, such as a figure's path
through a room. This interpretation, however, is not
the only possible one. Depending upon the picture
description capability of the system in which it is used,
and the algorithm which it drives, a path description
may determine changing locations, intensities, thicknesses,
densities, or texture gradients. For example, a pulsating
heart could be animated by varying either the size or
Figure IQ-A better display of the parametric curve. Symbols are
deposited at short, uniform intervals of tiIl,ltl
the intensity of a single heart shape.
Reference 28 presents a detailed discussion of the
relative strengths and weaknesses of wavefonns, pcurves, and other static and dynamic representations
of continuous movement. The discussion focuses on
their uses as inputs of dynamics and as visual feedback
to .the animator, their dimensionality, their role in
guiding temporal and spatial adjustments to existing
motions, their capacity for conceptual extensions, and
some practical problems (and solutions) that arise in
the sketching process. Furthermore, we describe four
kinds of editing and refining capabilities, operations
for:
1.
2.
3.
4.
scaling curves;
shaping and reshaping them;
algebraically and logically combining them; and,
performing pattern scanning, matching, and
transforming functions upon them.
Selection descriptions
Figure ll-The p.,curve corresponding to Figuresi-IO. The
dynamic display is compressed into a single static picture
containing nine selected frames
Consider the algorithm that selects an element of the
current frame from among members of a cel class. A
good example arises in the synthesis of different facial
expressions through the abstraction of discrete shapes
and positions of mouth, nose, eyeballs, and eyebrows.
One eel class could consist of the two members "eyebrows raised" and "eyebrows lowered." An animation
sequence may be achieved by a temporal concatenation
of selections from a cel class. A changing facial expression may be achieved by the parallel application of
282
Spring Joint Computer Conference, 1969
several such sequences of selections, one corresponding
to each facial component. In 'DINNERTEVIE,' this
technique was used to synthesize the movement of the
dog's legs, tail; head; and tongue.
A representation of the dynamic selection fronl a
finite set of alternative pictures is an example of the
second type of global dynamic description and is called
a selection description. The synthesis of selection descriptions is also aided by the use of pictorial representations, such as one consisting of a sequence of steps,
where the length of each step is an integer multiple of
frames, and the height is limited to transitions to and
from posit.ions on a discrete scale. Such pictures
appear at the top of Figures 15 and 20. Superposition
on a common time axis of pictures of several descriptions facilitates coordinating the counterpoint of the
parallel selection strands.
The use of the term "selection" implies that a mechanism chooses from among a designated set of alternatives. In the previous examples the alternatives are
eels, images to be introduced as components of frames
in a dynamic sequence. A more general view of a selection description regards it as a sequence of selectors,
functions which choose from a designated and finite
yet potentially denumerable set of alternatives. Depending upon the picture description capability of the
system in which it is used, and the algorithm which it
drives, a selection description may choose among alternatives that are subpictures, data, picture-generating algorithms, other global dynamic descriptions, pictorial events
or activities, or strands of dynamic activity. For example,
the dynamic selection from among alternative picturegenerating algorithms would be useful in a system
with discrete texture choices, where there is one algorithm capable of filling an arbitrary region with that
texture.
Further details may be found in reference 28, which
also discusses techniques for the definition and editing
of selection descriptions. These are conceptually similar to those used in the synthesis of path descriptions.
Rhythm descriptions
Rhythm descriptions consist of sequences of instants
of display time (frames), or intervals between frames.
They define patterns of triggering or pacing recurring
events or extended picture change. In this context it
is suggestive to think of a rhythm description as a
pulse train. Each pu]se may trigger the same action, Of,
as is discussed in reference 28, it may trigger one of
several act.ivities under the control of a selection description.
Rhythm descriptions fac~litate the achievement of coordination and synchrony among parallel strands of
dynamic activity. In this context it is suggestive to
think of a rhythm description as a sequence of event
:markers. The marking sequence may be defined with
respect to one pictorial subsequence, and then used to
guide the construction of another subsequence.
A rhythm description cannot by itself define picture
change; it can define a beat, a sequence of cues with
respect to which picture change is temporally organized and reorganized. Animators have sometimes used
metronomes as generators of rhythm descriptions. 2
Proper synchronization of a sound track to the visua1
part of a fihn is most critical to its success. 2
Hence, rhythm descriptions marking critical instants
of time play a key role in the synthesis and editing of
movement descriptions. For these operations a rhythm
description requires pictorial representation. In Figure
20 it is depicted both as a static pulse train and as a
sequence of event markers along the axis of movie
time. A direct and simple dynamic input, as we have
seen in 'DINNERTI:;\;IE', consists of tapping out the
rhythm on a push-button.
Dynamic hierarchies
It is easy to conceive of more complex and useful
couplings of global dynamic descriptions. Suppose, for
example, that a hop, a skip, and a jump have each
synthesized with the aid of several path and selection
descriptions. If the animator wishes to experiment with
varying dynamic patterns of hop, skip, and jump, he
should be able to define a selection description which
chooses among these three alternatives. This is equivalent to defining selections among sets of path and se1ection descriptions. Reference 28 discusses the use of
select·ion descriptions to establish arbitrary hierarchies
of structured dynamic behavior, and illustrates the
significance of this capability to the animator.
been
Exploratory studies in interactive computermediated animation
Three special-purpose picture-driven animation systems have been implemented on the ~J.I.T. Lincoln
Laboratory TX-2 computer. A conunon feature is that
each has a construction or editing mode, a playback or
viewing mode, and a fihning mode. In the first mode
the animator may begin work on new pictures and global dynamic descriptions, or may recall and continue
the construction of pictures and descriptions saved from
other sessions. Algorithms embedded in the systelnS
then compute TX-2 display files, in which sequences
of frames composed of points, lines, and conic sections
are encoded for use by the scopes.
These imag~ files are passed to the playback program,
Picture-Driven Animation
which simulates a variable-speed, bi-directional, video
tape recorder. The program nonnally sequences through
the display file representation of successive frames,
making each in turn visible for 1/24th of a second. One
useful option is that of automatic cycling or the simulation of a tape loop.
When the animator has prepared a satisfactory
sequence, he need no longer view it directly on the
scope; but may instead want to record it on fi1orn. A
pin-registered movie camera can be mounted in a lighttight box to a TX-2 scope. Its shutter is always open.
The filming program (a variant of the playback program) "paints" an image on the scope. After a sufficient
time interval to allow the decay of the phosphor,
approximately 1/5 of a second, a signal from the computer advances the camera. A return signal upon the
completion of the advance triggers the display of the
next frame. The camera can be operated on one scope
while we work at a tablet with another scope. Excellent
film quaJity, with high contrast and low jitter, can be
produced with the system.
The first two systems are very special-purpose.
ADAM allows one to animate a crude line-drawing
repre~mtation of a single human figurcl. EVE is an
Figure 12-This picture, "drawn" by the author, illustrates the
varietv of line and texture that may be included in a GE~ESYS
eel as·of December, 1968 Free-hand sketches are portrayed by
points spaced at an arbitrary, user-controlled density.
Straight lines can be solid or can be dotted, over the
same range of densities. Sections of circles, ellipses,
parabolas, and regular polygons may be
included. Arbitrary sub-pictures may be
copied, translated, rotated, and scaled
along two independent dimensions
283
exercise in abstract dynamic art, in which one can animate a set of points linked by "rubber-band" straight
lines. The animation technique in both cases is the
specific9.tion, via wavefonns and p-curves, of the seventeen path descriptions that define the temporal behavior
of the picture's seventeenc ontrolling continuous parameters. A lengthy discussion may be found in reference
28; we shall here content ourselves with three observa.j.:--~.
lJIUllt:5.
1. Clocked hand-drawn dynamics, or the dynamic
mimicking of animated behavior, produces lifelike, energetic movements, even if used in ADAM
to yield stick figure motions that are obviously
not physically realizable, and even if used in
EVE to yield abstract motions.
2. Slight modifications to a waveform result in
significant alterations to the character of an extended interval of a movement. For example,
ADAM's normal walk can be made into a jaunty
saunter by the addition of more bounce to the
vertical coordinate path description, or can be
made effeminate by increasing the scale of the
oscillations of the hip's rotational coordinate
path description.
Figure 13-A parametric curve, the final frame of a p-curve,
defining a movement that is life-like and energetic, smooth
and graceful. Observe how points cluster at pauses in
the motion
284
Spring Joint Computer Conference, 1969
3. Even in a system whose only intended application is cartooning, a dynamic mimick~ng capability must be augmented by an edit~ng capability,
for many motions cannot be mimicked or only so
with dijficulty, being purposeful exaggerations of
real movements.
Although GENESYS is also a special-purpose animation system, it is versatile enough to be used in the
generation of a broad class of dynamic images. The
term "generalized-cel," defined in reference 28, is a
generalization of the concept of cel class illustrated in
that its appearance in a given frame of the final dynamic
display is determined by the values of a set of associated
movement descriptions, both continuous and discrete.
The GENESYS animator may sketch, erase, copy,
transiate, rotate, and scale individual cels consisting
of points, straight lines, and conic sections. He may
sketch p-curves and dynamically tap rhythm descriptions. There are numerous tools for the manipulation
Figure 15--The four selection descriptiom; generate the
movements of the jaws, tail, legs, and body of the
crocodiless. Her translational motion is defined by the
two path descriptions below. The oscillator~T
waveform is the vertical coordinate; the
waveform sloping downward,
the horizontal coordinate
of static representations of dynamic descriptions.
Several individuals with varying degrees of artistic
skill and training in animation have constructed short
cartoon sequences with the aid of G ENESYS. Figures
12-20 illustrate some of these experiences.
Conclusion-the representation of dynamic informationThe concept of a picture
Thus the essence of picture-driven animation is:
Figure 14--The crocodiless cavorts across the screen, delighted
at her recent creation on the TX-2 console. The artist,
Miss Barbara Koppel of Chicago, had little animation
experience, no computer experience, a brief
introduction to GENESYS, and assistance in
using it from the author
1. that there exists a set of abstractions of dynamic
information, data sequences which drive algorithms to produce animated displays; and,
2. that these abstractions may in turn be modeled,
generated, and modified by static as well as
animated pictures, modeled in the sense that
the picture structure represents the data s~
quence, generated and modified in the sense
Picture-Driven Animation
Figure 16-The 1st, 7th, 13th, and 19th frames of the 'take-off'
of a bird are shown. The figure is superimposed on the parametric
curve which defines its path through space. Mrs. Johnson
has mimicked the motion by sketching the p-curve; the
bird then reproduces this movement. Observe the
switching among discrete shapes and positions
of its eye, wing. and feet.
Figure 17-All eels used by Mrs. Johnson in the animation of
Oopy-he tiaps his ear, winks, and Rticks out his tongue-are
shown superimposed on t.he left. To the right GENESYS is in
frame mode, in which the current state of a particular
frame is displayed. Also visible are "light-buttons"
representing eel classes (mouth, tongue, eye, ear,
brow). The animator may alter the current
frame, s"itehing the select.ion of a eel
from a class by pointing at it, or changing
it.s position by turning knobs located
under the scope. The underlying
movement descriptions are
automat.icaUy updated
by GENESYS
that the picture represents the process of synthesis as well.
The three kinds of descriptions constitute a rich,
expressive, intuitively meaningful vocabulary for dynamics.
Each type abstracts an important category of dynamic
behavior-flow and continuous change (path descrip-
285
Figure 18-A short cartoon-what the viewer sees: A man,
t.ripping blithely along, kicks a dog lying in his path. The dog
rises and trots off to the right (shown above). It then
returns, teeth bared (shown in Figure 19), and bites
the man. The man jumps and runs away. The dog
first follows, then returns once again to rest.
The duration of the sequence is
approximately 20 seconds
tions), switching and repetitive choice (selection descriptions), and rhythm and synchrony (rhythm
descriptions). The vocabulary is economical, flexible,
and general in the sense that it can characterize the
dynamic similarities that exist in seemingly diverse
animation sequences.
The use of dynamic descriptions couples picture
definition by sketching and by algorithm; it furthermore
allows both local (of the individual frame) and global
(for an interval_ of time) control over dynamics. We
have chosen to stress the latter and adopted the term
"global dynamic description", for it is the capacity
for global control that results uniquely from the use
of the computer as an animat.ion medIum. Yet a dynamic description is not only a representation over an
interval, but a sequence of single elements whose modification also provides local control over individual
frames. Both local and global control are vital to the
successful synthesis of movement. He who accidentally
crashes into a wall while running from the police is
going from the continuous to the discrete, from a global
motion to a local event. He who aims to scale the wall is
interpolating the continuous between the discrete,
adjusting the global to fit the constraints of the local.
The naturalness and power of the vocabulary is
increased by the ability to manipulate it in an interactive graphics environment. There exist, for each
kind of data sequence, static pictorial representations
286
Spring Joint Computer Conference, 1969
Figure 19-A short cartoon-how it was made: Mr Ephraim
Cohen of Orange, New Jersey, a mathematician and programmer
who is also a skilled caricaturist, completed the eels for his
cartoon one week-end afternoon at the TX-2. The system then
crashed, and he was forced to ret-qrn home. He sent through
t.hemail four selection descriptions, to choose eels from
the classeR "man's head", "man's legs", "dog's
head", and "dog's body", and two path
descriptions, to drive horizontally the
man and the dog. The author input the
dynamic descriptions, viewed the result,
and then refined the movie by
several iterations of editing
the descriptions and viewing
the sequence
such as the waveform which provide a global view of
and facilitate precision control of the temporal behavior
implied by the sequences. There exist, for each kind of
data sequence, methods of dynamic specification such
as the clocked sketching of parametric curves which
allow the animator's sense of time t.o be transmitted
directly through the medium of the computer into the
animated display.
We use the term "global dynamic description" and
the names of the three types somewhat loosely in
referring both to the underlying dynamic data sequences
and to their corresponding pictorial representations.
The imprecision is purposefli:l, for it is v~ry significant
that, in an interactive graphics envirdrJIDent, one can
easily traverse in either direction any leg of the triangle
{Dynamic Data Sequence, Static Pictorial Hepresentation, Dynamic Pictorial Representation}. What results
is an important plasticity in the representation of
dynamics. Characterizations of change can be manipulated (shifted, stretched, superimposed, ... ) within and
between the domains of the· static ana the dynamic.
Figure 20-A short cartoon-why it works: The dynamic
descriptions defining Mr. Cohen's cartoon as of January, 1969,
are shown above. The selection descriptions, from top to
bottom, belong to the man's head, the man's legs, the
dog's head, and the dog's body. There are 4, 8,
8, and 4 eels in each class, respectively.
The t.wo waveforms represent the
changes with time of the horizontal
coordinates of the man
and the dog
Several animation sequences can readily be related,
coordinated, or unified, regardless of whether or not
they ever occur concurrently. Dynamic behavior (data)
can readily be tran~ferred from one animation subsequenc'e (including the animator) to another, from one
representation or embodiment in a picture to
mode
another.
Our concept of a picture is a broad one, and purposely
so. For as we stress in reference 28, a computer-mediated
picture is not only what is visible but what is contained in its model in the computer system, And the
system, i.e., an interactive animation system, includes
not only disks and core but an animator and perhaps
an ongoing physics experiment as well as a tape-recorded speech. This system evolves continually through
real time. Occasioro..ally there occurs a particular reor-
of
Picture-Driven Animation
ganization of the system which results in the transfer
of information from the animator to the pictorial data
base, or in a computation on the data base which results
in a sequence of visual images (i.e., data directly convertihle by hardware into visual images). Thus, as we
have stressed before, the act of mimicking dynamics
is a (user-driven) dynamic picture. This unification of
the concepts of picture 'and action is important.
The greater is the number and generality of available models of pictures and of processes of picture
constructipn, the more flexible and powerful is the
animation system in its abHity to deal with dynamic
information. The design of a multi-purpose, open-ended
animation language that allows the aniinator hi:mself
to synthesize new models is outlined in reference 28.
Wi~h such a language one can describe arbitrary
action-picture interpreters that extract movement
descriptions from the animator's use of system devices
and transform them and existing static and dynamic
displays into new static and dynamic displays.
Finally, the use of dynamic descriptions helps establish a conceptual framework which facilitates efficient
use of the resources of the animation system: animator,
software, and hardware. For details, we again refer the
reader to reference 28.
Extensions, applications, implications
This paper is a pointer to a ::.vIarch, 1969, Ph.D.
dissertation,28 which includes the ma'terial contained
herein considerably expanded, some suggestions for
future research, and ....
1. There is a discussion of major difficulties in
implementing systems embodying these ideas,
with thoughts on the criteria supporting subsystems (both hardware and software) should
satisfy to facilitate interactive computer-mediated animation. The environment in which
current implementations exist is described in
another paper being delivered at this conference. 32
2. There is a lengthy outline of a proposed design
of an Animation and Picture Processing Language. APPL is a multi-purpose, open-ended
interactive animation programming language,
through which the animator may also exercise
algoritlunic control over a dynamic display.
The language will contain quasi-parallel flow
of program control, a data structure that is a
generalization of all hierarchic ordered data
representations, an extensible class of picture
descriptors, and a formalism which models the
aniniator's dynamics as it models the dynamics
of any picture, that is, as an integral component
287
of animated system behavior. A major design
goal is plasticity in the representation a (which includes cI>2 as a proper subset)
contains curve segments which may have inft.ection
points and which may cut themselves, as shown in
Figures 3 and 4 .
For display purposes, on a two-dimensional scope
face, it is enough always to work in P3, although for
many practical uses one wants to impose conditions on
the curve to be satisfied in Rn. In particular, one often
wishes to characterize a curve to be displayed in
two-dimensional projection by conditions expressed in
the projective space P", that is, in three-dimensional
homogeneous coordinates.
Iterative generation of curve
There are several methods for generating a curve,
depending upon its parametric representation. The
simplest is to generate a sequence of short line segments
between points on the curve corresponding to successive
values {to, t l , ~, ••• , t N } of the parameter t, with a fixed
difference 5 = l/N between tm and tm+l' Let x(t) =
X(t)/W(t) and yet) = Y(t)/W(t). Let pet) represent
any of the polynomials X(t), yet), or Wet) and let
Pn = P(tn ) = P(n5) forn = 0,1,2, ... ,~. In the usual
fashion we define two difference operators with respect
to the difference 5 as follows:
the forward difference: af(x) = f(x
+ 5)
- f(x)
the backward difference: \7f(x) = f(x) - f(x - 5)
am and \7n are defined recursively and aOf = \7°f = f.
Figure 2-.'\ closed curve
Note that P n + l - Pn = ap" = \7Pn+l and that if
,\Ve consider the family of curve segments
m
pet)
cI> = {V = Vet), 0 ~ t ~ I}
where each component of V is a polynomial in t. We
restrict the discussion to polynomials only because of
the simplicIty of polynomial evaluation. We consider
these curves in Rn; however our interest lies in pn, the
perspective space of dimension n - 1, generated from
Rn by dividing each component of V by the last
component.
Let cI>m be the family of curve segments defined by
polynomials of degree not exceeding m. The higher mis,
the more general is the family cI>m, but generating each
point on any curve is more complex. The greater
generality of cI>m for larger m enables the curve to satisfy
more conditions, but correspondingly requires more
conditions to wliquely define the curve. cI>2 includes
straight lines and conic sections only, Therefore if
=
L
akt k
then amp = \7mp = m!am for any
k=O
value of t. For the convenience of the presentation
we will let m = 3 in the following.
It is easy to see that
[ P~l] [1
aPn+1
a 2P n + 1
a3Pn+1
=
1 0
0 1 1
0 0 1
,0 0 0
or, in short, F n+l = S F
and
n
[ aP
p.n ]
a 2p,.,
,a3p" '
11
I P~l 1 [1
1
\7P n+1
= 0 1
\7 2P l.+1
0 0
... \73Pn +1 ...
,0 0
nrv~: 1
1
1
1
0 1
J
V2P n
_ \73P .. _
Fast Drawing of Curves for Computer Display
299
x
x
X·
Figure 4-Curve which crosses itself
or memory cells. The successive values {Pn } computed
by either method will be used in some fashion to display
the curve.
Let us factorize the matrices S and T to indicate the
two computational schemes:
S=['~0 0~ 1~ 1~].. [(~0 0~ 1~ 0~]I,.:
,0001,
.0001)
1 1 0 0]
0 1 0 0 = At Al Ao
; 0 0 1 0:
~O 0 0 1j
[
I.
x
Figure 3-Curve with inflection point
or, in short, Bn+1 = T Bn.
We have in mind placing the current values {Pn ,
aPn , ••• , amp,,} (or the {VkP,,}) in a set of fast registers
1 1
T
=~
~
[
I.'
!r [
0 0]1. :~ 01
01 01
.0 0 1
:.0 0 0
0 ]":"I
0
1)
1
1
:0
[I1 0
,,0
0
1
0
0
:
0
0
1
0
0]'
0
1:
.
1"
t.
= Ao Al At
where Ai is the operation of adding L\ i+l p to L\ ip
(or VHlp to Vip).
300
Spring Joint Computer Conference, 1969
We periorm these operations in the order Ao, AJ, A2
for forward differences as indicated by the composition
of operators F n+l = A2AIAoF n and in the opposite order
for backward differences.
There are only three additions involved in eitl}er of
these methods. However, there is a basic difference
between them. In the forward difference scheme, each
"new" value ~ ipn+l depends only on "old" values
~iP n, but in the backward difference scheme each "new"
value depends on the current value of the registers. It is
therefore possible to execute all the additions for the
forward difference scheme in parallel, taking only one
addition time for evaluating successive values of the
polynomials. This however requires much hard~are
(adders). The backward difference scheme is more
economical for sequential computation in software, or
in hardware with only one adder. By using extra logic
one can however overlap the three additions in the same
adder and execute them in not much more than one
addition time.
Basic curve form
For our purposes a curve in RN is a vector-valued
function from the real line R to the real vector space RN
of dimension N.* That is, a curve is an ordered N-tuple
of real functions (fl , f2' ... , fN)' Furthermore, let us
restrict the functions f i to be linear combinations of
some linearly independent set of functions, q, = [q,o, q,l,
, •• , CPM] and let the functions be defined over the
domain [0, 1].
M
Let fj(u) . =
L
AijCPi(U) where the {Aij} are con-
i-O
stants. Then a curve segment can be represented by a
unique (M + 1) X N real matrix A. A point V(n) on
the curve associated with a parameter u is given by
V(u)
of all matrices AH such that H(cp(u)AH) = H(cp(u)A);
it is clear that all the curves in RN specified by the
AHE H[A] will be mapped into the same-curve in RL and
there will thus be many representations of that curve,
Notice that although the original function space[f1, f2, . , " fN]-is a vector space of rank not exceeding
(NI + 1) its image under the mapping H is not necessarily of finite rank and we cannot in general represent
the resulting curve in RL by an expression of the form
W(u) = w(u) B where W(u) € RL, w(u) € RP and set
B a constant matrix of dimension P X L, w(u) a fixed
of basis functions, dependent only on Hand cP, The
mapping H will of course map the curve [fl, f2, ' , " Lv]
into a curve [gI, g2, ' , ., gL] where gi = Hi[fl, ' , ., f N],
where the {Hd are the components of the vector
function H.
We will usually choose the set of basis functions
[CPo, • , " q,M] to be the polynomials [u M, uM-I, , , " u2 ,
U, 1] or some other set of linearly independent polynomials of degree ::.\1. The functions fi will thus be the
real polynomials of degree :M or less. We will also
choose N to be dimension 3 or 4 and L to be dimension
2 or 3 depending on whether we are talking about two
or three dimensional curves, The mapping H will be
that used in making the transformation from homogeneous coordinates to ordinary coordinates, namely,
the projection obtained by dividing the first L components of the vector V (of dimension L + 1 = N)
by the L + 1st component to arrive at the L components
of the vector H(V), We thus identify the curve specified
by the form cpA and the resulting vector V(u) as
homogeneous coordinates of a curve v(u) in dimension one
less. The ma,ny-to-one property of the mapping H is
illustrated by the fact that two points in homogeneous
coordinates, P and Q, are equivalent if and only if
P = aQ for some non-zero a,
Thus we talk about curves of the form
[CPo(u), CPl(U), ... , CPM(U)] A = ep(u) A =
In this context we will say either that the matrix A
represents the curve, or, more pointedly, that the matrix
A is the curve.
If we have some mapping H:RN ~ RL from N
dimensional into L dimensional space then the image
v(u) = H(V(u» of the curve V lUlder the mapping will
be a curve v(u) in RL. The matrix A does not uniquely
represent the curve v(u), We can define the equiva1ence
class H[A] of a matrix A under the mapping as the set
* In other words, we only consider curves in
(explicit), rather than implicit, form,
&.
paramet.ri~
y=
bMu M
dMu M
+ bM~lUM-l + ' , , + blu + b o
+ dM_Iu M- + . , , + dIU + do
1
and optionally,
CMU M
dMu
+ CM_IU M- + . , , + CIU + Co
+ dM_IU - + . , , + dIU + do
1
z = ---------------------------M
MI
The value for each component of a point on the curve
is the ratio of two polynomials in the parameter u, In
theory and in practice we will first do some operations
on the curve in RN (or upon its representation as a
matrix) and only at the last moment before display
Fast Drawing of Curves for Computer Display
perform the mapping H : R,N ~ RL by doing the
division to remove the homogeneous coordinate. In
most cases the many-to-one property of H will not come
into play explicitly but only when we remember that
the points V(u) are expressed in homogeneous
coordinates.
If we have two sets of basis functions for the original
function space [f1, ... , Lv], say [1, ... ( s} x A
\
\
\
\
a(u) [SM
SM-l ••.
1] A = [UM
U M- 1 •••
\
1] S A
\
s=O
\
\
\
which holds if:
\
\
a(u) [SM
SM-l •••
1] = [UM u M -
1 •••
\
1] S .
\
\
\
\
If the rank of the null space of A is zero then it will be
a necessary condition as well. We will not at this time
pursue a further characterization of curves in tenus of
the null space of their associated matrix.
Under these conditions equating appropriate components of the vectors in the above equation gives:
1. for the last (1\'1
,,(u) 1
+
L_u
~
AU
(cua~u)d)M [[(au
~1
and
rLoJ~ 1
= R(u)
It is a polynomial of degree not exceeding
a~) =
;
=
[(:~! ~)" (:~! nw1_- \
= ~\UI
3. for the first component:
",(u) 8 M = ruM ... 1] S
Substituting in the original equation gives:
•••
1]
= rUM ... 1] S =
Q is a polynomial of degree not exceeding
s = Q/a(u) = Q(u)/P(u)
=
invariant transformation
Q au + b
s=P=cu+d·
a(u)
11srn
lJ
a\uI • = lU- ... 'J
8
6~hape
1
2. for the ~Ith component:
M
Figure
and at most NI zeros (including multiplicities) since the
polynomials Rand P are of degree not greater than ~1.
Thus Q/P has at most one zero and one pole and we
have
= ruM ... 1J S [ ; ] = P(u)
_
~
-!'-
Q(u)= cp(u) x B = cp(u) x 5 x A
1Bt) component,
P is a polynomial of degree not greater than :M. If
P = a(u) is a constant then s = u and S = kI for some
constant k, a trivial and uninteresting equality of
curves. Hence we assume P is not a constant.
f_\
~
+
b)M], [(au
+
b)M-l(CU
+ d)],
... , [(cu
+
d)M]]
Each component of ruM ... 1] S is a polynomial of
degree not exceeding M in u. The components on the
right hand side above must thus be the same polynomials. Hence a(u) = e(cu + d)M, where e is a
constant, and by inspection the component Sij of the
matrix S is the coefficient of U M- i in the expansion of
e(au + b)M-i(cu + d)i.
Bypassing the algebra,
:~\,I
and
[~]"
The expression R/P = [Q/P]M has at most
Sij
=e
t
k=O
:vr poles
aM -
i - i +k
bi-
k
c i-
k
dk
(
~-~
_V"-t-1+k
where we use the convention that
k are outside of the range 0 ~ k :;; j.
a)
)
(j)
11:
o when
j,
Fast Drawing of Curves for Computer Display
The matrix S for:U = 2 is
In fact, in general we have
dp
ds dp
du = du ds
and the matrix for M = 3 is
a 2c
2abc + a2 d
b2c + 2abd
b2d
ac2
bc2 + 2acd
2bcd + ad2
bd2
Typically we will want to use the reparameterization
matrix S to change the amount (extent) of a given
curve that is drawn and to alter the rate at which the
moving vector [u M • • • 1] S A traverses the curve. These
variables can be specified by setting
1. s(O) = a
2. s(l) = /3
curve A at which the new curve B begins. /3 is the value
of the parameter s on A at which the curve Bends. r2 is
a ratio of derivatives; the significance of r will be shown
shortly. It is easily .verified that the ratio
CU2
CUI
+ d )~ ~
+d
The product of the magnitudes of the velocity vectors
at the ends of the new curve B is thus (f3 - a)2 times the
product of the magnitudes of the velocity vectors at the
corresponding points s = a, S = {3 of the origi..'rJ.al
curve A. This product thus remains constant for all
similar curves covering the same interval (a, f3) of A.
It is in any case independent of the rate parameter r.
Notice that if r < 0 the new curve will not completely
overlap the old curve in the range 0 ~ u ~ 1, 0 ~ s ~ 1
although over the full line - 00 < u < + 00, - 00 <
. s < + 00 the two curves will be identical. In particular,
at the value u = r/(r - 1), s(u) = ± 00, definitely
outside the domain of the original curve v(s). Thus, for
example, if the matrix A draws half a circle, the matrix
S A will draw the other half in the same direction
if a = 1, /3 = 0, r = -1. (See Figure 7 for an example
of the use of a continuation matrix.)
[-~ -;]
2
a is the value of the parameter s on the original
=(
(f3 -a )r
dp
[(1 - r)u + r]2 ds
For M d 2 this matrix s(l, 0, -1) is
3. s'(O) = r2
s'(1)
s' (Ul)
S'(112)
-3
1
0
-
Substituting the above conditions into s = (au
(cu + d) we solve for a, b, c, d:
the curve A
+
~
b) /
a=/3-ar
b = ar
c = 1- r
303
(f3 - ar)u + ar
ors = ....:...,...-----,,;--(1 - r)u + r
d = r
using the arbitrary condition c + d = 1 to remove the
extra degree of freedom introduced by the homogeneous
form of the function s. The parameter e will allow an
absolute adjustment of the homogeneous coordinate
system, if that is desired.
The velocity vector dv/ds at the beginning (u = 0,
s = a) will be multiplied by the factor (/3 - a)/r and at
the end (u = 1, s = /3) by (f3 - a)r.
the curve S x A
Figure 7-Continuation of a curve
304
Spring Joint Computer Conference, 1969
and for 1'1 = 3 it is
r
1
'
~
_~ 1
2
4
-3
-8
3
4
5
-l~
-1
-1
-1
-1
[-3
J
is non-singular since the basis functions cI>(u) are by
definition four linearly independent polynomials of
degree 3. Define
M =
If we have a curve v(u) = H[iF AT] represented by a
matrix AT for some other basis function iF = rUM U M-l
... 1] T then the reparameterization matrix ST for this
basis will be given by the similarity transformation
ST = T-l STand the curve matrix after reparameterization will be T-l STAT'
:,' cp(O) ]i
cp(l) \
[ cp'(O) ,
, cp'(1) ,
i
A=M
Endpoint-Derivative form
In the previous sections we have been talking about
curves of arbitrary degree; in this section we will be
concerned only with curves of degree m = 3. Let hv = V
denote the homogeneous coordinates of a point in RN,
that is, let h = V N, V = V/VN = V/h where v is a
vector of the form [VI V2 ... VN-l 1]. Then the equation
of a curve is given parametrically by
Vo = ho Vo
d(hv)
Vo = -du
V(u) = h(u) v(u) = cp(u)A
where cp(u) are appropriate 1\1
Let
Lv~J
We now write
I
dimensional basis functions. The curve in RN-l = RL is
obtained by taking the first L components of the vector
v(u); that is, by dividing out the homogeneous coordinate h(u) from the vector h(u)v(u) and dropping the
last component.
[ ~Vol
I
I
v_o
= ho Vo
+ ho Vo
I
where v~, v~ are the derivatives with respect to the
parameter u and where ho, hI, ~, h~ are meaningful only
in homogeneous coordinates. Notice that the last
component of v~ and v~ is O.
Thus
V(0)
=
Vo
["
......u
V(l) = VI
V'(O) = dV(u)
du
I
=
A=l\1:~
V~
,0
u-o
0
hI
0
h~
OJ [vo]
0
0 o
ho o
0 hI'
VI :
V~ i
, V~
V'(l) = VI
The curve is given by
then we have
Vol
v~
=
r
Vo
L
v,I.J
[CP(O)
cp(l)
cp'(O)
A..'/l \
'Y \-'-)
1
I/>(u) A = I/>(u) M :
[
,
A
.J
One can show that the square matrix
cp(O) ]. .;
cp(l)
cp' (0) ,
[
.. ¢'(l)
ho
].
,
~ h: ho
hI
hI
[~]
We can perform the multiplication cI>(u) lVf separately
to define a new set of basis polynomials [F 0 F I Go G l ] = cp
~1 with transformation of basis matrix :\,1 itself. * We
observe that
* This
notation is borrowed freely from S. A. Coons.7.8
Fast Drawing of Curves for Conlputer Display
305
is especially simple, although for a very special basis
function constructed specifically for the particular set
of homogeneous coordinates ho, hI, ~,. h~. This form
shows that a point on the curve V(u) is always a linear
combination of the vectors Yo, VI, V~, v~.
=
l\tT-Il\/f
~~
~~
=
1 0 0
0 1 0
0 0 1
[
000
0]
0
0
1
With these basis functions, a curve can always be
represented by a matrix AM of the form
since it is given by the equation
We will sometimes write this endpoint-derivative form
as
It will also prove useful to rewrite it in the form
Curve specification
In the previous section we have characterized a
rational parametric cubic polynomial curve in terms of
endpoints-v~, v~-and tangent vectors at the endpoints-yo, vI-with four remaining degrees of freedom,
ho, hI, h~, h~. In this section we investigate several ways
of computing the numbers ho, hI, ~, h~ in order to
completely specify the curve from geometric consideration. (See Figure 8). Although some or all of these
results may be inappropriate for a particular application
the techniques used indicate the generality of the curve
formulation and what we believe to be the proper way
to attack the problem.
Let us require the curve to pass through the point vc
at the value U c of the parameter. We have
Vc
=
or in standard form as
We can solve Vc = hg: v for hg: (and hence for h,
since cf is non -singular for any 0 < lie < 1) if and only
if Vc belongs to the range of v. In R3 the geometrical
meaning of this condition is that if the curve is planar,
Ve must be in the same plane, or, if the curve is linear,
Ve must be on the same line. If the curve is' really
three-dimensional then v will have full rank and we
can solve directly for
where now the matrix
In R2 the equation Ve = hg: v is indeterminate since
we have three equations and four unknowns. If Ve is in
the range of v we can impose an additional condition. *
One convenient such condition is to specify that the
slope at Ve be given by the ratio x' elY' c = dx/dy.
V(u)
* Vc will not be in the range of 11 if and only it V~, v~ and Vo - Vl
are collinear and Vc - Vl is not on the same line. This means
that the tangents at each endpoint point to the other end and
Vc is not on the line between the two endpoints.
306
Spring Joint Computer Conference, 1969
or, rearranging,
vo-ve]
VI-V e
,
=
Vo,
[
VI
Denote the left side of the above by Q. Since we are
only concerned with the slope at Ve, we can extract the
first and second components by a post-multiplication
and obtain the ratio
whence
Figure R-8pecifying the curve
Taking derivatives with respect to u we have
u
=
Ue
because we have let he = 1. (ve = [Xc Yc 1]). Since the
third component of v~, v~, v~ is 0 we can solve for
and thus
If we adjoin this single equation to the original equation
for the curve passing t.hrough the point Vc we have
If the matrix is invertible, we can solve for ho, hI, h~,
h~ and determine a curve passing through a specified
point V c with a given slope x~/y~ with given endpoints
vo, VI and tangent vectors V~, V~ at those endpoints. As
with the three dimensional case above we could
characterize this problem in somewhat more generality
in terms of the range of the appropriate matrices, but we
will not do so since the conditions are not simple
enough to be interesting.
We could in the previous examples have just as easily
required the curve to pass through four non-planar
points Va, V(3, VI" Va at different values a, {3, 'Y, 0 of the
parameter.
Fast Drawing of Curves for Computer Display
\tVe would have
or
f,.'
A
=
¢(a)
Tl
Ii ¢~(j~
C/>Vy) J
L'" ¢(8)
Then let' us ask that the curve pass through v c at
u
=
307
which 'Can be solved directly for [ha h,3 hI' hal if the
matrix is non-singular, that is, if the four points are
non -planar. In this way we have asked the threedimensional curve to pass through five specific points at
. five specific values of the parameter. Similar results
could be derived in two dimensions.
REFERENCES
1 R F SPROULL I E SUTHERLAND
A clipping divider
Proc F J C C 1968
2 I E SUTHERLAND
A head-mounted three dimensional display
Ut::
::3
Proc F J C C 1968
L G ROBERTS
Homogeneous matrix representation and manipulation of
n-dimensional constructs
The Computer Display Review Adams Associates May 1965
4 H F BAKER
Principles of ge01netry .
where now we have let
1\1 =
6 Vol., Cambridge University Press Cambridge 1922
5 R M WINGER
¢(a)]
¢({j) ' ,
[ ¢('Y)
, ¢(lJ) _
If we define ¢(u c) 1\1 = [Fo Fl F2 F 3] we have after
rearranging
+
An introduction to projective gemnetry
D C Heath and Co Boston 1923
6 G BIRKHOFF S MACLANE
A survey of modern algebra
Macmillan New York 1965
7 S A COONS B HERZOG
Surfaces for computer-aided aircrajt design
Presented at AIAA 4th Annual Meeting and Technica
Display Anaheim California October 1967 American Inst
Aeronautics and Astronautics, New York
8 S A COONS
Surfaces for computer-aided design of space forrns
Project MAC Report MAC-TR-41 MIT June 1967
A class of surfaces for computer display*
by THEODORE lVL P. LEE**
Harvard University
Cambridge, Massachusetts
INTRODUCTION
conditions. The rest of the paper contains primarily
mathematical techniques for manipulating the surfaces.
This paper describes the mathematical formulation of a
class of three-dimensional surfaces parametrically
represented for efficient computer display. The degrees
of freedom in the representation are such as to provide a
rich variety of surfaces with convenient parameters for
manipulation and constraint satisfaction. Historically
this work began as an investigation of the properties of
rational parametric cubics, a class of curves well-suited
to the Harvard three-dimensional display.l.2 The desire
to represent curvilinear surfaces in terms of these curves
and an introduction to the Coons' surface formulation 3
were sufficient to suggest the approach discussed here.
The particular advantages of this approach with
respect to projective transformations and rapid iterative
display did not become apparent until later, although
they may be its most attractive features. The ability to
truly and simply represent such classic surfaces as the
sphere and torus, although a desired goal, was not
demonstrated until even later.
The paper begins with an introduction to homogeneous coordinate geometry, a topic now out of favor
in the general college curriculum. I apologize to those
who may have seen this material before, but it is
necessary for a proper understanding of the results
presented, especially those dealing with continuity
Notation
We will be talking about surfaces, represented as
tensors, curves, represented as matrices, or points,
represented as either three dimensional (ordinary coordinates) or four dimensional (homogeneous coordinates) vectors. A vector, usually a point in homogeneous
coordinates, will always be denoted by boldface type,
for example, V. Where relevant, a four dimensional
vector will be represented by an upper-case letter and a
three dimensional vector by a lower-case letter. Points
or curves may be obtained as part of a higher order
entity or as separate entities.
Subscripts will be used to denote either components
of the array (tensor, matrix, or vector) or to indicate
partial derivatives with respect to the parameters.
Components of vectors will not be in boldface
although vector components of a matrix will, for
example, the vector Ai of the matrix Aij. Integer
subscripts-i, }, k-will be used for components in some
cases while the symbols hz, 1a1/' laz, Ia will be used when it
is ~esirable to emphasize the spatial coordinates. The
SUbscripts u, " will naturally refer to the partial deriva-
.
a a
tlVes au' av' The components of a point in three
dimensions are indicated by subscripts z~ 1/, z-for
example, pz. This implies either true three dimensional
data or a division to remove the homogeneous scale
factor.
When a tensor describing a surface is used without'
any subscripts for components it is to be treated not as
an array of scalars but rather as a matrix whose elements are vectors. Multiplication of such a matrix of
vectors by a matrix of scalars is to be interpreted in the
standard way, with the summation being a vector swn
* The research reported here was performed at Harvard University and supported in part by the Advanced Research.Projects
Agency (ARPA) of the Department of Defense under contract
SD-265 with Harvard University, under contract AF 30(602)4277 with the University of Utah, by the Office of Naval Research
under contract ONR 1866(16) with Harvard University, and
by a long standing agreement between Bell Telephone Laboratories and the Harvard Computation Laboratory. The author is
a. National Science Foundation graduate fellow.
** At the Aiken Computation Laboratory, of the Division of
Engineering and Applied Physics.
309
310
Spring Joint Computer Conference, 1969
and the individual multiplications being the product of
a scalar and a vector.
When convenient, the standard convention of summing over repeated indices will be used, with the
proviso that indices appearing on both sides of an
equation will not be summed but indicate a running
index. Such summation and running indices will take on
the values 0, 1, 2, 3 for virtually all of the paper.
A curve, S(u, v), u = a, a = constant, 0 ::; v ::; 1,
ona surface S(u, v) ·will be denoted by Su=a or by Sail
for brevity. A point, S(u, v), u = a, v = b, on the
surface will be denoted by Su=a, lI=b or by Sab. In most
cases it does not matter whether such notation is taken
to represent the object (surface, curve, or point) itself
or the array describing the object; context should make
the situation clear. The geometric and mathematical
bases in which such an array represents an object will
either be irrelevant or clearly specified.
H omogtmeOU8 coordinates
Taking the lead from the 19th century projective
geometrists,4 computer display programmers have recently adopted the use of a homogtmeOU8 co01"dinate
representation of geometrical data.1) This section summarizes a few of the definitions, conventions and
formulae in homogeneous analy-tic projective geometry
needed for an understanding of the surface formulation.
Most of this material has been printed elsewhere, but is
not readily available.6.7
Point: A point (in three dimensions) is represented
by a non-zero vector of four components. Two points P,
Q are to be regarded as the same point if and only if
they are linearly dependent; that is, if and only if there
exists a non-zero constant a such that P = aQ. The
ordinary three dimensional point [x, y, z] can and will
be represented in the homogeneous form as [x, y, z, 1];
hence any point [a, b, c, d], d ¢ 0, is equivalent to the
three dimensional point [aid, bid, c/d]. This representation will be indicated by the notation [hx, hy, hz, h] =
hv = h[x y z 1], v = [x y z 1] for the homogeneous
coordinates of a point V, where by implication we take
the quotients hx/h, hy Ih, hz/h to find the three
dimensional coordinates. The assumption is that once a
point-[hx, hy, hz, h]-has been obtained, somethinghardware or software--will perform the necessary
division by the homogeneous coordinate. In particular,
whenever we talk about a point to be displayed, this
division must be performed.
Line: Three points P, Q, R are collinear if and only
if they are linearly dependent. The set of points P on
the line through two points Q, R can thus be generated
parametrically by P = aQ + (1 - a)R, or, in full
generality, by P = aQ + tJR, a, tJ not both zero. Two
points on this line, PI = alQ + tJIR and P 2 = a2Q +
tJ2R are equivalent if and only if the vectors [aI, tJI],
[a2, tJ2] are linearly dependent, that is, in this case,
proportional.
Plane: Four points P, Q, R, S are coplanar if and
only if they are linearly dependent. Hence the plane
through three points P, Q, R is spanned by aP tJQ +
'Y R, a, tJ, 'Y not all zero. Furthermore, for the dependence
aP + tJQ + 'YR + as = 0 to hold, we must have
[P Q R S] = 0, or, expanding by minors on the fourth
column, S·T = 0 (vector dot product) where
+
The relation S· T = 0 is thus the equation of a plane
and the vector T represents the plane. Among many
results it can be shown that two planes, T, U are
equivalent if and only if the vectors T, U are proportional.
Transformations
In ordinary three space, a non-singular matrix
transformation of the form Q; = PiT., (T a 3 X 3
matrix) is an affine transformation, producing only
rotation and scaling. In the special three dimensional
space of homogeneous coordinates, such a transformation (where T is now 4 X 4) is called a projective
transformation which in addition to rotation and scaling
performs translation and a perspective transformation,
hence its applicability to computer graphics. This
transformation is derived as follows: (see Figure 1).
Let an observer be at the origin 0 of a coordinate
system and let a display screen S of size 2 scope units by
2 scope units be at position z = cota, where a is half the
angle subtended by the screen. ~he x coordinate x, of
the intersection with the screen of a ray from a point P
to the observer-perspective projection from 0 of P
onto S-is
Similarly,
hy
y, = - cota
hz
Class of Surfaces for Computer Display
311
and let us define
Z. -
h
hz
Then the point represented by
p.
[hx/hz cota, hy1hz cota, h/hz, 1]
=
y
o
gives as its x and y coordinates the location on the
screen at which to draw the perspective projection of the
point P and as its z coordinate a value monotonically
related to distance, suitable for intensity modulation.
P 8 is equivalent to (hz) P 8 = [hx cota, hy cota, h, hz]
= [hx, hy, hz, h]
[cot co~ ~
'" 0
0
o~ ]:
1
and we have a matrix which performs a perspective
projection on a point represented in homogeneous
coordinates.
Figure I-Perspective projection
Surface equation
Let Bijk be a 4 X 4 X 4 array, then the components
of a point on a surface are given by a vector function,
P(u, v), of two parameters, the two degrees of freedom
on the surface, as
Translation is achieved by a matrix of the form
, 1
:0
o
!~,
o
[
1
o
o
Yt
Zt
This expression may be written in matrix notation as
1
and rotation by a matrix of the form
~
[-0
O·
!J
where R is an ordinary three-dimensional rotation
matrix.
Typically, several such matrices-rotation, translation,
and projection-will be applied in sequence to arrive at
a single compound transformation expressed as the
matrix product of the separate matrices.
Observe that given any matrix, M, which performs
some transformation, a matrix aM, a '¢ 0, performs the
same transformation, since a(P X M) = P X alVI
implies P X M and P X alVI are proportional, for any
point P. In particular, the identity transformation
becomes aI, a ~ o.
P'u = [etcetera]
Ph ..;, [etcetera]
These expressions may also be written without subscripts in the following fashion to indicate all four
equations, the implication being that B is a m~trix
whose components are vectors:
P(u, v) = [u8 u2 U 1] B [•.
~].
.1 ,
312
Spring Joint Computer Conference, 1969
Endpoint-derivative formulation
00
A =
Following Coons closely, let F o, FI, Go, G 1 be functions
of one variable such that
F ,(j) = 5} ; G ,(j) = 0
}
i, j = 0, 1
[
10
oou
01
11
01,..
, lOu
11u
where the notation, from Coons, is exemplified by
F~(j) = 0 ; G~(j) = 5}
111111 = ap(u, v)
au av
Then we can define a surface as
=~
u_l
_ A':,'
ap(u, v)1
au
Iu-o ,,-1
If we insist on F i, G i bejng cubic polynomials, the
above conditions define them completely as
Note well that these derivatives refer to each component
of the homogeneous coordinate four-vector; for example,
[Fo(u) F 1 (u) Go(u) G1 (u)] =
2
[Ul u 2
-3
0
u 1]
[,
-2
3
1
o
o
1
0
The 4 X 4 matrix above occurs often and has become
identified with the symbol ~1, for "magic" matrix. The
tensor A in the above equation is thus the representation of a surface using the basis functions F 0, fi\, Go,
and GI.
We can convert between the two forms of representation thus far introduced by means of the identities
A =
:\1-1
B }1-1T
since [Fo F I Go GIl = [u 3 u2 U 1] 1\1. In these cases the
matrix multiplication implied is that obtained by taking
each slice of the tensors separately, as B,,;o; = lVl Ah;o; ~IT
and so forth.
(Or, we could write it as
Because of the definition of the F i, G i functions, the
components of A relate directly to various partial
derivatives of the surface function P(u, v) as indicated
below:
P = a(h(u, v)p(u, v» = ah p
1
-2
u
au
au
+
h ap
au
and we must solve for
ap -_
au
Pu
~ phu , p = [x y z 1], aap = [x' y' z' 0]
u
to obtain the partial derivatives of the three dimensional components, x(u, v), y(u, v) and z(u, v).
Curves associated with the surface
By fixing one parameter a curve in the surface is
traced by letting the other parameter range over the
interval (0, 1).
For example, let v = b, then
P(u, b) = [u 3 u2 u 1] B [
F1
=
1
[u' u' u 1] Au.
J
where
The matrix Aub represents the rational parametric cubic
given by the above expression. The properties of these
curves are discu~sed in a companion paper.s
Ciass of Surfaces for Computer Display
The curves P(O, v), P(l, v), P(u, 0), P(u, 1) are the
boundary curves of the surface; in the shorthand
notation they are denoted by Ov, lv, uO, ul. We will
denote the matrix describing a curve for u = constant
by
313
which is achieved by simple shifts and additions, and
similarly for "(i (i). The summations over i and j are
commutative. If we are drawing the curves P(u, n,,()
we first compute a 4 X 4 matrix Cik = Cijk "(1 (j) for
each curve and then iterate upon it to compute the
successive points Pk(mo, n,,() = (r) Oi Cik on the curve.
A01l = ([a 3 a2 a 1] B)T
Transformations of the surface
so that the curve is given by an expression of the
standard form,
pea, v) = [v 3 v 2 V
1] Aov .
For computer display of the surface we generate the
family of curves
In the previous sections the coordinates of a point
P(u, v) on the surface have been defined by expressions
of the form Pk(u, v) = Ui(u) Sijk Vj(v) where U and V
are vector-valued functions of the parameters. Let T
be a projective transformation to be applied to the
surface at each point P and let pi be the transformed
point. Then we have
i , 1. = 0,1, ... , m
P ub , b = m
or the family
P av , a = -j .
,J = 0,1, ... , n
n
or both. The continuous curve Pub will be approximated
by a series of chords
and P av by the chords
Pavj Pavi+l , Vj
=
~ ,j =
0, 1, ... , t - 1 .
where the surface tensor Sijk is replaced by a transformed tensor S~it = Sijk Tkl. This derived tensor, S~il
will generate the transformed surface, without the need
to transform each point to be displayed. In other words,
the sixteen vectors 8 1j = [SijO Sijl Sij2 Sij3] transform in
the same fashion as points on the surface and can be
regarded as a set of sixteen points which define the
surface. Notice, of course, that any transformationincluding the identity transformation aI-of the surface
must be applied identically to all sixteen 8 ij • These
properties are obviously what allow us the right to call
the S ijk array a tensor.
Iterative display of surface
Reparameterization
The successive chords of a curve and the successive
curves of a family on the surface are computed using
Cohen's finite difference scheme.8 Without going into
details, we compute
As with a curve matrix, the tensor describing a surface
can be reparameterized to
for an appropriate tensor C dependent on the surface
and the particular family of curves to be generated. The
multiplication by (r) Oi is equivalent to multiplication
by the matrix
o o
1
o
o 1
o o
1. change the rate at which the surface is traversed
by the parameters and to
2. display other (smaller or larger) portions of the
surface with the same parameter range, 0 ~ u
~ 1, 0 ~ v ~ 1.
In the case of surfaces, 1 is particularly important
for such a reparameterization changes the appearance
of the curvilinear net used to display the surface, by
changing the density of contour lines non-uniformly,
whereas with curves it affects only the accuracy with
which the chords approximate the curve.
For each of the basis functions used so far, [u 8 u2 u 1],
[F. F 1 Go GI ] or [(~) (~)o (;)02 (~)o31, there exists a
314
Spring Joint Computer Conference, 1969
reparameterization matrix S(a, (3, r), a function of
three parameters a, {3, and r which will
1. map u = 0 to u = a
2. map u = 1 to u = {3
3. change the parameter rate by a factor r.
Two of these reparameterization matrices, Sea, (3, r)
and S( 'j', 0, s) can be applied to a surface tensor T to
compute a new surface tensor T' as
in which" the parameterization in both u and v has
been altered.
A shape-invariant transformation of the form S(O, 1, r)
combined with the identity aI has the property
of allowing us to adjust the fourth homogeneous
coordinate h at three of the corner points at will; in
particular, we could arbitrarily assign hOO = hOl =
h lo = 1 without any loss of generality in the class of
surfaces represented. Correspondingly, if we are given a
surface constrained in this fashion we can reparameterize
it so as to arrive at a more satisfactory rate of display.
three will be used in specifying the parameterizations in
u and v and in assigning an absolute homogeneous scale
to the surface.
At this point we have filled in the tensor as sho"..-n in
Figure 2. (for example, 8000 =
= A~ ; 8302 =
(P~l)hll = A~) The remaining sixteen components can
be determined from any sixteen independent conditions;
an easy set would be to specify put> at each of the four
corners and to specify a point ps through which the
surface must pass at some specified value of the
parameters, say u = 1/2, v = 1/2. With these conditions
we can solve for (Ph)U., at the four corners with one
degree of freedom left, say to speciiy the h value
reached at the center point P s or some other appropriate
geometrical constraint.
Instead of specifyhlg put> directly, one could specify
p,:
op
ap
au
av
(see Figure 3)
U_C
u_d
as desired outward tangents from the boundary curves,
solving for the mixed partial derivatives. In all the
above we are talking about conditions expressed in
Constructing the surface
The sections above describe some of the properties
of a given surface and are thus analytical; the usual
question, however, is the constructive problem of
generating a surface from external conditions. This and
the following two sections sketch some partial solutions
that are being investigated.
Suppose we are given the four bowldary curves of a
surface, specified by matrices AO",' Ah, A uO, A ul in
endpoint-derivative form. By the geometrical closure
of the curve segments bounding the surface these
matrices are guaranteed to represent the same corner
points P(O, 0), P(O, 1), P(l, 0) and P(l, 1) at the
intersections of the generated boundary ClR'ves. This
representation is, however, in homogeneous coordinates
and we have no guarantee that the four-dimensional
vectors given by the matrices are the same. (In other
words, A°.,(v = 0) is proportional to but not necessarily
equal to AuO(u = 0),) Usin.g the reparameterization
mentioned in the previous section we can however
arbitrarily assign absolute values to the fourth homogeneous coordinate h at all four corners, adjusting the
curve matrices A°." Ah, A uo, A 1£1 so that the endpoints
will now be represented by identical vectors.
In assigning the four values of h only one degree of
freedom will affect the shape of the surface. The other
..
pOo
..
plO
..
..
pOI
pll
..
pOo
v
..
pOI
V
..
pll
V
..
pOI
U
..
p'O
U
..
pll
U
Figure 2-Coni;t.ruct.ing the surface from boundary curves
Olass of Surfaces for Computer Display
315
terms of three-dimensional points or vectors; the
determination of the homogeneous coordinate representation for each such vector is done by specifying
other conditions, namely, the point ps.
u=o
v=1
Product surfaces and surfaces of revolution
A convenient way to specify certain surfaces is as the
"product" of two curves; if the curves are chosen
appropriateiy, a surface of revoiution resuits. Let P(u)
and Q(u) be two curves; then the i'th component of a
surface S can be defined as
If we let
Pi = j(u) Aii ,
where A, B are the appropriate matrices for the basis
functions , then Si = ;(U)Aii Bik k(V) and we can
identify
aP
av
u= a
v =1
as the tensor representing the surface.
If one of the curves P(u) or Q(v) is planar, say P(u),
we prove that all curves of the corresponding family,
S(u, a), are planar:
Let A be the vector representing the plane of P(u);
define a vector B, component by component, as
IV
Figure 3-Derivative vectors as conditions on the surface
as conditions on the curves. The surface, in homogeneous
coordinates, is
Then
h = Ph Qn
where now the summation convention holds, and the
curve S(u, a) lies in the plane B(a). Hence, if both
curves P(u) , Q(v) are planar, then all the constant
parameter contours are plane sections of the surface.
In particular, let P(u) be a curve in the x = y plane
and let Q(v) be a portion of a circle with center [0, 0, 1]
in the z = 1 plane. Then we have, in homogeneous
coordinates,
hx = Ph P:e Qh Q:e
hy = Ph P tI Qh Q" = Ph P:e Qh QJI
hz = Ph P z Qn Qz = Ph P z Qh
or, in regular coordinates,
Ph P:e = Ph P"
z
= p.
316
Spring Joint Computer Conference, 1969
and we have
2. Everywhere along B the two surfaces have a
common tangent plane. That is, the surfaces are
continuous and have a continuous unit normal
vector.
The first requirements are met by forcing
or
S~l to be proportional to T~
and also, z = P z, giving a family of circles about the z
axis.
All plane sections perpendicular to the z axis will be
circles and all plane sections passing through the z axis
will have the same shape as the original curve P(u).
Hence, S is part of a surface of revolution constructed
by rotatiL'1g the curve P(u) about the z axis.
Continuity conditions
In constructing an object from an assemblage of
elementary surface patches it is often necessary to
enforce certain degrees of continuity at the jmlCtion
between two patches. In particular, suppose Sand T
are two surfaces meeting in the common boundary
curve B, with the other boundaries as indicated in
Figure 4. Suppose we wish the following constraints to
be satisfied:
1. The Ov, Iv boundaries have a continuous tangent
direction at P and Q. That is, the Ov, 1v boundary
curves are continuous and have a continuous
tangent line.
and
S!l to be proportional to T!O ,
conditions obtained from the work on rational cubics.
The second constraint is more involved, since it talks
about tangent plfu"1es. 'Vithout deriving it, I state the
result that a point P is on the tangent plane of a
surface F at the point F(u, v) if and only if the
determinant
I P F(u, v) F u(u, v) F lI (u, v) I = 0
From this, the relation that tangent planes to surfaces S
and T coincide can be expressed as
where the vectors are evaluated at the appropriate
values of the parameters. Since the boundary curve
(a rational cubic) is shared we can adjust the parameterization in u such that
SuI = TuO and hence that S:l = T:O
The first two determinants will then vanish, so we only
consider the third.
In general we cannot expect SlI to bear any relation to
T or T u so the vanishing of the third determinant
requires Sv to be proportional to T lI . But this relation is
precisely the same as asking that the function SlI(u) ,
which represents a curve, be the same as the curve
TlI(u) , regarding the derivatives as homogeneous coordinates of points in three dimensions. Since we have
already adjusted the parameterizations in u of the two
surfaces to be equal along the common boundary, the
third determinant will vanish if and only if
S,,(u) = kTlI (u)
for an arbitrary proportionality constant k, and thus
the conditions on the tensors are
Figure 4-Adjacent smface continuity conditions
Class of Surfaces for Computer Display
S: = kT:'
St!! =
kT~
Please notice that, as usual, in all the above we are
talking about homogeneous coordinate vectors and that
an equation of the form S~l = kT~ does not constrain
the tangent vectors in ordinary three dimensions to be
equal. In fact, we have
(Sh s)v = (Sh)v s
+
Sh Sv = k(Th t)v =
k(Th)v t
+ kTh tv
where s = [x y z 1] and similarly for t. Now s = t but
in general Sh ¢ T h, so we have
or
The fourth coordinate of this vector equation gives
and thus
or
Although there is tangent vector direction continuity
across the boundary, there is an arbitrary magnitude
discontinuity, controlled by the constant k.
Problems for further research
The following paragraphs outline a few of the
important questions open for future research. I cover
here only the more mathematical questions; clearly the
problems associated with organizing these results into
an effective, human-engineered system for computer
aided design must be answered at some time.
Since a boundary curve can be degenerate, patches
with only two or three sides are possible. Such patches
by virtue of the degenerate boundary curve must be
treated differently as far as tangent plane continuity is
concerned. Exactly what constraints can be imposed and
317
what types of surfaces with degenerate curves exist are
open questions.
Another question of continuity constraint is the
general problem of two overlapping surfaces, say an
airplane wing and fuselage. Here we are attempting to
ask for surface continuity in the middle of a patch, not
on the boundary. Of course, we could use contours in the
interior of a patch to define a new subpatch at the
boundaries of which continuity is to be imposed. But
this may not always be possible, nor may it be the most
general solution.
Further results are needed in specifying surfaces from
external data. Personally, I prefer the surface-molding
approach in which on-line feedback is continuously
present as contrasted to the point surface-fitting
approach currently used by most surface design systems.
However, there are many occasions in which it would be
expedien t to use such easily displayed surfaces as these
to approximate a surface described in some other form,
perhaps from measured coordinates.
Even using these bi-cubic rational surfaces as molded
surfaces there are not at present sufficient techniques
for manipulating the display. For instance, efficient
methods of performing small variations in the surface
are obviously needed.
I will do no more than mention the question of
discovering hidden lines in a figure composed of these
surfaces. The problem for this geometry is obviously
very difficult and defies a simple analytical solution.
Even the application of Warnock's algorithm, effective
as it is,9 may not be the answer, since his techniques have
been found very susceptible to Mach band distortion on
curved surfaces approximated by planar sections. Such
distortion gives the surface a "fluted" appearance at
the joints of the planes caused by a psychological
enhancement of the intensity discontinuity.
Example8
Figures .1 through 9 have been included to illustrate
the appearance of the surfaces. The figures are all true
perspective projections of the surfaces froni varying
vantage points. They should be viewed from such a
distance as to give a 45 0 field of view.' They were
computed upon a DEC PDP-1 with DEC 340 scopes
used for display. The PDP-l is a rather ancient machine
by modern standards, having an 18 bit word length,
5 p'sec cycle time, 25 p.sec multiply, 40 p.sec divide and
no floating point.
The time to compute a new view of a surface is from
1 to 2 seconds for these figures, depending on the
number of curves used. This is about 1-2 ms. per chord.
Each curve is approximated by 32 chords.
318
Spring Joint Computer Conference, 1969
Figure 5-Cylinder
Figure 7-Sphere
Figure 6-Modified cylinder
The tensors for the cylinder, sphere and t.oroid were
manually computed as surfaces of revolution. The
hyperbolic paraboloid or saddle surface is simply the
equation z = X2 - y2 expres.ro;ed parametrically in the
Figure 8-Torus
Class of Surfaces for Computer Display
319
REFERENCES
1 R F SPROULL I E SUTHERLAND
A clipping divider
Proc F J C C 1968
2 I E SUTHERLAND
A head-mounted three diriwnsional display
Proc F J C C 1968
3 S A COONS
Surfaces for computer-aided design of 8pace forms
Project MAC Report MAC-TR-41 MIT June 1967
4 H F BAKER
Principle8 of geometry
6 V.oI Cambridge University Press Cambridge 1922 +
5 L G ROBERTS
Homogeneous matrix repre8entation and manipulation of
n-dimensional constructs
The Computer Display Review Adams Associates May 1965
6 E A MAXWELL
General homogeneous coordinates in space of three dimension8
Cambridge University Press Cambridge 1961
7 R M WINGER
Figure 9-Hyperbolic paraboloid
An introduction to projective geometry
DC Heath and Co Boston 1923
8 D COHEN T M P LEE
Fast drawing of CUrve8 for computer display
tensor. The surface shown in Figure 6 was obtained by
making a 20 percent random variation in each of the
components of the tensor for the cylinder of Figure 5.
Proc S J C C 1969
9 J E WARNOCK
A. hidden line algorithm for halftone picture repre8entation
University of Utah Technical Report May 1968 4-5
POGO: Programmer-Oriented
*
Graphics
Operation
...
...
by B. W. BOElThl, V. R. LAMB, R. L. MOBLEY,
and J. E. RIEBER
The RAND Corporation
Santa Monica, California
grams without spending a great deal of time
learning the intricacies of the graphic subroutine package.
INTRODUCTION
Wide-scale application of interactive computer graphics
(ICG) is currently inhibited by two major difficulties:
To an extent, these difficulties are removed in more
specialized ICG packages-for such applications as
simulations, circuit design and layout, trajectory
analysis, curve fitting, and chemical analysis-which .
we would call user-oriented rather than programmeroriented graphics operations. However, the second
difficulty reappears as soon as the user wants some
capability not expressible within the standard package
(a fairly common occurrence), which can be achieved
only by rewriting a piece of' the package in a lowerlevel language.
This paper continues with some background information on the development and usage of POGO, followed
by a description of POGO's general capabilities,
illustrated by an example of its use.
1. Terminal time costs too much.
2. It takes too much effort and expertise to develop
and modify ICG programs.
Several approaches, including RAND's Video Graphics System and other television-based or storage-tube
based console designs, are currently being tried to overcome the first difficulty.
The POGO system described here represents an attempt
to overcome the second difficulty, at least for a certain
fairly general class of problems, which includes the
interplay of computational programs with alphanumeric
and curve input and display, but excludes highly
dynamic interplay of computational programs with
geometric manipulations.
POGO is fully operational; it allows a user to specify
the nature of his ICG interfaces in a natural way at the
graphics console itself, simplifying the programming
process in two ways:
Background and applications
Background
a. Unburdening the programmer of the tedious
and artificial process of specifying ICG control
"pages" (CRT displays) by transcribing coordinates from layout paper and stringing
together calls to graphic support subroutines.
b. Permitting programmers to create ICG pro-
POGO is implemented on ,a 256 Kbyte IBM 360/40,
furnished with an IBM 2250 graphic display console
with light pen, keyboard and function keys, a RAND
Tablet! for freehand inputs, an SC-4060 hardcopy
device, and some IBM 2311 disk drives. It is written
in IGS (Integrated ,Graphics System),2 a set of FORTRAN-callable ro,utines for elementary graphics manipulations similar to the IBl\1 packages GPAK and
GSP.
The "mother" of POGO (in the sense that necessity
is the mother of invention) is a user-oriented leG
system for aerospace vehicle traj ectory analysis called
Graphic ROCKET. a This system consists of a network
* This research is supported by the United States Air Force
under Project RAND~Contract No. F44627-C--()()45-monitored by the Directorate of Operational Requirements and
Development Plans, Deputy Chief of Staff, Research and
Development, Hq USAF. Views or conclusions contained in
this Memorandum should not be interpreted as representing the
official opinion or policy of the United States Air Force.
321
322
Spring Joint Computer Conference, 1969
rr===;1,r
It
"
I
...
I
........
LT
u •••
....
,
2 ...
.....
•
....
...
'..
1-~: ...
'2 ...
...
00
,
~~.~A~6~1~\~J--~I~'2~i--1i--~2ir--+~]dt-.--+
•
• .... TI~'
~iC 24
l2
••
Figure 1-Graphic ROCKET control page
Figure
I"ITIAI. C:O"OITIO" O'TIO,,:
o
OIOOIT.
I.AT. "
01001T.
I.AT. "
IIiUTIAI. VII..
(;] oloc:n.
IoAT. "
&AITI! VII..
(;]
OIOC:TI.
I.AT. "
lIIalTIAI. 'II"
(;]
(;]
I"'TIAI. II. T. I. "
IIIITIAI. OUIT"1. C:OIIOITIO'"
o
i. y. i
1 __________ _
"loT I TIIOI ,'T I
1 __________ _
I.AT I TIIOI '010 I
1 __________ _
1.00"0 I TIIOI 1010 I
VII.oOClTY IFTIJIc:l
1 __________ _
1 __________ _
'1.o101lT ,ATII "1001.1 10101
'I.IOIIT AIIIIIITIl '0101
! __________ _
1 __________ _
wll OIiT '1..'
1 __________ _
AIIOIoI 0' ATTACK '010 I
1 __________ _
1111. . .
I
PAOI .Aell
!lAITIl 11001101
ROCKET output
IAITII VIII..
T 1111 calC:)
r
:~-Graphic
'AOI 1'0•• " ••
IT.AeKIJlOI
Figure 2-Graphic ROCKET initial conditions page
of interconnected control "pages" (see Figures 1,2) by
which a user specifies the design and Bight plan of a
rocket vehicle: then specifies and views desired graphical displays of the resulting vehicle performance (Figure 3).
To create control pages tor Graphic ROCKET, we
had to visualize, usually with the help of a layout sheet,
the positions and extent of lines and characters, and to
determine their coordinates and character counts to
enter as arguments for the appropriate IGS routines.
Finally, we had to check the display on the 2250 to see
if it came out the w~y we wanted. If not, we had to go
through all the steps again. ~Iodifying a control page to
incorporate an extra user-desired option also required
going through all the steps again.
Finding that other leG application designers at
RAND had similar problems (and having had them
previously ourselves), 4 we made a control page design
program that was as general as possible without seriously compromising its simplicity. To complete the
package, we modified a curve input program that had
been developed for a graphic re-entry simulation, 5 and
the curve display program and filing routines from
Graphic ROCKET, to make them available to the
general I CG program developer in forms easy to use,
and compatible with the design pages and with FORTRAN computational programs.
Application's
Since then, POGO has been used to create control
pages and explanation pages for Graphic ROCKET
and other models including on-line simulations and
chemical models; it has further been useful for such
processes as curve-fitting and digitizing map data. It
has also been used to entirely specify the ICG interface
for a model of Buid balance in the human body. Using
the SC-4060 hardcopy option, which produces a paper
copy and a 35 mm film copy of the 2250 scope contents
whenever a function key is pushed, POGO has been a
handy tool for composing slides for briefings and talks
(e.g., Figure 4). In this vein, POGO has an attractive
POC-o
323
ORIGINAL BATCH PROGRAM
l
ff
MODIFICATIONS FOR POGO
~·......J
IBM
JlO''''
Figure 4-Layout of graphics terminal
Figure 5a-The POGO process: Batch program modifications
potential for film animation, which we have not yet
been able to pursue.
model, producing output functions from input functions and parameters, the following capabilities are
needed to construct an interactive-graphics interface:
Using POGO: an example
This example involves a model of fluid balance in
the human body. The rate of the body's water excretion depends on the level of a hormone called AD H
in the blood plasma, while the rate of ADH production
depends on the amount of water in the plasma. The
functional forms of these relationships are imprecisely
known from physiological measurement. One would
like to try a set of test functions (curves), specify
some external inputs in curve form (e.g., "a drink of
water"), and a set of initial conditions, integrate the
set of coupled differential equations and compare the
results with observed data.
This had been done by means of a batch-type FORTRAN program (Figure 5a) that accepted keypunch
input curves and parameters and printed the numerical
values of the resulting integration outputs, which were
then manually plotted. As this is a tedious and timeconsuming process, one would like to give the researcher
the capability of tracing his curves directly into the
machine and directly viewing the output curves. And,
if the fit is not satisfactory, one would like to interrupt
the integration, modify the numerical or curve inputs,
and try again. This capability is what POGO allows a
programmer to create in a simple, natural manner. The
accompanying film will show the interactive aspects;
this paper will just show some examples of the various
pages.
1. A means of interactively tracing, editing, labeling, and storing input curves.
2. A means of interactively recalling stored input
curves and specifying which to use.
3. A means of identifying the types of input curves
that may be traced and stored, and of relating
them to the appropriate storage arrays in the
batch program.
4. A means of interactively selecting, scaling, and
displaying output curves.
5. A means of identifying the types of output curves
that may be displayed, and of relating them to
the appropriate storage arrays in the batch
program.
6. A means of entering values of numerical parameters through the graphics console, and of
relating them to the appropriate storage locations in the batch program.
7. A means of specifying decision options at the
graphics console, including the flow of control
between the various input and output pages.
POGO provides these capabilities in two phases of
operation at the graphics console, the design phase and
the execution phase, separated by a generaHy short programming phase. The nature of these phases and their
interrelations are shown for the fluid balance model
example, a fairly typical case, in Figure 5b.
Curve input
Constructing graphical interfaces
Given any batch program, such as the fluid balance
Capabilities 1 and 2 for creating, storing, and recalling input curves are provided during the execution
:324
Spring Joint Computer Conference, 1969
DESIGH PHASE - AT C{I!ISOLE
IMlER
I
Enter names of
tnput arrays.
Ir-----1I
(Fig. 8)
PROGRA}MI~
Enter names of
output arr.ya.
)
(Fig. 10)
II
.Due
Ic.u::~~.... I
'OINT
ay II
II ....
A ••
.A'n 0. AN ••ODUC:TIDII " • • AT •• 1101.1 •• AC:TION
1
I (Figs.
11,13)
PHASE
• Modify batch progr...
(Fig. 5a)
• Write, or use standard POGO, control page progr....
(Fig. 12)
• Write, or use standard POGO, main control program.
..
• Compile, link edit, file on disk with control page data,
o
I.
•
using standard POGO job control sequence.
I
II
I
.......
II . . . .
•.• n.
i_
IIOI.IE F.
+
Figure 6-POGO curve-traeing page
EXECUrIOR PHASE - AT CORSOLE
Read in
frOll! disk
Trace curves
(Fig. 6)
curve types
(Fig. 7)
output graphs
(Fig. 9)
Figure 5h-The POGO pme'eR:;: Fluid halance model example
phase by a pair of standard POGO control pages.
Figure 6 shows the curve-tracing page. Pushing the
"SETUP GRAPH" box allows one to move the axes
and adjust the scale numbers to match the curve to be
traced in. As the stylus is capacitively coupled to the
Tablet, one can place his graph paper on the Tablet
and trace the curve by following it on the paper. This
capability is provided by the "TRACE CURVE"
option. Pushing the "EDIT POINTS" box allows one
to specify a fraction of the points to be retained, or to
add and delete specified points with the stylus. "ERASE
POINTS" removes the curve. "STORE CURVE"
writes the curve data on the disk in the location indicated by the legend; this number can be modified, so
one may recall a curve, modify it, and keep both copies.
"RETURN TO LIST" transfers control to the
other standard POGO input page shown in Figure 7.
This page indicates the different types of input curve
available, and the current list of curves of each type
appears when the appropriate "LIST" box is hit. One
can then specify which of these curves to use in the
calculation, to delete, or to display; the latter option
transfers control to the cu...-rve-tracing page with the
specified curve displayed. Up to ten curve types and
ten curves of each type can be stored; the "SCROLL"
options allow the user to reach the ones not currently
displayed.
Capability 3, for identifying types of input curves,
is provided during the design phase by the POGO page
shown in Figure 8. The user specifies, at the graphics
console; 3011 the information POGO needs to label his
u;rm
i
TYPE OF CURVE
J
C
8
0
I.
I.
8
Z
'OLUTI I.C.ITIDIII .ATI ". ADM MOLl •• ACTIOIII
~
(XJ
I
."TI 0. ADM .IODUCTIOII V' .AT •• 1101.1 '.ACTIO"
•
.ATI• • ATI V, ADII
I
151dLAY/51 n
1
•
I:
It I
II
l LIST OF CURVES OF TYPE
, .." •.••• cua"l
I
I
£illffiJ
[ill]
I · . · ••
8
8
III. TAIL 1-11
8
8
8
c:J
8
8
8
8
8
8
8
I
8
a ... ".1 •• cua"'l
~
J
I '''01
'''CII
I
... API •• C:U.". IIOD 1-1.
Figure 7-Input {"urve li>-:t, page
I
.AG. AMIEAD
I
POGO
1\
r
U
~
~:..:
,
~
."To;1t
1O~<;It"TIO~
It"To; 'li AD" "U."OOoI\ "0.. ,,
DISPLAY: 1!1!_III!!_=_J.UJ_APII _____________________ _
CON'''I.: I.F.I.NC. IUti
~lttTIU~
C!!!!::!!Jr...
AD"
a.".
4
~OD""l.TI\
...
• ..
MU.... ~ ... "
,"S ... ~
).4'
J
.. ~<;It"TIO~ H4T" .li
"I)"
\IS
,,0.. "
1110.'0
0.10000
u.O.O'
. . . . 00.
u .....
o. '.00.
lUO.OO
0 .•••••
~.A\;TIO"
:sOL..,l"" liT
-OI ...".SIOIII
325
'"
.. 0\.t:, .. 11III
100
::~:HO~ "0" ::O~~:~O:H'\:A:: :~~: .·HlI~~'O:OI."'''I''
.
y
AM
TO
• I.
I.
•
z
: Hi
1.:1
AI
D
•. s ••••
II . . . . . .
U
+-
.. I
I ••••••
•..••.. U
1 . . . . 0.
• .1 ••••
1'.0.00
.......
~
""'III.':'" 0'" PO' lilT» __ _
I
"O~"""'Dt:ftIr,T""
Alt 11\1IL.K ..... M"- _________ _
LU
_______ _
'.10'"
T~
AMK"
"AMt: _____ _
IIZO.OO
""ITS _______ _
4HHA\ .. " .. " _____ _
o".<;H IPT 10" _______________________________________________ _
~~~==+-~~~~-+--~~~--~~~
c:::!:!!!!l u . .... .. . .... .. . 0000 eo .0000 C!!!:!!!!l
.......
11 .•• 0.
xl
NUMEIICAL V" .. U.Illlo
Figure 8-Input array specification page
I HOLD
JUM' IACIC
.TO 'CII
I
'''01 ."CIC
11.0'"
IIIN
TIIII
1 •• " l l ' o
I
ITOII lI.
lUll 110. __
'0.0000
.0 . . . . .
It
1.1 •. I . '
Ja
o
I I~:"::~·.L
. .J
ali
•. Itl
001
GIlD
Figure 9-0utput graph page
input curves and relate them to the appropriate
arrays in his batch FORTRAN program, via the
questionnaire form on the lower part of the page.
When he pushes the "ENTER NEW DATA" box,
the resulting "information is summarized on the upper
part of the page, and entered into the appropriate
master tables on the POGO disk. "PUNCH DI1VIENSION STATEMENTS" produces a set of punched
cards with the resulting FORTRAN array dimensions,
if needed, for the user's erstwhile batch program.
For example, suppose a user has entered the information shown in Figure 8 during the design phase. Then, if,
in the execution phase, he hits the "USE" box on line 1
of the "LIST OF CURVES OF TYPE 2" area of the
control page of Figure 7, POGO will go to region 2 of
its curve input storage space on the disk, read off the
values of the independent and dependent variables
stored in item 1 of region 2, and store them in the arrays
XA2 and F2 (from Figure 8), respectively.
Curve output
Capability 4, for selecting and displaying output
curves, is provided during the execution phase by a standard POGO display page shown as Figure 9. This page
allows one to graph values of two dependent variables
(Y and Z), as functions of one independent variable
(X). The windows along each axis show which of the
output quantities is being used. Pushing the arrow next
to a window brings in the next quantity on the list.
Its name and unit appear in the window; its nominal
upper and lower limits appear on the axis, and, on
pushing the appropriate letter (X, Y, or Z), the corresponding output curve appears.
One may change scale by writing in new values with
the stylUS, find the numerical values associated with any
point in the output region by pushing "NUMERICAL
VALUES" and indicating the point with the stylus, or
superimpose a grid on the output region. Generally,
output points appear as they are being calculated; one
may push boxes to "HOLD" the calculation and to
"GO" again. And, one can store current curves on the
disk and recall them for comparison with future runs
by using the "STORE" and "COMPARE" options.
Capability 5, for relating the quantities produced by
the erstwhile batch computation program to the routines controlling the Output Graph Page of Figure 9,
is handled during the design phase in much the same
manner as the corresponding input specification Figure 10. With this page, the user sits at the graphics
console and enters, for each variable he wishes to display (up to twenty), its FORTRAN array name and
dimension in his computational program, some description for the labels along the axes on the display page,
and some nominal lower and upper limits. As with the
corresponding input specification page, "ENTER NEW
DATA" updates the appropriate master tables on the
POGO disk, and "PUNCH DI}IENSION STATEMENTS" produces FORTRAN array dimensions on
cards, if desired.
Spring Joint Computer Conference, 1969
326
DIII;I:KI'TIUI'o
i
Ii
I:
R
U
L.
I.
I.I'oITI;
"IU'" ,
DI .... I'oI;IU'"
"U"I"'41.
I.U .... 1l
1."t;1l
I
""1°t.1l
MULt-1i
ailli
100
U 0 000
O.tUOt;.04
~
"0"
MULt-1i
"Rli
100
00000
1000ut:-U.
J
1i0L~TK
MUL.t:1i
lillli
100
00000
Uo~OOt;·UI
4
TIIU;
MIN
Tli
100
00000
OoIOOt:.o.
~
RII:1. a4TII:R
1'00"",
"1lt:L.
IUO
00 UOO
OoIUUt:.UI
!
IP~Ii"
WI'fil 'filii NODII., YOIi CiAjIi
III TR"CI IN CURYII DESCRnJIIO THI INTIR"CT ION 0'
."TI8, .OL.UTI, "NO HORIIOIII I.IVII.. III T"I: HUN"N BODY
III TY'I OR .RITI IN V41.UEI 0' INITIAl. LIVILS 0' THill
OU""TI1'III,410 T8"CI III CU8VI. 0' IXTI8NAL IIII'UT.
\,;"~"lit.~
""Ilt: I to
M"Dt: TU npt: I.I:oT
IiP!!I:II"
FLUID BALANCE MODEL
LI"I(~
(II VII. CU8VIES SHO.IIIG THI 81.UI.TIIIG IIIIUL.ATIO
I
IVOLUTION 0' THI 'LUIO BAL""CI 0' THI 100Y
I
INITIAL CONDITIONS
4 .. ". T\''':
INITIAL TIIiI T. (1i1N1
O":;I:IlII'T I'll: TII:RM _________ _
!----!------
INITIAL ."TIB LIVEL .0 (IIOLKSI
.0
=____ ! _____ _
,;;;c:..:~:
o
tUKl K4" 4KK4\
i iii i i i oii. .01.;';\"'. .. ... Ii.
1)1 .. ",,:; IU"
JIIITIAL HOBNOIII 140"1 LIVIL "0 (1101.1$1
B
11,,1:,,1
+
Figure lQ--Output array specification page
_____ _
IIUIIIIII 0' SIG""IC,,"T DIOITS
"0'11""1. ~'P"R L.I'IIT
11'41it;
! ____ !
+
-!!!!
TO
TO
III'UT CUBVII
COIITBOL '''B''"ITI:8I
COII.UTI "liD
'''01
'AGI
OIS'LAY
-!!!!
-!!!!
TO
-!!!!
Figure II-Initial eonditions page for POGO example
Control page design and interfacing
Capabilities 6 and 7, for entering parameter values
and specifying decision options at the graphics console,
are provided by control pages, which the user designs
himself. He can do this at the graphics console by means
of a set of POGO routines that allow him to create
strings of text, fields for numerical values, option boxes,
and geometric figures. He may then use the Tablet
stylus to move these around the CRT screen until he
is satisfied with the layout. He may enter codes that
will be used to relate the numerical fields and option
boxes to his FORTRAN program, and then press a
button, which has POGO punch out a set of cards that
will recreatOe the display at any later time.
Figure 11 shows one of the control pages that was
created with the DESIGN program for the fluid balance model. The number associated with an input field
indicates the location in the input storage array into
which POGO will store values entered in that field;
when one of the boxes is hit, the number accompanying
that box will be returned to the user's control program
for him to analyze what to do next.
To manage the control pages at execution time,
POGO has a standard set of routines that can be incorporated in the programmer's FORTRAN control program in any way he desires. These routines include:
RECALL
given a page number, creates the corresponding
page on the screen.
ACTION
wa.its until the user interrupts via keyboard,
function key, light pen, or Tablet, then returns
to the control program with numerical codes
identifying the type of interrupt and its location.
SA VAL
tests values of variables on the screen to see if
they have been changed since the last such test.
If so, they are converted to floating point and
stored in the location corresponding to their ID
number.
By stringing together CALL's to those routines in his
FORTRAN control program, the programo..rner can allow
the user to switch from one display page to another,
enter new values, select multiple-choice options, or
transfer to the curve input and display pages. He generally writes these programs after having composed
the displays (see Figure 5), but can work the other way
around also.
Figure 12 is an annotated listing of the subroutine
POGO
327
General comments on control routines
0001
0002
0003
0004
0005
0006
0007
SUBROUTINE CTRLPG(IPG)
COMMON/PARAM/D( 100)
--storage array for input parameters
COMMON/JPAGES/JCURVP .JGRAFP .JGRI DP .JUSERP (10)
COMMON/FLAGS/IPGNXT .NPOINT(20) .INPNTS(10) .IRUN
--two standard POGO cards
COMMON/MODES/Z{200)
--a co_un1catfon area for all graphics routines
DIMENSION BCOVAL(3.15) .KVAL(15)
--for s tori ng BCD images and poi nters
CALL GETIDG(Z.ID)
--provides local ID number for display
0008
CALL RECALL (Z .JUSERP (IPG) .0 .BCOVAL .KYAL ."VAL, OMY .OMY j
--places display of Fig. 11 on screen
0009
CALL ACTION(Z.ICH,IVAL.ID)
--waits for user action
0010
IF(ICH.EQ.2 .OR. IVAL.EQ.500) GO TO 2
--check inputs on box strike or end key
IF(IVAL.GE.l00l .AND. IVAL.LE.10l0) GO TO 3
--box strike to change page
GO TO 1
--other acti ons ignored
0011
0012
0013
0014
0015
0016
0017
0018
CALL SAVAL(Z.D.BCDVAL.ID.KVAL.NVAL)
--convert new numer1 ca 1 entri es
GO TO 1
--other acti ons ignored
IPGNXT -IVAL-1000
--index of next page routine to be called
CALL DISPLG(Z.O.O.O)
--clears display screen
RETURN
--return to control program
END
Figure 12-POGO control page subroutine
CTRLPG, which uses these POGO routines to manage
the initial conditions page of Figure 11 at execution
time. First, the page is put onto the screen with RECALL, then ACTION waits for a user action. Suppose
he enters the number "43.6" in the field next to "INITIAL WATER LEVEL", and the number "3" in the
field next to "NUMBER OF SIGNIFICANT DIGITS" (either via the keyboard or the Tablet stylus),
and then pushes the "CHECK INPUTS" box (with
the light pen or Tablet stylus). Control will pass from
the subroutine ACTION with IVAL = 500; the next
statement results in a "GO TO 2" that passes control
to SAVAL , which will return with the value 43.6 placed
in FORTRAN location D(2) and the value 3.0 placed
in location D(14).
The subsequent "GO TO 1" returns control to ACTION, which waits for further action; suppose the user
pushes the "TO INPUT CURVES PAGE" box. Control now passes from ACTION with IVAL = 1002;
the subsequent tests produce a "GO TO 3," which
computes the number of the page to be placed on the
screen next (IVAL - 1000 = 2), clears the display
screen, and returns control to the main program. Of
course, during the programming phase of Figure 5, one
must also write a main program that calls the appropriate subroutine when its number is returned.
1. If the user's control pages follow the standard
format of Figure 12 (number fields referenced to
an input array D(100), a "CHECK INPUTS"
box with a code of 500, and boxes for going to
other control pages, for which page N is given
the code 1000+N), then the user need not even
concern himself with CALL's to ACTION,
SAVAL, etc. In this case he need oniy insert a·
CALL CTRLPG(IPGNXT)
in his main routine and include CTRLPG in his
load module.
2. Even if the user wants extra features, such as
special option or decision boxes, on his control
pages, the control routine he writes will be generally simple and straightforward. Furthermore,
it will be transparent to such control page modifications as adding or changing commentary,
adding new "values" fields, and moving entities
around the page.
3. The output display control page of Figure 9 and
the input and output array specification pages
of Figures 8 and 10 were laid out with the POGO
DESIGN program. The corresponding control
programs involved CALL's to ACTION, SAVAL,
etc., but also required some IGS-Ievel programming for scrolling, curve display management,
and numerical values. These figures give some
idea of the range of POGO capabilities for composing and managing control pages. This "bootstrapping" capability also allowed us to shorten
the development times of the total POGO package, probably by a couple of months; it also
makes these pages very easy to modify.
Control page design
All of the figures in this paper, except Figures 3, .5,
6, 12, and 13, were created with the POGO DESIGN
program; this gives some idea of the range of its capabilities.
The facilities available to compose and interface
displays are indicated in Figure 13, which show the
POGO function keyboard layout. To use any POGO
facility, the user simply presses the corresponding
function key. Short descriptions of some of these facilities follow:
Small Characters
The user indicates with the Tablet stylus where
328
Spring Joint Computer Conference, 1969
cates (by lifting the stylus) that he is satisfied
with the box.
Values
n
SY.ALL
J:.A.~E '-.../ T~UCR
CRARACTERS C:iARACTZRS
t.'!'
?:.AI!':
0000
HeR!Z
VERT
VALUES
FA.'iCY
The user points with the stylus to define a place
to store the value of a variable; the position is
denoted by underscores.
IXSERT
Fanf:Jj Boxes
666'006
'°0 '0 "0 "0 ~o '0
'0'0 ~o '0'0 '0
'0'0"0"0"0'0
!)E~""'!E
GE0X.
Fi:GUiUS
DISPUYS
6U":?"",,"!
DISPLAY
INVISIBLE
b0XES
SYST:<;-t
J~!.'iED
GR0~1C
tINES
CIRCLES
ERASE
SCiU:EN
These are similar to plain boxes, except they
have a dot at the center to serve as a target for
the light pen.
RECALL
FUES
Insert Codes
KILL
,
i
II
j'
Joined Lines
I
i
Figure
l:~-Fun('tion
By each box and each "values" position in the
current display, the user is presented with a line
of underscores to furnish a numerical code which
will identify this box or value this FORTRAN
control program.
key overlay foJ' "DESIGN" program
on the "page" he would like his character string
to begin, then enterR a string of characters from
the keyboard.
Touch-Up
Places the console in the character recognition
mode. 6 The user may modify any of the characters on the screen by writing over them freehand
with the Tablet stylus.
Jlove
The user points to the character string or geometric entity he wants to move with the Tablet
stylus, and drags it around the screen with the
stylus until it is where he wants it. Lifting the
stylus completes the action.
Plain Boxes
The user points with the Tablet stylus to define
the lower left corner of the box. Pointing again
defines the upper right corner; the user may drag
the position of this corner around until he indi-
The user can draw arbitrary geometric figures
consisting of joined line segments with the
stylus.
Recall Files
They allow the user to recall a previously created
display for review or modification.
Output Display
POGO asks the user to provide a name for the
current display. When this is done, POGO
punches out a set of cards with the information
necessary to recreate the display and identify
its components to the FORTRAN control routines.
An example using the DESIGN program:
Furniture arrangement
Figure 14 shows the layout of an apartment suite and
the outlines of various pieces of furniture. Pushing the
MOVE key in the DESIGN program allows one to drag
the images of the items of furniture about the screen
until he has a satisfactory layout. Or, by using the
other DESIGN options, he may create more furniture
or modify the outline of the suite. This application
makes a nice demonstration of the potential use of
interactive graphics in problems of spatial distribution.
The entire application was composed in s. twentyminute console session with the DESIGN program.
Por~
10,.AI
CHAI.'
0
0
0
0
0
0
0
0
0
0
r
0
~
0
~
m
I
I
L",
TAa ....
DO
OOG
0
8
8
I
\
I
PIA,"O
~
FURNITURE ARRANGEMENT
329
4. Scaling and overlay of displays at design or
execution time (e.g., for map and network studies).
Others are more difficult, such as incorporating a
hierarchical structure in DESIGN program constructs,
due to the nature of IGS, our source language. On others,
such as a more advanced file and retrieval system, we
are waiting for more information on usage patterns.
Finally, one would like to combine the design and
execution phases, indicate the flow of control and processing activities at the console along with the page
design, and then directly execute the resulting program.
RAND is doing some research toward building such a
capability, but it is more difficult than POGO by at
least an order of magnitude.
PO I NT TO TN. ,.UaN I TU.. .1 TH TH. ITY .. US
AND NOV. I T AROUND TH. "OUI. A. YOU 1.1 II.
oa . . . au I 1.0 YOU. ol1'II ,.UaN J TU ••
Figure 14-A POGO j)ESIG~ applic'ation:
Furniture arrangement
CO:\L\,IENTS AND CONCLUSIONS
V €!,satility
The POGO pages are modular and need not all be
used for an application. Thus, a POGO program may
consist completely of control pages, as in decision tree
applications, or perhaps just curve input and output, as
in computing convolution integrals. Further, the modules have clean, well-defined interfaces and can be
(and have been) used to design and update the control
page parts of a special-purpose ICG applications system, or input and file traced curves for interactive or
non-interactive programs.
Although the DESIGK program and the curve-tracing program require the RAND Tablet, the rest of the
POGO pages (including pages composed with the
DESIGX program )will run on a configuration having
only light pen and keyboard input.
Areas for improvement
Some POGO improvements can be accomplished
fairly straightforwardly, and these we plan to incorporate, including:
1. Wider range of output pages: charts, histograms,
more numerical information.
2. Simple operations on output curves, particularly
integrals and derivatives.
3. Reformatting displays at execution time (e.g.,
for summarizing a sequence of decisions).
Development and usage experience
Total development time for POGO to date has been
about one man-year. Machine usage on the 360/40
was about 100 hours for development. As mentioned
above, our ability to bootstrap some of the curve input
and output pages with the DESIGN program reduced
our development time by a couple of months, and makes
these pages far easier to modify.
We are just beginning to instrument POGO to measure user interaction and response times. One interesting
usage observation is that people tend to get tired of the
continual, precise interaction involved in control page
design and sign off after one to two hours.
On responsiveness in interactive graphics systems
On our Graphic ROCKET application, we estimate
that the POGO DESIGN page has cut our control
page development times by factors of four to ten below
those required for the manual layout-paper approach.
Further, the work is far more palatable, and our error
rate is cut to virtually nil.
The most important consequence of the above factors
is that they have lowered considerably our responsiveness threshold on providing users with additional
capabilities not in the basic Graphic ROCKET package.
On most interactive graphics systems we have seen,
this extension-threshold is quite high and constitutes
a major usage bottleneck.
If there is any general reason for this, we feel it is
due to a tendency to design complete ICG systems by
deductive inference from an abstract model of typical
user performance at a console, producing "closed"
systems, which are quite responsive in the small but
quite unresponsive in the large. Our experience with
Graphic ROCKET and POGO users indicates that
330
Spring Joint Computer Conference, 1969
J E RIEBER
general characterizations of user activity are still quite
risky, and that more overall responsiveness is gained
by the prototype approach: deliberately designing an
austere but extendable prototype, then refining it by
inductive inference from observed usage patterns.
3 B W BOEHM
REFERENCES
M. Kierer and J. Reinfeids Academic Press 1968 343-45)
5 R TURN R L MOBLEY J P HAVERTY
M WARSHAW
A:rt application of interactive computer graphics to
Graphical aids to aerospace vehicle mission analysis
~
The RAND Corporation P-:3660 October 1967
A S PRIVER B W BOEHM
Curve fitting and editing via interactive graphics
The RAN D Corporation P-3742 December 1967
(Also in Interactive systems for experimental applied
mathematics
1 M R DAVIST 0 ELLIS
The RAND tablet: A man-machine graphical
communication device
The RAND Corporation RM-4122-ARPA August 1964
2 G D BROWN C H BUSH
Trte integrated graphics system for the IBM 2250
The-RA~D Corporation RM-5531-ARPA October 1968
on-line ballistic missile defense simulation
The RAXD Corporation RM-5590-ARPA August 196H
6 G F GRONER
Real-t-i-;ne reco-ngU-ion of r/,Q,-ndpri-nted text
The RAND Corporation RM-5016-ARPA October 1966
Computer-aided processing of the news
by J. F. REINTJES and R. S. MARCUS
M a8sachusetts Institute of Technology
Cambridge. Massachusetts
The process of publishing the news may be divided
into three parts: the news gathering stage, the processing of the raw information into pub1ishable form,
and the actual printing and distribution of the material.
IVlany technologies, including wire and wireless communication, computers, automatic-typesetting equipments and photographics are being employed by news
publishers in order to achieve their goal of getting a
hard copy of the news to their readership as quickly as
possible at the lowest cost consistent with profitability.
Our study of the application of multiaccess computers
operated in an online mode to news processing indicates that these machines offer interesting opportunities
for departure from the traditional processes employed
in the business of news publishing.
In terms of information transfer, newspaper publication embraces four areas: information gathering;
information processing; hard-copy reproduction and
distribution; and auxiliary business operations. In the
news-gathering phase, news and other information
are derived from many sources, including staff correspondents and writers, the wire services, advertisement customers, and syndicated columnists. In the
news processing phase, information arriving at the
newspaper office or generated internally is edited and
formatted to reflect the character of each publication
and to conform to the depth and breadth of coverage
which management desires. In the third, or hard-copy
reproduction phase, formatted information is set in
type and printed in accordance with the style of the
newspaper. In this presentation we are principally
concerned "\\-i.th the second area, that is, news processing.
As in most manufacturing operations, news processing may be looked upon as a multiple-input, multipleoutput operation with a variety of internal feedback
loops. Figure 1 illustrates the manner in which news
flows from the time of occurrence of a newsworthy
event until a permanent record of the event appears
as hard copy in the hands of the readership. The process
begins with the occurrence of an event or with a decision of a customer to advertise. Advertising itself
may be considered as a component of the news in the
sense that it is a public pronouncement that someone
has an item to exchange in the market place. As indicated in Figure 1, an event may be transformed into
a news item by representatives of the wire services,
syndicated columnists or by in-house staff correspondents working on a full or part-time basis.
The next phases of the news processing procedure
embrace management decisions and production-staff
operation which culminate in manuscript and display
advertising copy for a specific edition of the newspaper.
In many newspapers these materials are now set in type
either under computer control or through use of digital
techniques. Following- type setting, plates are made
and hard copy is printed.
Our work to date has pertained to the development
of techniques for storing digitally encoded news in a
multiaccess computer and for retrieving the stored
information through dynamic interaction between
the machine and its user. The problem divides i~lf
naturally into four areas. One must first identify the
INTEltNAl INPUTS
STNFefine--~IS/030
Adds, deletes, or prints user definitions generated at
a terminal whenever the inquiry statement includes
the I>EFINE, CANCEL, or PRT/I>EFINITIONS
key commands.
:343
programs not in core, and files, file tables, and indices
can be loeated on assorted storage devices depending
on contention problems and channel utilization. The
system configuration of the :\1IS/360, :\1odeI50, used in
the IB:\f Poughkeepsie Laboratory is shown in Figure 1.
Getting on-line
Each user with a dial-up data phone dials the number
assigned to him and establishes a link with the computer
via the 2703 TCU. If the line is dedicated, rather than
dial-up, the user merely puts power-up on his terminal,
and he is ready to transmit. In the first case, there is
no contention possible on a user's line until he disconnects, and with a dedicated line no contention is
possible.
Basic inquiry procedure
The basic elements of any inquiry, shown in Figure 3,
are:
Error, inquiry history, and mail processor
Generates either error messages or appropriate endof-job messages and, at the same time, writes out the
inquiry history record. This module also searches the
history file for user mail requests when the computer
operator is ready to satisfy these particular requests
Update
Changes the contents of fields in a record when activated by terminal inquiries. Editing of data being
changed includes alphanumeric and range checking, and
an audit trail of all transactions is also supplied.
If, for example, there are 250 fields in each file record,
any of the field terms can be included in the inquiry in
any order, as can any selection criteria and control
terms desired. The format of the output is dependent
on the order of terms within the inquiry.
Definition of inquiry elements
lVIIS control tables
Each inquiry statement
following tables:
Security code
File name
Inquiry parameters
Format terms
Selection criteria
Control terms
IS
compared against the
Report description
User description
Field description
Access description
These tables describe all pertinent characteristics of
each standard :\IIS report, each field in a record, each
user who will access particular files, and the description
of all users who have special access to files.
System operation
Each user's file is located on an IB:\'C 2314 Direct
Access Storage Facility as are all description tables and
the indices for all files. All data sets, including :\US
Security
The first entry for any inquiry statement must be
the security code assigned to each :MIS user. Periodically, the security codes are automatically changed
using a random means of selection.
~
xn..
ecuritY
Code
rMIND:::, ..~ C1AOOnl'O]
FUeR
I
-
Inquiry
f ar-
REL/DATB ./C
teu
GT I'm '.0/1 ./C
Selection Criteria
Control '1'el'lll
Figure 3-Basic inquiry elements
~44
Spring Joint Computer Conference, 1969
Special access within a security code
Each security code can be given "special access
coding." In the file table, cards containing security
codes that indicate special access to certain files or data
fields can be specified. For example, many users can
interrogate the personnel file, but only cleared users
such as salary administration are able to retrieve salaryfield data from this file.
Format terms
Each data field~in the file has a specific name assigned
by the user. Only fields (such as CIRCUIT NU2\1BER,
RELEASE DATE and E/C NO., as shown in Figure 3)
included in the inquiry are displayed in the output for
those records meeting the selection criteria.
File name
Each l\tIlS user assigns a name to his file and, if
desired, the names of any standard reports he wants.
These reports must be defined within the MIS ta.bles
and, at the time of inquiry, may be retrieved byentering the file or report name. If inquiry parameters are
added for fields not in the first standard report, the
output will not be a standard report but will include
only those terms indicated in the inquiry.
There are three names assigned to each field in the
file: normal field name, the term used when making an
inquiry, and the column heading for each field when
displayed. Each output report includes a heading for
each field.
Control terms
Mter the desired terms and selection criteria are
determined, the form of the output may be further
qualified by the use of the following control terms.
TOP
-
Top number of records that meet
criteria.
LOW
-
Lowest number of records that meet
criteria.
SEQ/H
-
Sequence, high-to-Iow, of all records
meeting criteria; field to be sequenced
must be indicated
SEQ/L
-
Sequence, low-to-high.
TOTAL -
Provide field totals only, without
printing details.
COUNT -
Provide only a count of the number of
records that meet criteria.
LIl\1IT
-
Control the number of output lines,
i.e., print only a specified number of
lines regardless of the number of
total records that meet the criteria.
~1AIL
-
If this term appears in the inquiry,
it cancels output from the terminal,
and a mail request is store~ on the
history tape. After :\tIlS is off-line, the
operator searches the history file for
all mail requests, prints them out on
the IBM 1403 Printer, and then
mails the output to the user. This is
used primarily for an excessively
large output and frees the terminal
for further on-line user inquiries.
CALC
-
MIS terminal users can also perform
calculations on data fields and print
and total the calculated data that are
requested in the selection criteria.
Calculate operations include:
Selection operators
Select terms are:
EQ -
Equal To
NE -
Not Equal To
GT -
Greater Than
NG -
Not Greater Than
LT -
Less Than
NL -
Not Less Than
WL -
Within Limits
OL -
Outside Limits
Multiple selection criteria are allowed on various
fields. For each criterion, except WL and OL, the select
term must be preceded by a format term and followed
by a literal (see Figure 3). Two literals must follow
WL and OL.
+
(addition)
(subtraction)
* (multiplication)
/ (division)
V (square root)
** (exponentiation)
-
DEFINE -- This is one of the most powerful control terms. It enables the user to
equate a report name with a group
of terms or with a total inquiry
statement. For example, a complex
On-line Information System for Management
inquiry statement of the maximum
length of 132 characters could be
equated to a report name such as
REPORT/10l. The DEFINE capability is used most effectively when a
report is frequently required, and
the user does not wish to enter the
lengthy statement each time. This
also eliminates possible operator
errors when entering a long inquiry.
Figure 4 shows a typical inquiry into a personnel
file, inc.1uding the report heading· and the detailed output. The actual Poughkeepsie Laboratory pelsonnel
file contains approximately 4000 records with 248 fields
per record. All of the fields can be selectively manipulated with the resulting data output appearing in any
desired order or quantity. Also shown in Figure 4 is the
use of the DEFINE term.
MIS implementation and installation
The concepts, philosophies, and benefits of management information systems are now accepted by most
areas of management. The greatest difficulty was
gaining management's acceptance of the time and
expenditure required for successful implementation
and installation of an MIS system.
Early in 1966, efforts to establish a terminal-oriented
:345
management information system in the Poughkeepsie
LaboY'~tory were begun. Considerable systems analysis
and cogramming experience of on-line terminal systems
had been obtained with ATS. This helped to make
management aware of the value of such systems,
more knowledgeable about their functions, and more
appreciative of the efforts to make them operational.
At that time a system called MICS (Management
Information and Control System) was operational in
the IBIVI DP lVIidwestern Region, and a follow-on
System/360 effort was starting to convert it to System/
360. The capabilities of this system were valuable to
the Poughkeepsie Laboratory and made an appropriate
starting point for moving into the on-line management
information systems' world. The effort began by canvassing the "bread and butter" application areas of
the laboratory such as purchasing, personnel,and
finance. These areas had data processing as an integral
part of their operating life, and they were constantly
subjected to new reporting requirements and frequent
statistical gyrations. Because of these two points, it
was believed that MIS/360 could easily be applied to
their problems and easily understood and appreciated
by management.
Some people felt that top laboratory management
should be addressed first, and that their support and
active involvement in MIS/360 should be enlisted
before applying it to operating levels of management.
This approach was strenuously opposed for the following reasons:
Securi ty Code
1
XYZ
1. Problems in the early stages of implementation
F11e Name
.~
NAME SER MGR HlREJDATE DEPT WI. D12,D19 JCODE E9 8412 LIMIT 90.
Basic FOJ..t Tems
--rI _
I
•
Selectica Criteria
_
Control
Term
Rnultinq Output.
EMPLOYEE
SERIAL
-1!!!!L
...!!!!!:...
~
HIRE
~
~
JOB
~
JlDgers, E
Evanson, J
Walters, R
14368
23145
41398
J. Jones
I. Brun
J. Jones
01/64
08/61
10/66
D12
D18
D12
8412
8412
8412
I!'irker, I
98314
R. Martin
11/S8
D12
8412
Record count 73.
End of Inqui%y.
'!'he DEFINE functica allOlls the above inquiry to be reduced to a concise
inquiry state_nt when there is a periodic need for the data.
To!!! !£ thia report the inquiry would be.
I XYZ63 DEFINE REPORT/lOS PERS NAME SER MGR HIRE/DATE DEPT WI. D12,--- 90.1
After MIS accepts the above definition, the buic inquiry is satisfied
with a si~le request.
I XYZ63 CALL REPORT/lOS. I
The s . . output as shown above will result fr_ this inquiry without
entering all tems and criteria involved.
Figure 4-MIS inquiry example
and installation were anticipated, and it was
felt that top management should not be burdened with them.
2. Initial problems may have caused opposition to
MIS, making it difficult to revive interest at a
later date.
3. Operating areas would provide the best exposures
for MIS. It would be better utilized and more
easily justified at this level.
4. The current state-of-the-art was more in line
with operating level management, and further
sophistication of MIS was needed before it
could truly satisfy top management needs,
directly.
Once the approach was decided upon, management
became enthusiastic about MIS. "We like it, when can
we get it?" In many instances, this enthusiasm cooled
slightly when costs and installation time were given.
Management enthusiasm waned even more with the
realization that their assistance was vital to a successful
MIS effort. The laboratory's ATS helped to overcome
346
Spring Joint Computer Conference, 1969
this resistance. It enables potential users to better
evaluate the benefits and capabilities of MIS and to
relate them to the solution of their specific informationgathering problems.
After this initial canvass, it was obvious that a system such as MIS/360 was needed in the laboratory and
could be justified. An initial proposal was made to
laboratory management showing areas of potential use,
hardware requirements, and cost. It was tentatively
accepted with the requirement that hardware needs
be incorporated into the overall Computing Center
equipment plan to ensure maximum equipment utilization at the lowest cost. Many passes were required
before a meaningful equipment plan was developed and
the required equipment ordered.
In parallel with equipment planning, applications analysts were assigned to areas where ~\1l~
had the greatest potential. They began detailed systems
analysis to precisely define how ~IIS was to be used
and what procedures and programs would be required
to support it. This took more manpower than was
originally anticipated. Each application area took
approximately one man, full time for two to three
months, to accomplish all tasks necessary to effectively
implement }lIS. These tasks included learning the
area's mission; understanding its problems and needs;
relating }HS capabilities to these needs; defining reports; making programming modifications to existing
batch systems where required; preparing .\US table
cards; ordering and installing terminals, data sets, and
telephone lines; and educJ.ting the personnel in each
area.
As more analysts and application areas became involved, the original organization plan became unworkable. A terminal systems group was established to
coordinate all ~vns efforts in conjunction with the other
systems programming groups in the department. The
group's responsibilities included:
1. Coordination of all ~ns application areas.
2. :\1IS programming and support.
3. Control of MIS equipment ordering and installation.
4. Pre-analysis and feasibility studies of new
applications.
5. Control of l\US control tables. editing. and
storage allocation.
6. .MIS user education.
7. ~"ns cost center control.
This relieved the applications analysts in the other
systems groups from many time-consuming tasks not
directly related to the customer's problem. This group
was also responsible for an in-depth analysis and im-
plementation of ~IIS applications not related to an
existing batch processing system.
By February of 1968, there was a solid :\IIS installation plan with definite customer commitments. This
plan called for a year-end target of 20 lines and 35
terminals. The IB~l System/360, :\lodel 50, was installed in :\Iarch. By April 1968, the initial files were
loaded and :\IIS became operational. (See Figure 5 for
1IIS Planning and Installation Phases.) In :.vIay, the
first serious system problems arose. These were a combination of hardware and software difficulties and took
almost three weeks to resolve. These problems were not
unexpected; with a real-time terminal system start-up
problems were anticipated. Since then only minor
problems, which were quickly resolved, have marred
system performance. Statistics show a steady growth
in transaction load, increasing from 600 inquiries per
week in early June to 2700 inquiries per week in October.
A vast amount of preliminary work allowed the original ~IIS installation timetable to be followed almost
to the letter. Figure 6 shows actual installation dates
for the various application areas; as shown, the yearend plan to install 20 lines with 35 terminals was substantially exceeded.
During the first six months of operation, installation
target dates were slightly behind schedule. vVithin a one
month period, the demand and commitments were
such that not only were end-of-year objectives exceeded,
but there was a queue of areas demanding :.vns service.
The implementation effort reversed. Instead of a
struggle to develop the required }IIS base, it was now
an effort to install new applications within a reasonable
time without exceeding system capacity. This was not
unexpected. After :\IIS had started to prove itself and
its capabilities were better understood, the demand
went up accordingly. As a re~mlt, the effort::; of the :\IIS
system group were redirected. :xew plans were developed for increasing 31IS capacity to satisfy the expanding needs of the laboratory.
User education was a crucial effort throughout the
}IIS implementation period. The objective was to
formalize the education process so that all users received
the same instruction and to accomplish this with
minimum expenditure of Systems and Procedures
manpower. The classes were conducted in three half-day
sessions. Work periods and terminal operation time
were integr9J parts of the sessions, Two people conducted each class, and the major portion of each session
was followed by problem-solving work sessions. These
sessions were the key to understanding ::VIIS.
AIlS applications
:\USj360 has been applied in various areas, including
On-line Information System for Management
1966
1967
J P M A M J,J A SON D
J F M A M J1J A SON 0
I
~erall
Study of MIS Needs in Laboratory
4
Preliminary Presentations to
Key Laboratory Groups
4
• I
I
I
•
.,
.,~proval
!Laboratory Management
Equipment Approvals , Equipment Ordering
'III
rder
--..1
I
r
I
Testing of Pilot Applications
on CHQ-MIS System
MIS Feasibility Studies and In-Depth
Systems Analysis throughout Laboratory
,
I
I
- User Manual
}
- Systems Analysis Manual
- Internal Procedures (Pile
Load, Tables, Operation)
J
A
S
0
N
D
No.of Lines
12/31/68
2
2
Purchasing
1
1
1
Coq>uter Services
1
1
1
2
Facilities Services
1
1
1
S5P Reports Management
1
1
1
Financial Disbursement
1
CustOI1lll Syatel1lll
Engineering
3
5
8 110 110
Electronic COIIIpOIlent
Information Syate.
I I
1~2
PIS APAR Control
1
Enqineering Education
I12
2
4 f-- ~
2
Budgets/Ana1yds
1
Memory Products
1
CoqIOnents Division
14
1
4 ..
I
1
OOC. . .nt COntrol
1
14
1
2
3
I
2
1 ..
5
3 ..
1
1
2
2
1
1
1
1
3
2 ..
EIS Project Control
1~ 1
1
PIS System Test
1
f-----
1
1
TERMINALS
7
13
17
21
25
28
33
37
38
LIliES
7
13
15
16
19
21
24
24
24
• of Areas Using MIS
7
11
12
13
14
15
16
17
17
HOTEl
24
The asteriaked applicatione invol_ MIS Network •• The.e MIS
users have IIOre than one terllinal per line into the COIIIputer
and as a reau1t they share and contend for the line. a . . iqned
to the••
Figure 6-MIS application installation
April 1968 to January 1969
(MIS tenninals operational)
I
-IUS <>p.rotional
$
I
'III
.,
I
I
I
Personnel 5 Recruiting
I
,
I
in~tallation
,•
I
I
Figure 5-MIS planning, analysis, and
J
4
,
I
,
I
~S Documentation Developed for Poughkeepsie
I
!'ll/6t
I
MIS User Education Classes and
Systems Analyst Classes
M
......
I
~IS Operational at Poughkeepsie
'68
Apr.
I
r
Equipment Installation, System Test, and
MIS Installation and Test at Poughkeepsie
APPLICATION
SublDl.tte~
Equipment Deli ry Period
-+
+--------------.,
.... ~
System Design and Programming
for Pilot Applications
1968
JFMAMJJASOND
I
I
I
I
Systems Justification and Approval
~
347
I
schedule
programming, administrative, and engineering activities. This section discusses, in depth, the MIS application in the Custom Systems area and gives a brief
description of other significant areas.
Custom systems
Custom Systems is responsible for evaluating, pricing,
and engineering all special features to released IBM
equipment within the Systems Development Division.
These requests for products outside of the IBlVI product
line are generated by a customer through a salesman.
They result in a Request for Price Quotation (RPQ) ,
which is directed to Custom Systems.
When RPQ's are submitted to Custom Systems,
records are created for each RPQ. Activity against an
RPQ causes an updating of the record. Data that are
recorded include RPQ number; description; estimated
and actual costs to develop, manufacture, and install
orders placed against any RPQ; customer's name and
the IBM machine-type. A system of batch-processing
programs enables updating and control of the data base
that contains pertinent data associated with all RPQ's.
The master files that comprise the data base are periodically loaded on the MIS System. These files are:
The RPQ statistical file contains a record for each
RPQ that is received in the Custom Systems Record
Department for each Laboratory location. The file is in
;~48
Spring Joint Computer Conference, 1969
RPQ number sequence. It is used to provide both
statistical data and the status of a particular RPQ.
The Laboratory order file contains a record for each
order and for the work in process at a Laboratory. It
is in order-number sequence within RPQ number. The
file contains such detailed order data as machine and
model on order, scheduled shipment date, customer's
name, and quantity ordered. The data in this file are
used to analyze the order phase of RPQ processing as
it pertains to each Laboratory.
The SD D order file contains a record of each open
order for every RPQ, whether initiated by a laboratory
or a regional office. The information is submitted to the
Custom Systems Department in Harrison from the
plant order departments. The data are on a year-to-date
basis for the current year only. This file is used to ana=
-lyze order information on an SDD basis.
The RPQ price file is a detailed file of priced RPQ's
that are currently active. It is in machine type-model
sequence within RPQ number. The data are customer,
laboratory, and machine indicative. Information is
available by RPQ number, customer number, branch
office number, region or laboratory, and machine type.
The RPQ cost file contains a record for each RPQ
that has a completed cost associated with it. Detailed
cost estimates and actual cost data exist for those
RPQ's that are priced and eventually ordered. The file
is in machine type-model sequence within each RPQ
number. This file is widely used by management for
budgetary and other financial analyses.
The RPQ reference file contains a description of each
priced RPQ that is active in the RPQ price file. It is
maintained in RPQ number sequence. The data in this
file describe the purpose and capabilities of the special
features for IBM equipment.
The RPQ error file is a control file. Errors detected in
entering and updating data are maintained for examination and correction by the appropriate Custom Systems Department. The corrections should be reflected
in subsequent input transactions. The data in the file
are current as of the most recent batch update.
The Custom Systems network of MIS terminals
consists of four lines with 14 terminals contending for
these lines. These terminals are located in the eight
SDD Laboratories, and four Data Processing Division
Regions,. and at Division Headquarters in Harrison.
This network allows sales personnel, Custom Systems
engineering groups, and management to interrogate
the system for RPQ descriptions, to analyze orders,
to determine which System/360 systems are getting
the most RPQ's, to see which customers are making the
requests, and a host of additional information. The
immediate availability of such information reduces
distribution and mailing costs of reports and reference
lists, enables sales personnel to be more responsive to
customers, and reduces redundant engineering efforts
at IBM Laboratories.
As an example of the use of MIS as...~ume that a
Data Processing Division (DP) industry representative
is selling a System/360, Model 65 to an airline. He
wishes to know what RPQ's have been requested for
that system by airline customers. He would interrogate
the RPQ statistical file with the following inquiry to
get his report.
j
Inquiry
XXXX RPQSTAT INDUSTRY CLASS
EQ Tl SYSTE~V1 EQ 2065
RPQ/NU~IBER
CUST/NAME B/O DEVICE.
(NOTE: XXXX = Security Code,
B/O = Branch Office)
Report
RPQ
CUST
NU:\fBER N A1VIE
B/O
A72097
E62077
ABC Airways 123
Bird Airlines 456
G18999
Transport Co. 789
DEVICE
NAME
Cable Extension
~lodify 7094
Emulator
Console Change
This answer might lead him to an inquiry of the RPQ
reference file to obtain a detailed description of the
RPQ, and to the RPQ price file to determine its price.
(Future plans for MIS will address a multifile interrogation capability with a single inquiry.)
To cite another example, suppose that Custom Systems management wishes to know the total rental for
all RPQ's that are ordered, with a subtotal for each
region. This inquiry would interrogate the SDD order
file.
Inquiry
XXXX SDDORD CHARGE EQ R SUBTL/LH
REGION
CALC TOTAL/RENTAL 8.0 = QTY *
UNIT/CHARGE NO/DTL.
In this inquiry, CHARGE is a field name and identifies which RPQ's are purchased or rented. SUBTL/LH
indicates that subtotals are wanted for each regional
office from low to high. CALC tells the system that the
next field is not in the record and must be calculated.
The 8.0 defines the TOTAL/RENTAL field size, with
no decimals wanted. The TOTAL/RENTAL field is
calculated by multiplying two defined fields, QTY and
On-line Information System for Management
UNIT/CHARGE. NO/DTL tells the system not to
print detail lines.
Report
REGION
ERO
GEl\1
~IWR
WRO
(TOTAL)
TOTAL/RENTAL
100,000 {fictitious numbers)
98,732
111,234
~A.
Q7'>
VV,UI.,
346,838
Summary description of MIS applications 'tn process
349
Facilities services
Initially, two files are utilized: (1) Plant Engineering
Detail Project file, arranged by purchase order number
within project number, and (2) Laboratory Facilities
Services Summary Project file, arranged by project
number. These files contain such information as
estimated, committed, and actual costs for each facilities
improvement or rearrangement project. The information is used for statistical analysis on projects, types of
projects, vendors, etc. Seventy-two fields of data are
available for interrogation.
Systems and procedures reports management
Personnelreoords/recruit~
The Personnel Data System (PDS) has been used to
create a 2000-character record containing significant
information about each employee. Data fields such as
promotion dates, salary information, year of degree,
etc., can be addressed for an individual, or a group of
individuals. ~1ore than 240 fields of information can be
interrogated.
The Recruiting file contains all processing information about applicants, regardless of status, for the
current recruiting year. When an individual applies for
a .professional position at IB':\1 Poughkeepsie, a record
is created. This record remains in the system until
appropriate action has been taken and until recruiting
year-end. Forty fields of data can be interrogated,
including method and date of contact, test scores,
departments visited, areas offered and accepted, acceptance date, etc. The Recruiting department uses this
file in day-to-day operations, in the generation of weekly
and monthly reports, and in year-end analysis work.
Financial disbursements
The initial files loaded are the Travel Accounting
file and the Accounts Payable department's Request
for Purchase Rejection file (RPR).
The Travel Accounting file enables management to
analyze such travel information as who went where and
how much did it cost. This file contains all closed records pertaining to employee travel advances and expenses, along with statistical and personnel information.
Forty-four fields of data can be interrogated from the
terminal.
The Accounts Payable file contains information about
RPR's. RPR's can be analyzed, and recommendations
about vendors can be given to management. Ten fields
of data can be interrogated, such as purchase order
number, ship date, vendor name and number, and
disposition.
The Reports ':\lanagement file includes key data about
all reports prepared by SDD Poughkeepsie, such as
report title, preparer, requestor, frequency, cost, number of readers, subject, and report number. Thirty-five
fields are available for interrogation. A divisional and
corporate system, utilizing the MIS system as a basic
information retrieval tool, is planned for the future.
Electronic component information system
This JUS application provides a monitoring and
reporting system used to track engineering change data,
to determine whether objectives are being met, and to
provide input to other systems, such as the logistics
simulator. Events are recorded for each part number
tied to a Request for Engineering Action (REA) or
E/C. Typical data fields include origin and response
dates, REA type, ship dates, machine group or part
type impacted, recycle codes, E/C break-in dates, etc.
Between 40 and 50 fields are available for interrogation.
This is a network-type application involving SDD
Laboratories, Components Division, Systems lVlanufacturing Division, and Field Engineering, with three
~UIS lines allocated at this time.
Purchasing
The automated purchasing system includes }IIS
as an integral part of its overall design. Currently,
the .:\HS file is a product of a series of System/300'
batch-run programs. Future JUS capability will, for
the most part, eliminate periodic creation of reports
via the batch-run mode. Reports are created through
JIIS inquiries on a need-to-know and exception basis.
Two files are accessible through 1\11S/360: the Purchasing .:\Iaster file that contains information about
open purchase part orders and open interplant part
orders; and a daily receiving file that contains records
of a day's receiving activity.
350
Spring Joint Computer Conference, 1969
Engineering education
A combined personnel-education data file for SDD
Poughkeepsie employees serves as input to the data
preparation program that creates the -:.vns educationload tape. The data preparation program is run on a
quarterly basis. It extracts as output all management
education courses, graduate work study courses, Syracuse University program courses, and all Engineering
Education and Voluntary Education courses taken
during the most recent four-year period. There are 62
fields available for interrogation. Some of the more
perti..'1ent ones are date of hire, educational level, educational objective, school codes, course number, course
level, and course completion codes.
Document distribution and control
This area coordinates and controls the distribution
of documents in SDD Poughkeepsie. 'Vhenever a document is to be circulated, such pertinent information
as those who should receive it and their respective addresses are obtained from the distribution master file.
:\1]S loads the distribution master file and makes it
available for terminal interrogation. Two terminals are
installed in the area. One is used for information
retrieval and . limited updating; the other is equipped
with a special pin-feed platen that allows ~n8 to print
address labels for numerous distributions having a
relatively small volume of labels.
Budgets/ Analysis
This financial area handles budgetary control and
analysis for the SDD Poughkeepsie Laboratory. Two files
are loaded in MIS. One consists of the entire 12 month
Budget master; the other is the Variance report master.
The Budget master file makes the details of eaGh area's
budget available for terminal interrogation. The Variance report allows the financial area to analyze all areas
for any variances (planned budget vs. actual expenditures) either on a current-month basis or on a year-todate basis.
Applied programming analysis report (AP AR)
control
The file consists of the AP AR master, with 33 fields
available for interrogation. It includes AP AR checkpoint dates, associated AP AR codes, areas, etc., so that
every phase of APAR activity is available for analysis
and manipulation by 1\118. An :\1IS network~ for AP AR
control is a future possibility.
~emory
products
This area uses an .:vIIS file to monitor and control the
memory engineering projects. The file contains a profile
record for each unique stage or phase of the memory
engineering project as it goes through development.
Fifty-two data fields are available for interrogation.
Some of the more pertinent fields are engineering project number, project phase code, estimated start and
completion dates, revisions to start dates and completion dates, status codes, cycle time, and problem status
pointers.
CONCLUSION
The :\USj360 System described in this paper is an integral part of the operating and management activities
of the Poughkeepsie Systems Development Laboratory.
Users of the system have found that it aids them in
"doing business a better way." They can evaluate more
things in more ways and in less time, allowing a better
base for the decision-making process.
The system continues to grow-in numbers of lines,
in numbers of terminals, and in numbers of inquiries,
which is most indicative of how much a part of everyday
operations :\lIS has become. It is intended that the
system will grow as its use grows. Future plans call for
a larger CPU and improved :\1IS software with additional capabilities. These activities must be continuous.
As user demands upon the system increase, it must be
made more responsive. It must exhibit higher degrees
of sophistication in its capabilities. These requirements
~ust be met if :\IIS is to continue to be a dynamic and
valuable management tool.
ACKNOWLEDG:\iENTS
MIS program development was the responsibility of
Mr. George Dath of Corporate Headquarters, with
portions of the effort accomplished at SDD Kingston.
SDD Poughkeepsie and FSD Huntsville.
During the installation of l\!IIS at Poughkeepsie, the
systems analysis and programming efforts were accomplished through the cooperative efforts of S&P personnel, computer operators and management, and the
operating people involved within each application area.
At the inception of the project in 1966, the contributions of :\lr. W. D. Timberlake and Mr. B. H. l\1atteson, Jr. (former managers of S&P and Computation
Services) during the planning and justification cycle
were particularly significant.
Computers and Congress
by EDMOND S. MESKO
Technical Information Services Company
College Park, Maryland
INTRODUCTION
The Instititute of Management Sciences (TIMS) and
the Washington Operations Research Council (WORC)
co-sponsored two meetings in the early months of 1968
in the Rayburn Building on Capitol Hill. In these
meetings, these professional associations held what was
probably the first dialogue between the ::\1anagement
Science community and Representatives of the U. S.
Congress. The Representatives were Congressman
Robert ::\1cClory of Illinois and Congressman F. Brad.;.
ford Morse of ::\1assachusetts.
The purpose of these meetings was to search for areas
where .:.YIanagement Science techniques could come to
the aid of the Legislative Branch of the Federal Government. N either th~ members of the House of Rep~'esenta
tives, who were the guest speakers at the meetings, nor
discussants, nor the members of the audience had any
recourse but to say, "YES! l\1anagement Science
Techniques can help Congress!" But as suggested by
Congressman J\Iorse, the 1Ianagement Science community must make the management science terminology more "fashionable" so the members of Congress
will add it to their vocabularies, and must also "sell"
Congress on the great potentials of :\Ianagement Science technology.
Background
Congressional record
There have been several articles in the Congressional
Record regarding ADP assistance to Congress. One
article appeared on October 19, 1966. 1 This was the
introduction of a bill by Congressman ::\1cClory of
Illinois. The bill authorizes the Legislative Reference
Service of the Library of Congress to make use of automatic data processing techniques and equipment in the
performance of its function in support of the Congress.
Congressman lUcClory noted the growing dilemma of
Congressmen and their staff's to screen, sift and extract
significant information from the ever increasing volume
of data they receive.
Some of the very basic information that the Congressmen must know includes: status of current bills, legislative history of bills, schedule of committee hearings,
budgetary data and facts and figures regarding everything from informat.ion about his constituents to information about unidentified flying objects.
Another article appeared in the January 30, 1967
Congressional Record. 2 In this article Congressman
McClory introduced an abridged version of a study
prepared by the Legislative Reference Service of the
Library of Congress. The study was a review of various
ways in which computers might be used to aid the
Congress, Congress as a unit, each chamber of Congress, the committees of Congress, and the individual
Congressman.
The third article in the Congressional Record was
introduced by Congressman Tom Railsback on January 29, 1968. 3 The article is Congressman ::\1cClory's
speech to the joint TIl\1SjORSA meeting on January
17, 1968. In his speech Congressman ::\1cClory reviewed
the need for AD P equipment to aid Congress. He also
described a recently installed on~line terminal system
which was installed in the American Law Division
of the Legislative Reference Service of the Library of
Congress. These terminals enable the Legislative Reference Service to store on magnetic tape descriptions
of all bills and resolutions' introduced in the 90th Congress. This data will be used to compile and list the
"Digest of Public Bills". Eventually the system will
enable a Congressman to retrieve any bill by number,
title or word descriptors. When we realize that 26,000
bills and resolutions were introduced in the 89th Congress, we can begin to see one small area where Congress
can be aided by ADP.
In his speech Congressman McClory reviewed his
statement which he inserted in the October 19, 1966
351
352
Spring Joint Computer Conference, 1969
Congressional Record. He also mentioned that the bill
which he introduced in that Congressional Record still
is pending.
Congressman McClory mentioned in his speech a
fact that was surprising to me. He noted that Congress
in 1967 appropriated over $1.2 billion for the 3,000
computers in use by the departments of the executive
branch of the federal government. However, the Congress has refused to appropriate one-thousandth of
that figure to equip itself with an ADP capability.
Studies of Congress
There have been several studies and books regarding
Congress and Congressional reforms. I will discuss only
those areas regarding ADP. The studies are: the Arthur
D. Little Study that was sponsored by the National
Broadcasting Company, the results of which were made
into a television Special;4 the Twelve Studies of. the
Organization of Congress conducted under the auspices
of the American Enterprise Institute for Public Policy
Research;5 the Dartmouth College study, which was
directed only to the House of Representatives;6 We
Propose: A Modern Congress, which is a series of articles by members of Congress;7 and the Report of the
1965 Joint Committee on the Organization of the Congress, which is now represented in bills before the SenateS and the House.9
The common thread running through all the studies is
the problem of obtaining timely, accurate, complete
and relevant information for decision making. During
the Dartmouth study,6 four out of five Congressmen
said that the lack of information and complexity of
decision making were the major problems preventing
Congress from perfOlTIling more effectively. This is
true for the individual Congressman as well as for the
Committees of Congress. The Dartmouth study was
in the form of 32 reform proposals drawn up by the
study team. The proposals were developed after a search
of the extensive literature written about the Congress.
The team members then asked a total of 116 members
of Congress what their thoughts were regarding the 32
proposals.
The need for better information was also mentioned
in the Report of the 1965 Joint Committee on the
Organization of the Congress.s The report urged the
use of automatic data processing to provide expanded
budget information to members of Congress to aid in
Congressional fiscal control and budget evaluation. The
result of this report has been formed into bills now
pending in Congress. 8 ,9 I will discuss this pending legislation in a later section. This report was an internal
study of Congress. The study was co-chaired by
Senator :\1ike :\Iollroney and Representative Ray
2\1adden.
The need for a computer to better analyze the budget,
as well as the hundreds of other subjects, is also mentioned by David Brinkley, the KBC correspondent,
in the introduction of the book, "Congress Needs
Help.'" One of the findings by the Arthur D. Little
study team was that Congress does not take advantage
of automatic data processing equipment to facilitate
its work. Because of the massive volume of data input
to Congressmen and Committees, it is only natural to
turn to high speed, large capacity computers. The
conclusions and recommendations of the study call for
the use of the computer to manipulate the data into
usable information.
The American Enterprise Institute for Public Policy
Research is a nonpartisan research and educational
organization. The purpose of AEI is to assist legislators
and educators with studies of current issues of national
significance. AEI compiled twelve studies of the Organization of Congress into the book, "Congress: The
First Branch of Government."5
In the study, Availability of Information for Congressional Operations,5 it was found that the complexity
of decision making and the lack of information are the
difficulties that were most frequently cited by the
l\1embers of Congress. In the study, the Committees in
a Revitalized Congress,5 it was noted that the information problem is not one of scarcity of information, but
an abundance of information, most of which remains
unassimilated and undigested. The study, Information
Systems for Congress,5 advocates the development of
automated information processing systems to provide
the information for legislative decision making.
ADP applications to Congress
Before we discuss how ADP can be applied to Congress, let us first categorize the working parts of Congress. 10 The functional areas of Congress can be divided
into five parts:
1. Congress as a Unit
2. Each Chamber of Congress
3. Committees of Congress
4. Individual Congressmen
5. Political Parties
\Vithin some of the functional areas there are two
kinds of information that is required: legislative information and administrative information. ll
The legislative information can be divided into informa.tion for current problems and information that
could be relevant to future areas of concern,
Computers and Congress
The legislative information applicable to current
problems and the legislative information being compiled
for future matters can be divided and ordered by subject.
Let us now look more closely at the functional areas
of Congress and begin to determine their information
needs. 6
Congress as
a,
unit
This includes both Houses of Congress. Certain kinds
of information is relevant to both the House of Representatives and the Senate. A centralized data bank
should provide:
a. Legislative Information
1. Status of Pending Legislation. Considering
that there are about 26,000 bills and resolutions submitted for action in each Congress,
we can see that there is a need for a central
file of this legislation. At this time there is
no one place where a Congressman can easily
find information regarding pending legislation.
A Congressman should be able to have access
to a centralized file of all legislation introduced into either House of Congre:;:s. He
should be able to search for this information
by the number assigned to the bill or resolution, or by subject. To go one step further,
each Congressman could have his "interest
profile" stored in the computer system and
have this "interest profile" automatically
search each piece of proposed legislation
that enters the data bank. The "interest
profile" would represent the personal interest
of each Congressman. When the key words
of the "interest profile" would match with
the key words of the bill or reeolution, an
abstract of the bill or resolution would automatically be sent to the Congressman as a
printout or output on his own terminal in
his office. Included with each bill or re80lution should be pertinent information such as
the name and number of the bill, the 8ponsor,
the content of the bill, related bills in the
House or Senate, past legislation regarding
both bills and laws germane to the current
bill, and status of action on the bill.
2. Lobbyist Activity Information. Lobbyists are
one of the prime sources of information for
Congressmen. All lobbyists are required to
register either with the Clerk of the House or
the Secretary of the Senate. These liRtR are
353
then published each quarter in the Congressional Record. However, they do not
provide much information to the members of
Congress.
To assist the members of Congress it would
be beneficial to record all lobbyists and
related information in a central data bank.
A Congressman should be able to search a
data base through a remote temlinal to
determine if an individual is a registered
lobbyist, his employer, the legislation he is
concerned with, total sum of contributions
he receives and the source, his past history
and technical background, including his
speeches and publications or editorials.
a. Access to the Legislative Reference Service. The
ability of being able to access the Library
of Congress' imaginary computerized data
banks through the Legislative Reference
Service (LSR) is potentially a very powerful
tool. The Library of Congress is a vast storehouse of information. While the potential is
great, the implementing of the system will
not be easy.
However, to review a point raised in the
TE\1SjWORC meeting, the American Law
Division of the Legislative Reference Service
of the Library of Congress has installed online terminals which enable LRS to enter and
store on magnetic tape descriptions of all
bills and resolutions introduced into Congress. Eventually a Congressman wi1l be able
to recall a bill by number, title or word
description.
4. Legal Information. The University of Pittsburgh Health Law Center has recorded on
magnetic tape the entire U.S. Code of Laws.
I t is possible to search the tape and select all
the laws within a given subject and also it
is possible to find laws pertaining to a particular subject but entered under different
headings. Included in this system are the
complete codes of several states, the U.S.
Supreme Court Decisions since 1950, the
Internal Revenue Code and Regulations, as
well as other legislative and. court information.
Other legal information now in ADP form
includes the Department of Defense sponsored Project LITE (Legal Information
Through Electronics), legal information in
several other Executive Branch agencies,
and other legal information held by states,
:354
Spring Joint Computer Conference, 1969
private organizations and several U.S. universities.
b. Administrative Information
1. 1ndex-C aialog of Congressi()nal Doc'wnents.
This could include - all the Congressional
documents published in either House of
Congress. An example could be a listing by
subject or related category of all the published
committee hearings.
2. Congressional Employee Payroll.
3. Legislative Telephone Directory.
Each chamber of Congress
The information required here would be relevant
eit.her to the members of the House or Senate, but not
to both.
a. Legislative Information
1. Location of Bills. A Congressman in the
House or Senate should be able to locate a
bill that was introduced in his Chamber and
also the status of the bill. He should be able
to find out the history of action taken on the
bill, whether it is in Committee or not,
amendments to the bill, Committee votes,
floor votes, scheduling ·for future action, and
sponsors of the bill.
The bill should be able to be retrieved by bill
number, sponsor or subject.
2. Vote Information. When the voting bell sounds
in a Congressman's office, he must go immediately to his chamber to vote on a subject
about which he may know very little. Currently the chamber based information regarding 9, vot,p usually comes from a colleague
on the floor who knows something about the
subject or else even by the doorkeeper.
With a terminal in his office, the Congressman could be able to get an abstract of the
bill on which he is being mustered to vote.
This could give the bill number, sponsor and
legislative history, and pro and con arguments.
3. Automated Voting. Automated voting is now
done in several foreign countries and in some
of our states. However, automated voting is
more a political problem than a technical
problem. I will not summarize the pro's and
con's, but merely say that it is technically
very feasible.
Committees of Congress
The Committees of the House and Senate conduct
the bulk of the legislative work in Congress.
a. Legislative Information
1. History of Committee Action. Each Committee
should have a history of all the bills th9"t fall
within its jurisdiction. The bills should be
sorted by subject and should include related
information such as the sponsor, the Congress
in which they Were introduced, the bill's
provisions, whether or not any hearings were
held, record of information supporting or
opposing the bill, action by the other chamber on similar bill or bills and whether the
bill becomes law.
2. Appropriation Information. This is the area
in v~lhich there is the greatest need for an
information system. There is no lacking of
appropriation data for both current and past
expenditures. However, correlating this data
into usable information is still a problem.
This is not only true for the budget review
within a single committee, but there is also
a great need to have a cross-committee
review of the budget. What is ~signed to one
committee can be directly related to a matter
in another committee. The introduction of
the Planning-Programming-Budgeting System (PPBS) may provide the government
with an added impetus to convince the
Congress that a computer could be used as
a tool to aid in the review of the budget.
The appropriation information should include
statistics on past and projected budgetary
expenditures for each agency of government.
The information should include all appropriation pending for an entire program and
not just the funding for the individual segments.
Unfortunately, getting an across-the-board
review of the budget is another area where
the political problems of developing such a
system are equal in scope to the technical
problems.
3. Congressional Overview. One of the prime
functions of Congress is to overview executive
agencies. For example, Congressional overview of the Space program is a function of
the Senate Committee on Aeronautical a.nd
Space Sciences and the House Committee
on Science and Aeronautics. These committees should have the information to
examine appropriations for the Space program and to correl[l,te phwned events and
Computers and Congress
proposed expenses with historically related
data.
4. Subjects Under Committee Jurisdiciion. Each
committee is charged with maintaining an
expertise in specific areas. These particular
areas are defined in the "Rules of the House
of Representatives" and the "Senate Manual." The committee members should have
access to significant and pertinent information relating to each of the subject areas and
should have the ability to browse through
this information such as we do when we look
"in a library's catalogs.
b. Administrative Information
A schedule of all committee meetings should be
maintained to enable committee members to
better plan their time. ~Vlembers of the House
and Senate may belong to more than one committee.
Individual Congressmen
Congressman ':\iorse, in his discussion before the
joint TLVIS/WORC meeting in the Rayburn Building,
said that his workload is about 75 to 80 hours per week.
I t would be crystal ball gazing to prophesy that computers will reduce his workload to 60 to 65 hours per
week. However, there is no doubt that ADP could
help Congressman ::\lorse make more efficient use of
his 75 to 80-hour work week.
a. Legislative Information
1. Personal Information. Each Congressman's
office should be equipped with an on-line
system to handle his own personal information file. The system should fit the individual
Congressman's needs. Each Congressman's
interest as well as style of operations vary.
The file could be divided bet\veen the Congressman's special long-term interests and
current legislative obligations.
The long-term interests could be public works
projects within his district or possibly a
strong interest in a national matter such as
water or air or noise pollution.
The file of current legislative matters could
include his voting record on a particular
subject, a summary of pending legislation,
a summary of his constituents' attitudes,
and a recall of his public philosophy that he
expressed in speeches, statements to the
press and in various publications.
.
2. Reference File. Each Congressman must wade
through a mountain of data everyday. He
355
can scan some of the reading material, but
he must read other material sentence by
sentence. A Congressman should have a
system that could retrieve information based
on his own key words. This system could
either present a listing of the relevant documents or else it could project the written
page on a screen.
b. Administrative Information
1. Re-election Information. The Congressman's
prime issue is to get re-elected. A Congressman must know the total amount of campaign contributions, a list of the donors and
the amounts they donated, the donors'
interests, the amount spent in a re-election
campaign, and the manner in which it was
~ent. He must also know the voting blocks
within his district. These include the unions,
business leaders, civic leaders and the interest groups, such as a farmer's association.
The system should also be able to analyze
polling data and election returns.
2. Constitutent Data. Each Congressman should
also have access to the names and addresses
and other relevant information to each of
his constituents.
As you can see, this administrative information deals with a very sensitive subject.
::\,iany people feel that this would lead to the
"Big Brother" state described in George
Orwell's 1984. Too much information in the
hands of the wrong people is bad. Too little
information in the hands of the right people
is bad. It would be a difficult task to justify
every bit of information that went into such
a data bank. However, in the near future this
is precisely what must be done. Technical
potential must be tempered and guided by
social conscience.
Political parties
Each of the political parties has National and Congressional Committees. The Political (Party) Committees of Congress include both the House and Senate.
Each of these Committees has a specific purpose and
are, therefore, interested in specific information. Some
of the committees for both Republicans and Democrats
are the Policy Committee, Steering Committee, Personnel Committee and Campaign Committee. Information required, therefore varies from campaign information to the planning of political strategy in the
House or Senate.
356
Spring Joint Computer Conference, 1969
The National Committees could include policy information relating to party objectives and policies; information by states or areas of the country; or information
by categories such as the Space program, or air or
water pollution, or information on the overall policy
toward cities. Other information could include the
opposition party's policies and objectives and the
arguments against those policies and objectives.
Other information could include administrative
matters. This would include voting information such
as campaign planning and funding, the names and
addresses of state and local leaders, the opposition
party's strong and weak areas, and the policies and
political backgrounds of voting blocks possibly divided
by economic strata, ethnic groups, and/or geographic
areas.
Congressional committees
Any of the above-mentioned candidates for ADP
applications could be discussed more deeply. However,
we will discuss only the problems relating to the standing committees of the House and the Senate. There are
20 standing committees of the House of Representatives12
and 16 standing committees of the Senate. I 3 The
Senate Manual and the Rules of the House of Representatives list the standing committees and the power
and duties of each of the standing committees. The
committees were last restructured in 1946 to better
delineate the jurisdictional areas of each of the committees and to better parallel the executive agencies.
Whether or not this precise delineation of responsibility and attempt to parallel the executive branch is
satisfactory will not be discussed in this paper. However, this situation is mentioned because it indirectly
leads to an example of the problem caused by the current committee structure and how this problem could
be somewhat alleviated through the use of ADP's
ability to provide horizontal integration of a similar
subject.
Horizontal integration with ADP
The House of Representatives has a Committee on
Education and Labor. The Rules of the House of Representatives lists and defines one of the jurisdictional
areas of t.his committee to include "Measures relating
to education or labor generally." The Senate has a
Committee on Labor and Public Welfare. The Senate
Manual defines one of the jurisdictionals areas of this
committee to include "Measures relating to education,
labor, or public welfare generally." Because these
powers and duties are specifically listed in the rules
books of both the Senate and the House, we would
assume that all education matters are handled by
these two committees. However, this is not the case.
It is revealed in the book, "Congress Needs Help'"
that about thirteen different Senate Commit.t.ees;
fifteen House Committees, and one Joint Committee
considered education bills in the 89th Congress. Congressmen would have to go to 29 different committees
to get information regarding education bills in the 89th
Congress. This is an excellent case for justifying a
retrieval system using key words.
Currently, each of the committees has a committee
calendar. The Committee on Education and Labor
publishes their calendar monthly on a cumulative basis
for each Congress. The calendar is organized three
ways: sequentially by bill number, by author, and by
subject. The committee staff updates a ,vorking copy
daily with the same information they provide to the
Legislative Reference Service for the Daily Digest.
The Daily Digest is not cumulative.
A staff member of the Committee on Education and
Labor explained that it was no trouble in his office to
find information in the updated office copy of the Education and Labor Calendar regarding any education
bill in that committee. However, the only way for him
to get information regarding other education bills in
other committees would be to look at the working copy
of each committee's calendar. This would be a very
time-consuming project. He said that there is a need
for a Daily cumulative House Calendar that would
include the status of all bills whether they are in committees or not. This House Calendar could be organized
in the same manner as is the Education and Labor
Calendars. He said that this House Calendar would be
valuable in three ways: time saving for staff members,
more rapid response of Congressmen to constituents,
and more adequate voting information for Congressmen.
This would not be a complex problem to solve. The
data are already there. It would be a matter of compiling
the data in one location and organizing the data in an
integrated data base. This situation would fit in very
well with an on-line information retrieval system using
key words.
History of committee action
One of the prime sources of information for committees is the committee hearing. The word for word transcriptions of hearings are published in a book form.
Most of these transcriptions get to be about the size
of a book. And there is more than one hearing in a
committee. In the House Committee on Armed Services in the 89th Congress there were 102 printed
hearings and special reports, containing 11,848 pages. 14
Computers and Congress
There were also 396 meetings by the full committee
and its subcommittees.
It would be beneficial to have an on-line system
through which summaries of these hearings could be
reviewed using key words. In this manner, the members
of the committee who were at the hearing could refresh
their memories and new committee members or other
Congressmen who were not at the hearings could get a
concise, accurate review of the hearings without having
to work their way through a great deal of extraneous
words.
A spokesman for the Committee on Education and
Labor said that the current information retrieval system is to remember what was said at the committee
hearing or else to read the 300 or 500 page transcript.
Subject under committee jurisdiction
While there are many areas where ADP can assist
the committees of Congress, we must not assume that
all the information for anyone subject will always be
found in the subject file. Staff members of the Senate
Aeronautical and Space Committee get bits and pieces
of infonnation from the Bureau of Census , NASA ,
HEW, Department of Transportation, the National
Academy of Sciences, the State Department and the
airplane manufacturers.
One of the staff members believes that there is no
place for a computer in a committee. The reason given
is that the sources of infonnation are too scattered and
varied and too unstructured to be satisfactorily assimilated and compiled into a unified fonnat. i-'1:uch of the
infonnation is needed on an immediate basis. For
example, a member of the committee requests in the
morning material for a speech to be given in the afternoon. The staff members do not have the information,
but they do know who to call and the right question to
ask.
It is my feeling that the members of the committee
staff are not afraid that the computer will replace them,
but rather are wary that a computer system is not
flexible or dynamic enough to receive, process and output information within the constraints imposed by the
function and purpose of the committee. To an extent
this is true. However, any large organization has routine
input and historical data that can be structured and
processed and presented in a logical and varied fonnat.
When looked at in this manner, the Senate Committee"
seems very similar to any organization.
ADP as a tool for committees
The staff directors and the chief clerks must be made
to believe that a computer is only a tool. It does not
357
dilute the powers of the committee members or staff
directors or chief clerks. It should be made to enhance
their power. It should enable them to better organize
and structure the information they already have and
to p~esent the infonnation in a timely and orderly and
conCIse manner.
A bill to improve the operation of the legislative branch of
the Federal Government
A bill to improve the Operation of the Legislative
Branch of the Federal Government was introduced in
the House9 and SenateS of the 90th Congress. The bill
is the resulting product of ~he Special Committee on
the Organization of the Congress. There are numerous
mentions of areas where ADP can be applied to aid
the Congress.
One area specifies a data processing system for budgetary and fiscal information and data. The bill states
that "The Comptroller General of the United States
the Secretary of the Treasury, and the Director of th~
Bureau of the Budget shall develop, establish, and
maintain, for use by all Federal Agencies, a standardized information and data processing system for budgetary and fiscal data." The Comptroller General is
also required to specify the location and nature of data
relating to various Federal agencies' programs, activities, receipts and expenditures. It is also specified that
the Comptroller General establish within the General
Accounting Office the data processing systems. The
Comptroller General is also authorized the funds to
obtain the services of individual experts and consultants for assistance.
In another part of the bill, each standing committee
of the Senate or House is authorized to contract the
services of consultants or organizations to make studies
or advise the committee with respect to any matter
within the committee's jurisdiction.
The Director of the Legislative Research Service,
i.e., the bill proposes changing the name of the Legislative Reference Service to Legislative Research Service, is also authorized to procure the services of individual experts or consultants learned in particular
fields of knowledge. Also in order to facilitate its perfonnance, the Legislative Research Service may (1)
prepare infonnation for machine processing, (2) process
information by machine, and (3) prepare information
for presentation by machine. The Service has also authorized the funds to acquire automatic data processing
equipment to implement the specified work.
The bill also would establish for the Congress an
Office of Placement and Office ~Ianagement which
would be supervised by the House Committee on House
Administration and the Senate Committee on Rules
358
Spring Joint Computer Conference, 1969
and Administration. The Office of Placement and
Office l\ianagement would maintain for the entire
Congress, a list of private l\1:anagement concerns capable of rendering studies regarding h'1lproving the
efficiency of Congressional operations.
The Senate version of the bill also proposes the
establishment of a Joint Committee on Congressional
Operations. One of the functions of this Joint Committee is to make a continuing study of automatic data
processing and information retrieval systems for use
in the House and Senate and to recommend the implementation of these systems. To assist in this matter
the Joint Committee is authorized to procure the
services of consultants or organizations knowledgeable
in the particular areas.
'Vhile these bills were not passed, there is general
approval and intent among Congressmen to submit
other bills to pursue the goal of adding automated data
processing support to meet congressional needs.
CONCLUSION
I have presented to you the current thought on how
ADP can aid the Congress. The needs and solutions
have been mentioned by members of Congress in
books and official publications of the Congress; they
have been specified in a joint committee study of the
Congress, and they are now documented in a bill
introduced in the 9Ist Congress.
This bill is a door. Beyond this door is a room of
boundless dimensions limited only by our imagination,
technical knowhow and salesmanship. I hope I have
done my part in presenting this door and a picture of
what is behind the door.
ACKNOWLEDGMENTS
I wish to thank Robert Chartrand, the Information
Science Specialist of the Legislative Reference Service
of the Library of Congress, for his encouragement and
for suggesting various references that have substantially
added to my paper.
REFERENCES
1 R McCLORY
An autornatic data processing facility to support tlw Congress
Congressional Record, "Tashington October 19 1066
2 R McCLORY
Congressman McClory recommends automatic data
processing study
Congressional Record Washington January 30 1967
3 T RAILSBACK
Congressman McClory suggests computer uses for Congress
Congressional Record Washington January 29 1968
4 P DONHAM R J FAHEY
Congress needs Iwlp
Random House Inc New York 1966 Chapter 6 7
5 Congress: TIw first branch of government, twelve studies of
IIw organization of Congress
American Enterprise Institute for Public Policy Research
Washington D C 1966
6 R H DAVIDSON D M KOVENOCK
M K O'LEARY
Congress in crises: Politics and congressional reform
Wadsworth Publishing Co Inc Belmont California
Hawthorn Books Inc New York 1966 Chapter 1 4
7 We propose: A modern Congress, selected proposals by tlw
House Republican Task Force on Congressional reform and
minority staffing
McGraw-Hill Book Co New York 1966 Chapter 20 21
8 Senator Monroney, from the Special Committee on the
Organization of the Congress
A Bill 90th Congress 1st Session S. 355
9 Congressman Bolling, "Legislative Reorganization Act
of 1967."
A Bill 90th Congress 1st Session H R 10748
10 R L CHARTRA~D
Computer-oriented inforrnation for tlw U. S. Congress
Law and Computer Technology Vol 1 No 2 February 1968
11 R L CHARTRAND
Congress seeks a systems approach
Datamation May 1968
12 L DESCHLER
Rules of tlw House of Representatives, Ninetieth Congress
13 G F HARRISON J P CODER
Senate manual, Ninetieth Congress
14 Organization Meeting of House Committee on A.rmed
Services, Ninetieth Congress
Washington D C February 11976
15 R L CHARTRAND K JANDA M HUGO ED
Information support, program budgeting, and tlw Congress
~ ew York Spartan Books 1968
Automatic checkout of small computers
by MARVIN S. HOROVITZ
Digital Equipment Corporation
Maynard, Massachusetts
INTRODUCTION
System hardware
The testing of a computer may take on many forms, one
form is as follows. The computer may be tested in a
segmented manner.
To maintain continuous testing of the PDP-8/1 at
its normal clock speed would require a test system with
enormous capabilities. A more practical approach is
to design a system that will test the computer at its
normal clock speed, but only for short increments of
time. The test system hardware can be designed so that
when properly preconditioned by the Test System
Software, it will cause the PDP-8/l to function at normal
speed for the specified interval with no further stimulus.
Time between tests is used for checking the results of
the previous test and to set up for the next. T~is time
is large compared to the actual time spent testing.
This enabled us to use the PDP-8 as the test systems
computer. Design is simplified when the test systems
computer and the computer under test are the same
type machine. Data manipulation by both hardware
and software is facilitated when both machines use the
same word size. Also, a computer of the same type is
usually available in the production area and need not
be a permanent part of the test system.
The test system must have an input peripheral device
for program loading and an output device for reporting
errors. This test system uses a disk for input and a
printer for output.
There is a spEcial interface which acts as a control
and sensing device to the computer under test and is .
completely program controlled by the test system.
'Vith the appropriate commands, the tester will perform the following test functions in the PDP-8/1 under
test through the speci~l interface.
IC
:vrODULE
POWER SUPPLY
:vrEMORY
WIRING
CP TEST (PHASE 1)
,
ENVIRONMENTAL (PHASE 2)
ACCEPTANCE (PHASE 2)
Each of the above segments makes use of either a
dedicated logic exerciser or a dedicated computer or a
time allocated computer system. The IC, MODULE,
POWER SUPPLY, ME~VIORY and WIRING are
assembled and tested prior to the entrance of Phase 1
and Phase 2 testing. This paper deals only with Phase 1
and 2 testing.
Phase 1 testifI.{J
The objective of Phase 1 is to exercise a computer
under test and check the resulting status of that
machine. In designing a test system of this nature a
prime concern is finding any malfunction that may exist
within the computer under test. Each mode of every
instruction, ::\!(emory System, I/O Interface and ::\!(anual
Control must be completely validated. To accomplish
this, initial conditions must be established. The
computer under test (PDP-8/I) must then be stimulated
and the results of the operation monitored for comparison with anticipated data. If an error is detected,
the test system must have the capability of reporting
the error and repeating the test the computer failed to
perform. The system is designed so that the computer
under test can never impede the repeated cycling of
any test.
1. Manipulate any key or switch logic.
2. Simulate memory read operations by transferring data into the memory buffer at the
proper tjme.
3. Sense memory read and write drive pulses produced in the memory address decoding circuits.
:i59
360
Spring Joint Computer Conference, 1969
4. Sense memory jnhibit drive pulses produced
during the memory write cycle.
5. Sense the O:N or OFF state of all jndicator light
source iunctipns.
6. Sense the one or zero state of all timing clocks
such that any timing state or pulse can be activated at will.
7. Control the PDP-8/1 clock speed.
However, in the event of a program wipe-out, due to a
machine malfunction, a programmed high-speed reload
and restart enables the system operator to observe
repeated failures on an oscilloscope. This contjnuous
cycling feature is not possible on a free standing machine
when a wipe-out failure occurs.
Figure 1 shows entjre Phase 1 Test System Flow
Chart and Figure liP shows the actual test station.
The system hardware provides many avenues through
which the programmer may channel his efforts in
attempting to find all existing problems in the computer
under test. Two general approaches will be considered
here, one being diagnostic in nature, the other being a
specification check.
The specification check consists of outlining in detail
every particular operation that the PDP-8/l is designed
to perform. A series of tests is then written using various initial conditions and operands for each operation.
Each test is provided with several check points at which
the test system monitors the state of every available
status function. Every status at each check point has
been predicted by the programmer and is stored in
internal tables of the test system program. If the monitored status is wrong, the comparison of the anticipated
status with the monitored status results in an error
report at the test systems printer.
The approach discussed above does not anticipate
a failure in any particular hardware area at any time,
nor does it attempt to exercise one area of the hardware
The PDP-SI! computer under test
Most central processors are equipped with an operator's console which uses switches, keys, and indicator
lights. Generally, connection of this console is made to
the central processor logic panel with plug-in type
cables. While the PDP-8/1 is being tested by the system,
the operator's console is not used and these cable connections are made to the test system. All manual switch
controls are operated remotely by the test system. The
Test System program can simulate any of the actions
of a console operator from starting and stopping the
processor to observing the indicator lights.
For control of timing, appropriate modules are removed and timing control lines are cabled in from the
test system. Control is such that the PDP-8/1 may be
run at any of several speeds from faster than normal
to pulse by pulse.
The input-output peripheral buss cables of the PDP8/1 are connected to the test system. This affords an
extensive test for the I/O interface in that the injtiated
peripheral commands can be monitored, and the response to peripheral initiated actions can be sensed by
the test system.
During the initial stages of testing, the computer is
exercised without a memory stack. Cables from the
vacant memory area in the computer logic panel to the
test system enable the system to monitor memory read,
write, and inhibit pulses and simulate memory core
changes on the sense amplifier input lines.
When some confidence has been established in the
basic processor control logic and the memory control
circuitry, the pre-tested memory stack and memory
sense amplifiers may be inserted and more advanced
tests carried on. Various combinations of machine
instructions can be loaded into the PDP-8/1 memory
to form test loops that can be initiated and stepped
through much as an operator would do at the operator's
console. These program loops can be started and run
at normal machine speed. Any program can be loaded
and run in this manner which duplicates the condition
of the program running in a free standing machine.
System software
I. =---=~
I' -TTest
I
System Software
II' -
I
I
-1
Output Peripheral
I
I
Device (Printe~
I
I
I
I
TEST
SYSTEM
L_ _
I~~~~~I·
~~~
_ _ _
I~
I
Ij
II II
Comp.1i&r Under
Test
PDP-8/1
'----~
Memory Control
and Sensing
II I
---Switc-h
Contra---'I
and
indicator Sensing
Figure I-Flow chart of Phase 1 test system
Ii
Automatic Checkout of Small Computers
361
Figure l/P-Actual Phase 1 test system
more than another, during a selected group of tests.
It does, however, cause the PDP-S/I to peIform its
specified operations under various conditions and checks
for any sign of a malfunction anywhere in the computer
during all the tests. In contrast to this specification
check, the second software approach is aimed at validating isolated pieces of hardware. The building block
method is employed where previously checked logic is
used to test other areas.
As individual pieces of hardware are tested in small
increments, the table of kno"\\'n functioning logic grows.
Validated logic is considered sound when a new test is
performed. By analyzing the results of many tests,
a failure can be isolated to within a few logic modules.
Using the proposed system allows the programmer to
expand the set of tests whose results may be used to
predict failing modules. This expansion results from the
fact that the system can cause the computer to perform all of its specified functions plus many more, such
as executing time pulses out of sequence, causing program interrupts at any specific time; stopping the
processor clock at any points, etc. In actuality the
building block tests are first used and then followed by
the specification tests. The Memory System is then
integrated with the computers logic. Memory integration tests include exercising memory with simple test
patterns through complex test patterns. This is accomplished by using the PDP-8/1 data break facility.
(Direct memory access.) We now have, for all practical
purposes, integrated the memory into the computer
under test. The final test is to load small test routines
directly into memory and run them at machine speed.
Spring Joint Computer Conference, 1969
362
The results of these tests are constantly monitored
by the test system. Error control is still handled by the
test system. Ultimately through this method, the
entire PDP=8/1 logic and its memory system are completely tested and a complete computer is born.
monitored for evey subdivision of the test. With the
entire test outlined before him and the problem area
pin-pointed, he can formulate his plan of attack, which
TELETYPE PRINTOUT',
Printovt example:
Documentation
~1
Printout meaning:
The more the test technician knows about the tests
being made and the expected responses, the easier it
will be for him to use the test system effectively in
problem solving. For this reason, an extensive set of
documents is recommended. This includes a separate
timing and print out chart for each test programmed.
These charts will list each test system action and the
anticipated computer function monitored.
The system error reports will inform the operator
of the failing test number, a failing subdivision ",ithin
that test, the status that is wrong, and what that status
should be. With this information the operator can turn
to the print out chart for the failing test to get a composite picture of how the test is carried out. Listed, he
Will see the predicted status of every computer function
G~1
S GB
OO~1
No. of
Stole of 8/1
~
~
0001
COIToct
Group
Indicators
Group
Indical""
GB
Defective
Group
~
Goool
BO~1
Number of tests == test which fault occurs in
State of 81 timing = time or cycle of 81 which test fails in
Group Indicators :. registers, states, or significant pulses where test problem occurs
Correct group indication = correct contents of group indicator
Defective group indication = the actual group indication (wrong indication)
--------------------------------------------------------------------------------------GROUP INDICATORS
MA - memory addres,
FR -
fetch reg ister
PC - p~!"oC!'!! CO'_'!"!~!"
M B - memory buffer
ER - execute regi,ter
AC - accumulator
TR - lransfer regi,ter
GA - Group A
SI -
GB - Group B
SC - step counter
M S - maior sta~s
BC - buffered AC
buffered MB bits
Figure 2-'-Error message explanation group indicators
GROUP INDICATORS
i
PC
MA
MB
GA
GB
MS
i
!
I
AC
FR
DR
ER
TR
I
I
I
BI
SC
BC
BMB~
BUFF.
BRK.
BUFF.
RUN
BAC~
BIT
I
EXT.
MA Sf PC
~
~
MB· ~ AC
lINC
PARITY
FM R
PARITY
DMR
PARITY
EM R
I
1
I
..I
...I
..
MAll
PC 11
MB 11
,
:
I
MA~
AND
EXT.
MA'l
EXT.
TAD
MA2
ISZ
--BMB 3
DCA
DR
ER
BIT Sf BIT ~
lOP
1
lOP
2
lOP
(1)
(1)
0
1
4
ADDR.
ACC
2
3
'p'!j~RC'
W. C.
BMBT
JMS
FLOW
4
C. A.
-BMB 5
JMP
BT 2A
5
o F~
--BMB 6
lOT
BTl
6
POWER
CLEAR
DFl
BMB 7
OPR
I
o
--BMB 6
FETCH
I
F2
IF ~
IF 1
I PAUSE
i
ION
IF 2
RU N
I
I
I
:
I
I
I EXEC.
DEFER
j,
AC 11
FR
BIT. ~
BRK.
I
. 1 .I .I
BIT 11
I
BIT 11
!
BIT 11
Figure 3-Group indjp,st.or table
II
SCl
7
SC2
6
I
SC3
,,.I
PONER
OK
BMB 11
9
!
10
SC4
~
SC5
BAC 11
11
Automatic Checkout of Small COluputers
/APCS--6L - TAPE 1
/TESTS 1-17 ARE 1 CYCLE INST.
/
/CLEAR 8/1 (SP-ST,SS)
/INITlALIZE TESTER
/lOAD FETCH REGISTER (SEE FR FOR NUMBER)
/lOAD MARGIN REGISTER (OPEN ENDED TIMING)
/lOAD ADDRESS, EXAMINE
/START S#
/
/lOAD MARGIN REG
/PULSE BY PULSE MODE
/
0001 l NO MEM DONE
0001 LE MA G2576
0001 lE PC G2577
0001 lE MB GOOOO
000 1 lE AC GOOOO
0001 lE GA G1400
0001 lE GB GOOOO
0001 lE MS G4000
0001 lE FR G5325
000 1 lE DR GOOOO
0001 lE ER GOOOO
0001 lE TR G0141
000 1 lE BI GOOOO
000 1 lE SC GOOOO
000 1 lE BC GOOOO
0001
0001
0001
0001
0001
0001
0001
0001
0001
0001
0001
0001
~001
F
F4
F4
F4
F4
F4
F4
F4
F4
F4
F4
F4
F4
/FROM EXAMINE S#. MEMORY CYCLE
NO MEM DONE
MA G2525
PC G2526
MB G5325
AC GOOOO
GA G 1400
G8 G0321
MS GOll0
FR G5325
DR GOOOO
ER GOOOO
TR G0161
BI G5325
Figure 4-Error message examples
363
registers in the printout marked "G" (Good) after
the register. Individual test formats \vill designate
when this is true.
• Column 4 is the "G" or Good number. That is the
number or instruction loaded into or predicted
from the 8/1 under test. They are printed in octal.
• Column 5 is the "B" or Bad number. These are not
included in these listings. The "B" column gives
the incorrect number from the 8/1. They are printed
in octal.
Phase 2
The System Controller is composed of a PDP-8, I/O
peripheral equipment, an Inter-Processor Buffer and a
residing software package.
The obj ective of Phase 2 is to provide the technician
with a quick means of reloading a Maintenance Program to worst case Margin Test a PDP-8/l. It is also
used to automatically accept unattended computers.
The System Controller can be used as a high-speed
program loader, or to automatically run a computer
under test with diagnostic programs in a predetermined
sequence. The programs are stored on a disk at the
System Controller. Many stations can be tied to the
controller's bus for access to the diagnostic programs.
The number of stations fs limited only by the dwell
t;me for servicing a station.
Drawn in Figure 5 is a block diagram of the system.
Each station has a console which has switches that
the operator uses to select a diagnostic program. He
then presses a switch to indicate to the System Controller that he wants a program. Indicators are used
is the most important phase of any attempt at solving
a problem.
SYSTEM CONTROLLER
Error format
• Column 1 designates the Test Number within the
program.
• Column 2 is the check point number within a test.
It may be a number (1 to 7) or a letter-number
combination (i.e., F3, D3, E1, etc.). If a letter and
number, the letter is the cycle name (Le., F =
fetch, D = Defer, etc.) and the number is the
time state in which the test is performed. If a single
number, the cycle and time should be given under
the particular tests format.
• No Mem Done-This indicates the memory was
cycled by either a switch function or by programming command and did not complete its cycle.
• Column 3 gives the abbreviation of the register in
which an error occurred. (See master chart.) Numbers loaded into the 8/1 will appear in some of these
i-------x-- -
-
-+
Figure 5--Flow chart of Phase 2 test system
364
Spring Joint Computer Conference, 1969
to inform the operator of a successful load or an error
condition.
The System Controller connects one station at a time
. to the bus by enabling that station's gates. The station
is then interrogated for program selection. If a program
is requested, the desired program is brought from the
source disk to the extended memory field of the controller and checksummed. From the extended memory,
the program is then loaded into the computer under
test with the aid of an Inter-Processor Buffer (computer
to computer transfer). After the program has been
loaded, the extended memory of the controller is cleared
and the program is then sent back to it from the computer under test. The controller then makes a checksum
test to determine if the program was successfully loaded
If a bit were picked up or lost during the transfer, an
error condition would exist. The operator is notified.
via the station indicators whether there was an error
or successful load (Program loading with overhead 2
seconds) .
When being used as a high-speed loader (Figure
5 IP), the operator manually calls for the individual
Processor Tests from the System Controller. These
tests are designed to catch worst case failures caused
by temperature, vibration and voltage margins. These
are our standard field-oriented maintenance programs.
When being used in the auto accept mode (Figure
5/PA) following a successful load, the computer under
test will be told to jump to the beginning of the program
and run it for some specified length of time. While the
computer under test is running, the controller monitors
each on-line station for errors. If an error exists the Sys-
~11
-!T!'v.
- =- -- --
Figure 5/P-Actual Phase 2 environmental test
syst~m
A ....... ____ L.!_
.l"1.UI"ulUGtl"lC
,..-,, ___ , __
J
\.JIlOC.K.OUl:;
1""'"
or
, ..
~mall
Computers
365
Figure 5/PA-Actual Phase 2 auto-acceptance test system
tern Controller will output the error information on a
printer as well as the operators console. The controller
has the ability to re-try running that program to gather
further information as to whether is is a transient or a
repetitive failure. If the error is catastrophic, the
station will be disconnected from further service. If no
errors have developed after a specified length of time,
the next diagnostic program is loaded and run. After
all diagnostic programs have been run successfully, the
controller will type an accept message for that station
and start the routine over again. After a specified number of hours of error free operation, the computer under
test is ready to be shipped. The auto accept mode of
operation does not require any operator intervention.
CONCLUSIONS
The proposed system provides a very effective tool
for use in debugging new computer central processors
at a production facility. Any malfunction that may
exist within most computer control processors can be
detected and found by using this system. In general
these problems will be found easier when using the test
system than when running a diagnostic program in a
free standing machine.
While many of the details of this system are oriented
towards computers produced by Digital Equipment
Corporation, I believe that the basic idea can be
adapted to a wide variety of computers, produced by
many manufacturers.
The advantages of using a computer test system for
checkout on a computer production line are fast turn
on time, less experienced test technicians, resulting in
greater product reliability at lower cost.
Cryptographic techniques for computers
by DENNIE VAN TASSEL
San Jose Stale College
San Jose, California
INTRODUCTION
The use of systems of secret communications as an
economical method to increase the security of confidential computerized files has stimulated much interest.
Just recently during Congressman Gallagher'S Congressional hearings on privacy, it was repeatedly suggested that cryptographic-type protection should be
used for data communication lines and storage of
confidential information in order to make eavesdropping
an extremely difficult task. 1 Today, one finds the yery
nature of computerized information systems actually
facilitates its unlawful reproduction and transmission
to anyone with the tools and know-how. Unlike information which is stored with scrambling techniques,
information stored in clear form requires no sophisticated technology, nor complex deciphering systems for
either decoding or dissemination. 2 More importantly,
there is good reason to assume that organized crime
and industrial spies have, or will have, the knowledge
and the financial resources necessary to acquire and
misuse the information in most systems now being
considered, including the tapping of communication
lines. Finally, once a piece of information is lost, its
original confidentiality can never be regained. Since information which has preyjously been scattered among
several rather protected and widespread sources is being
collected into one place, wholesale theft of information
is very likely to become a continuing fact of-life for the
American public.
This new pattern of computer misuse must be discouraged by the imposition of severe sanctions as well
as clearly defined safeguards. One dangerous factor of
keeping information confidential is that our society
does not believe its own pronouncements about the
right of secrecy or privacy. In general, the majority of
people will support its own claim on the right of keeping some information confidential but at the same time
will not demand prohibitive action against both govern-
mental and private snooping. While it is obvious that
this reaction says little for society's capacity to be
honest and rational, equally important, this trend
strengthens the possibility that individual privacy may
vanish like the American buffalo.
The main focus of this article is on cryptographic
techniques. This leads to something of a distortion.
While cryptographic techniques are an essential means
of keeping information confidential they are a symp...
tom rather than a cure of the larger problem of privacy.
While this is not the appropriate place to expound the
question of the right of privacy and the relationship of
privacy and the computer, it has been necessary to
give the problem minimal consideration here.
A high degree of secrecy at minimum cost can be
achieved through the use of cryptographic techniques
for the protection of confidential information. The
general principle behind the use of cryptographic
techniques to protect confidentjal information is that if
unauthorized use is inexpedient and costly the price of
such use is raised to such an extent that it is generally
uneconomical to attempt it. The same principle is used
in building bank vaults.
In order to explain the use of cryptographic techniques for computers it will be necessary to preface the
discussion with a brief definition of terms. A PLAINTEXT message is the input message. A CIPHER or
CRYPTOGRAM is the output message; that is, the
message after it has been changed to hide its meaning.
CRYPTANALYSIS is the act of resolyjng cryptograms into their intelligible texts without having possession of the system or key employed. Throughout
this paper the word ENEMY will be used to designate
any persons not authorized access to the messages.
There are two principal classes of cryptography,
transposition and substitution. A TRANSPOSITION
cipher is one in which the letters of the plaintext are
unchanged, but its order is rearranged so that the
368
Spring Joint Computer Conference, 1969
cipher message apparently conceals the clear message.
A ::\IOXOLITERAL transposition is one in which the
transposed elements are the single letters of the plaintext. If the transposition operates on groups of letters
or words, the transposition is called POLYLITERAL.
The agreed upon manner of writing the clear message
into the agreed upon pattern is called the INSCRIPTION of the message. The method of taking off the
letters from the cipher sequence is called the
TRANSCRIPTION.
In a SUBSTITUTION cipher the elements of the
plaintext keep their relative position, but they are replaced in the cipher text by other letters or symbols.
Substitution symbols are ::.\10NOALPHABETIC if a
single cipher alphabet is used and POLYALPHABETIC if two or more cipher alphabets are used.
'Vhen the substitution involves one letter at a time
the cipher is ::\10NOGRAPHIC. In a POLYGRAPHIC
system the substitution is by pairs of letters or larger
groups. ::\Iost cipher systems consist of two parts; a
general method which is fixed, and a key-variable
which changes at the will of the correspondents and
which controls the operation of the basic method.
Key~ are either literal, consisting of words, phrases or
sentences; or numerical composed of figures. 3 Exa.mples of keys will be provided "vith each method.
Transposition methods
Transposition techniques consist of changing the
natural order of a record so that the original meaning
is hidden. A common game with children is to write a
message backwards. The record VAX TASSEL would
be enciphered LESSAT :\"AV. Another simple example
is '.yhen adjoining characters are switched; using thf:
same record, VAX TASSEL becomes AV ~ATSSLE.
Another method of transposing is to take all the even
numbered characters within a record and move them
to t.he first half of the record, and move the odd numbel'ecl characters to the laRt. half of the record, as follows:
VAX TASSEL becomes A ASLV~TSE. These are
simple examples of transposition methods.
During the civil war a simple transposition called the
RAIL FEXCE transposition was commonly used. In
this system a record containing a Social Security
Xumber .503-40-1687 and an hourly rate of $3.12,
(5034016870312), is inscribed along a rail fence as
follows:
5
067
:3
o
4
a 2
8 0
Then the transcription is taken off row by row in groups
of five as shown below:
53067
:32041
801
The rail fence method can be modified to a 3-row,
4-row, or n-row; however the security obtained is
minimal. The key in this method is the number of rows
used.
There are other ways in which records can be scrambled. One of the most common makes use of rectangles
to scramble the message. We can inscribe the alphabet
into a rectangle by using a vertical path as follows:
Q U y
X R V Z.
C G K 0 S W
D H L P T X
A E I
B F J
~\1
,,-'
This transcription consists of taking the elements off
horizontally, as follows:
AEIl\1Q UYBFJ XRVZC GKOSW DHLPT X.
There are many variations of the possible inscription
routes and as many for the transcription. In fact, if the
record is n-elements long there are n! (n factorial)
possible orderings of the elements. Using conventional
geometric inscriptions we may obtain the fo~lowiHg
routes:
1
2.
3.
4.
Horizontal
Vertical
Spiral
Diagonal
A horizontal route can have all the rows inscribed in the
8a.mp. rlirp.ct.ion or in alternating directions. The same is
true for the vertical route. A spiral route may be clockwise or counter-clockwise. And a diagonal route may be
diagonal upwards throughout or diagonal downwardR
throughout, or it may begin either upward or downward and alternate its direction while maintaining a
diagonal path. Thus, there are ten routes in inscriptioll
beginning with each corner of the rectangle, i.e., :.>horizontal, 2 vertical, 2 spiral, and 4 diagonal
routes. Therefore, there are 40 different possible paths
using conventional routes. This method is particularly
fitted to computer usage because of the ease of setting
up matrixes and modifying the path of transcription.
The· size of the rectangle has much to do with the
amount of security obtained. If a rectangle of 64 elements is used there are five possible rectangles, i.e.,
2 X 32,4 X 16, 8 X 8, 16 X 4, 32 X 2. On the other
hand when using a rectangle of size 72 elements there
are 10 possi'ble rectangles, i.e., 2 X 36, 3 X 24, 4 X 18.
Cryptographic Techniques for Computers
6 X 12,8 X 9,9 X 8, 12 X ~ 18 X4, 24 X 3,36 X 2.
The greater the number of possible rectangles the
greater the security.
It is not necessary to use a rectangle that fits the
record length exactly. That is, a record of length 26
can be inscribed into a rectangle of 28 elements. The
unused cubes are simply ignored while the record is
transcribed as it was in the first rectanglar example.
Once the size of the rectangule is known, it is much
easier for an enemy to decipher the cryptogram;
therefore, it is undesirable to use a rectangle the same
size as the record. If partially filled rectangles are used,
much less information is given on the encipherment
method.
Alphabetic keys are often used to encipher a record.
Using the key-word LENGTH, the key-word is placed
over the columns as follows:
L
E
B
N
C
G H I
M N 0
S T U
A
G T
D E
J K
P Q
VW
H
F
L
R
X
N ext, the letters in the key-word are put in alphabetic
order and the respective columns are shifted along with
the letters of the key -word as follows:
E G H L N T
B D F A C E
H J L G I K
N P R lV1 0 Q
T V X S U W
Quite often a key-word is also used on the rows in the
same manner. This method of transposition is called
XIHILIST, named after the Russian anti-Tsarists who
used this method.
Substitution methods
In a substitution cipher the elements of the plaintext
keep their relative positions, but they are replaced in the
cipher text by other letters or symbols. One of the most
simple substitution systems is called a CAESAR system, supposedly used by Julius Caesar. Caesar replaced
each plaintext letter by the third letter after the replaced letter in the alphabet. The correspondence of
each plaintext letter with its cipher letter is represented
in the following table:
plain ABC D E F G H I J K L IV1 N 0 P
cipher D E F G H I J K L ~l N 0 P Q R S
TUVWXYZABCQRSTUVWXYZ
369
The record FORTRAN is enciphered as IRUWUDQ.
The process here is similar to module arithmetic with
base 26. Sometimes a reversed cipher alphabet is used,
but predictably neither method offers a high degree of
security.
A key-word method offers a much higher degree of
security. The key-word is written first and followed by
other letters of the alphabet not in the key-word. Any
letter in the key-word which is repeated in the key-word
is dropped the second time. If the key-word is COKFIDENTIAL the key-word alphabet would be as follow~:
plain ABC D E F G H I J K L
~1
N 0 P
cipher CON F IDE TAL B G H J K .:.vI
PQRSUVWXYZQRSTUVWXYZ
It should be noted that both the letters K and I were
repeated in the word CONFIDE:XTIAL so that when
this word was used to set up the key-word alphabet the
second X and I were dropped and CO XFID ET AL was
used. The record FORTRAN l~ enciphered a~
DKQSQC.J.
Instead of using a key-word cipher alphabet it i~
possible to set up a strictly random ~equence of the
alphabet~ But the additional security obtained is not
much greater t han with the key-word alphabet, and the
key-word system lends itself to use by subroutines and
simple change of the cipher by merely ehanging tlw
key-word.
One disadvantage of all the above ~ubstitution methods is that once it is set up the cipher never change~.
This lesse~ls the security because there are certain statistical and structural characteristics of English word~
that help break a substitution system of this type. For
instance, one is that the most common letter in th('
alphabet is the letter E, so a cryptanalyst ha~ to merely lo?k for the most common letter and chance:,.; are
that it iR really the letter E. Here in their order of importance is a list of the rno~t common letters of the
alphabet E T 0 A X IRS H. There are also certaill
structural characteristicH in English such as the letter l"
always follow the letter Q. Another common characteristic in English iR that eertain digraphs sueh as I'll
appear quite often. AddresseH, dates, (~()BOL and
FORTRAN programs are especially vulnerable to
analysis. By now readers will have observed that the
above systems are not invulnerable by any means, and
that the art of cryptography must require a more COlllplex system than offered so far.
Important systems to consider are those of polyalphabets, that is,' those with more than Olle alphabet.
Clearly, polyalphabets are used to make the enemy'H
work a little more diffieult. A GROXSFELD encipher-
370
Spring Joint Computer Conference, 1969
the substitute is S. To encipher R with key one, begin
at R and count forward one in the normal alphabet;
the substitute is S. For decipherment, count backward
in the alphabet. rrvv~o factors are evicieIlt: there are 10
possible substitutions here (for the digits 0-9) and we
lose some of the weah..~ess of the previous systems.
Giovanni Battista della Porta designed a system in
the 16th century that was actually considered completely safe from enemy decipherment for 200 years. Remarkably, the system is probably still safe from anyonp
but a trained cryptanalyst. Here is the Porta table:
ment uses a numerical key and modifies the traditional
Caesar system. Using a key 31206 and the plaintext
record PROGRAM~1ING the following encipherment
is obtained;
key
plain
cipher
31206
PROGR
SSQGX
312063
AlVEUIN G
DNOIT J
To encipher P using the key digit three, simply begin
at P and count forward three in the normal alphabet;
PORTA TABLE
.I.
I·
I
I CD
1
ABC D E F G H I J K L M
o P Q R STU V WX Y Z N
ABC D E F G H I J K L M
P Q R S 1 UVWXYZNO
EF
'T'
GH I ABC D E F G H I J K L M
I Q R STU V W X Y Z N 0 P
i
IJ \ABCDEFGHIJKLM
IRS T U V W X Y Z N 0 P Q
I
KL I ABC D E F G H I J K L M
i
STU V W X Y Z N 0 P Q R
!
MN
ABC D E F G H I J KL M
T U V WX Y Z N 0 P Q R S
OP
ABC D E F G H I J K L M
U V WX Y Z N 0 P Q R S T
QR
ABC D E F G H I J K L M
V W X Y Z N 0 P Q R STU
I ST
ABC D E F G H I J K L M
~XYZNOPQRSTUV
!w
I
m
ABC D E F G H I J K L M
XYZNOPQRSTUVWI
HI J K LMI'
Ii AY ZBCN 0D PE QF GR STU
V WX
I
1 YZ IABCDEFGHIJKLMi
1
IZNOPQRSTUVWXYI
j
1
Cryptographic Techniques for Computers
This system uses a key-word and 13 cipher
alphabets. If the key-word is HELP and the record to
be enciphered is PROGRA:rvrMING the following
encipherment is obtained :
key
plain
cipher
HELP
PROG
YICJN·
HELP
RAlVIlVl
BPRT
HEL
ING
YLY
By referring back to the Porta chart we can see 13
alphabets. In all 13 of these cipher alphabets, the
encipherment is reciprocal. In the first alphabet on
the chart, for instance, the substitutet for A is N, and
the substitute for N is A. This system applies a keyword to determip.e which alphabet 1S to be used. If the
key-letter is either A or B, the first alphabet is the one to
be used.
In the example above the firsi key-letter is H. Therefore, we go down to the GH alphabet in the Porta table,
whibh is the fourth alphabet from the top . .Next we
take the plaintext letter under the H in the example,
which is P, and find the letter M above the P in G H
Porta alphabet. M is the cipher letter corresponding to
P. This system is an improvement on the Gronsfeld
f;ystem because of the greater number of alphabets.
We now come to a system developed by Sir Francis
Beaufort which has of course the name' the Beaufort
method.' Not unlike the Porta system the Beaufort
:-:ystem also makes use of a key-word and uses a Beau..
fort Table (shown below).
BEAUFORT TABLE
ABC D E F G H I J K L M N 0 P Q R S T UV WX Y Z A
BCD E F G H I J K L M N 0 P Q R STU V WX Y Z A B
C D E F G H I J K L M N 0 P Q R STU V W X Y Z ABC
D E F G H I J K L M N 0 P Q R STU V WX Y Z ABC D
E F G H I J K L M N 0 P Q R STU V WX Y Z ABC D E
F G H I J K L M N 0 P Q R STU V WX Y Z ABC D E F
G H I J K L M N 0 P Q R STU V WX Y Z ABC D E F G
H I J K L M N 0 P Q R STU V WX Y Z ABC D E F G H
I J K L M N 0 P Q R STU V WX Y Z ABC D E F G H I
J K L M N 0 P Q R STU V WX Y Z ABC D E F G H I J
K L M N 0 P Q R STU V WX Y Z ABC D E F G H I J K
L M N 0 P Q R STU V WX Y Z ABC D E F G H I J K L
M N 0 P Q R STU V WX Y Z ABC D E F G H I J K L M
N 0 P Q R STU V WX Y Z ABC D E F G H I J K L M N
o P Q R STU V WX Y Z ABC D E F G H I J K L M N 0
P Q R STU V WX Y Z ABC D E F G H I J K L M N 0 P
Q R STU V WX Y Z ABC D E F G H I J K L M N 0 P Q
R STU V WX Y Z ABC D E F G H I J K L M N 0 P Q R
STU V WX Y Z ABC D E F G H I J K L M N 0 P Q R S
T U V WX Y Z ABC D E F G H I J K L M N 0 P Q R S T
U V W X Y Z ABC D E F G H I J K L M N 0 P Q R STU
V WX Y Z ABC D E F G H I J K L M N 0 P Q R STU V
WX Y Z ABC D E F G H I J K L M N 0 P Q R STU V W
X Y Z ABC D E F G H I J K L M N 0 P Q R STU V WX
Y Z ABC D E F G H I J K L M N 0 P Q R STU V WX Y
Z ABC D E F G H I J K L M N 0 P Q R STU V WX Y Z
ABC D E F G H I J K L M N 0 P Q R STU V WX Y Z A
3·71
I n this table we have 27 alphabets in which all four of
the outside alphabets are exactly alike. L sing the same
key-word HELP and the plaintext record PROGRAJVI}UNG we will get the following encipherment :
key
plain
cipher
HELP
PROG
I.NDR
HELP
RA1fl\1
KWBX
HEL
ING
BJV
To encipher by this method we start with the key-letter
H (at any border) and trace inward to the plaintext
letter P, turn sideways and emerge at the border letter
I which is the encipherment ofP using the key-letter H.
While these substitution systems have been set up
for a 26-element character set, they can all be expanded
to any desirable character set such as a 36-element character set which would include the 26 elements of the
alphabet and the numbers 0-9 or perhaps even one of
the 48- or 60-element character sets commonly used in
computers.
Advanced crypto(lraphic techniques
The main focus of this paper-has been an introductory
look at many general methods of cryptography. Indeed, while each slight variation can add or lessen the
security acquired from the individual system the many
possible modifications of each system have not been
included because of the limited scope of this paper.
Yet it is necessary at this point to raise some of the
more advanced cryptographic techniques. Quite often
substitution and transposition methods are combined.
First, a record is put through a transposition and next
a substitution is app1ied. This win surely increase the
security even if both the transposition and substitution
are quite simple.
A double transposition or double substitution can be
used and although it doesn't lower the security neither
does it always significantly raise the security. An example of a double substitution that would actuany
reduce the security is to use two Caesar substitutions
that were actually inverses of each other. While this
may seem ridiculous it is possible to use two substitutions or transpositions without noticing that they are
actually partial inverses.
Valuable infonnation to possess when tapping a
conununication line is to know exactly when information is being transmitted. To avoid releasing even this
small amount of information, strings of random digits
are often transmitted when the system is not being
used. 4 This necessarily puts the intercepter in the
position of first having to determine which string of
digits is useful information and which is garbage in-
372
Spring Joint Computer Conference, 1969
formation; otherwise he will spend days trying to decipher something that doesn't mean anything in the
first place. The same principle can be used with stored
memor"'J files. Unused memol1T space is inserted "\xlith
strings of random digits.
Messages are also split up into segments so that part
of the message is sent at one time and the rest is sent at
another time, possibly even by a different system of
communications. The same principle can be used on
stored memory files so that records are divided up into
segments and spread through two or more storage
devices so decipherment could only begin after the
different sources were properly brought together.
Another technique is to add a generated random
binary sequence to records as they are being stored in
memory. It is possible to add a different random number
sequence to each record so that decipherment of one
record by an enemy will give no information on how to
decipher the next record. This can be a rather discouraging prospect for even the most persistent cryptanalyst
with a computer.
Indeed, the list of cyptographic techniques is as end-
less as the inventive genius of man. All one has to do is
transmit the cryptographic key in some non-interceptabl~ way and to have all operations reversible (nonsingular). As to what constitutes the perfect cipher
Francis Bacon says: "that they be not laborious to
write and read; that they be impossible to decipher;
and in some cases, that they be without suspicion."
j
REFEREN"CES
'j'M computer and invasion of privacy
Hearings Before a Subcommittee on Government Operations
House of Representatives July 26-28 1966
U.S. Government. Printing Office Washingt.on D.C. 1966
2 H E PETERSO~ R TURN
System implication of information privacy
Proc S J C C Hl67
:3 D D MIl..LIKI~
Elementary crytography and crytanalysis
~ew York University ~ew York 1943
4 P BARA~
On distributed communications: IX. security, secrecy and
tamper-free considerations
RM-3765-PR The RA~D Corporation Sant.a Monica
California August 1964
Montessori techniques applied
to vro!!rammer trainiW! in
a workshop environment
.L
LJ
LJ
by ELIZABETH R. ALEXANDER
California Division of Highways
Sacramento, California
In July, 1966, we developed a curriculum for an
in-house systems programmer training workshop, and
applied certain training methods formulated by Maria
::\1ontessori. 1 These methods are the right of the student
to be active, to explore his environment and to develop
inner resources through investigation and creative
effort. The environment should be such as to give
scope to the individual's inner resources, to direct
these resources and most of all to call them forth. The
instructor's task is one of assisting, watching, encouraging and inducing rather than interfering, prescribing
or restricting.
To date, seventy-two systems programmer trainees
have graduated from eight classes where these techniques have been applied.
A systems programmer trainee within our installation is one whose basic training includes concepts
considerably beyond the fundamentals of applications
programming. A graduate from our systems program,
mer trainee workshop must also have a broad, basic
understanding of the logic of the operating systemdata management, system library functions, catalogue
procedures, the sophistications and efficiencies of Job
Control Language, the purpose of system control
blocks, the various access methods, available utilities,
and core dump analysis.
Graduates from our workshop are eligible for consideration for rotation into systems software programming after a minimum of six month's experience in
applications programming. Upon rotation into the
systems software programming unit, they receive
additional training in operating system coding, teleprocessing access methods, system generation and
details concerning the logic of the operating system
under a multiple variable task environment.
INTRODUCTION
This paper describes a unique workshop structure
based on the Montessori Nlethod and utilizing both
vertical and horizontal interaction in the training of
systems programmers.
The scope of this paper covers the definition of the
training need, the objectives of the workshop, .the
training curriculum, the selection process, the application of certain ::\1ontessori techniques in the training
of programmers, the measurements for evaluating
success, the results of the workshop to date, and the
planned, continued upward development of programmers.
Training need
The California State Division of Highways' unsatisfactory experience with on-the-job and vendor
training resulted in our decision to develop and implement our own in-house programmer training workshop. Prior to August, 1966, we depended upon on-thejob training supplemented by vendor courses.
On-the-job training was constantly interrupted by
production schedules; production supervisors did not
allow adequate time for training, and they were not
necessarily qualified or motivated to train.
Vendor training objectives tended toward course
completion and coverage of material. The courses were
generalized, scheduled at inconvenient times and did
not cover the total subject matter necessary to the
training of a thoroughly productive trainee systems
programmer.
Individual self-discipline, motivation and ambition for increased levels of responsibility did not result
from these approaches toward training.
373
374
Spring Joint Computer Conference, 1969
The objectives of the workshop
The objectives of our programmer training workshop are:
1. The development of com.petent trainee systems
programmers who can take immediate responsibility for· complex assignments.
2. The development of individual self-discipline,
professional motivation and endeavor towards
reaching levels of increased responsibility such
that it will continue after graduation from the
workshop.
3. The assurance of a steady flow of capable personnel, qualified and trained, to fill programming positions which occur through promotions
and attrition. We cannot afford to be dependent
upon the indispensable programmer.
4. The programmer training workshop is only a
first step in the system programmer's development; it serves to reduce attrition in the long
run by providing opportunities limited only by
the individual's interest and ability.
The training curriculum
The training curriculum is dynamic in nature. It
is subject to revision based on our current hardware/
software environment and advancements in the stateof-the-arts which have practical application within
our installation.
At the present time our environment consists of a
System/360 Model 65 with one mi~lion bytes of core
storage, twelve tape drives, two 2314 disk storage devices, one data cell with another to be delivered in
August, two high-speed printers, a drum, a Cal-Comp
plotter, remote job entry with 2780's in eleven districts, six 2260 display units in the software and programming units, with additional 2260's on order for
users.
We are under a full operating system with the Faster
generalized file processor and are in a multiple variable
task environment.
The curriculum developed for the workshop is divided into two parts. The first section covers programming concepts and the hardware and software of the
system and comprises eight weeks. The remaining four
weeks are devoted to a real, live production environment within the workshop in which each trainee is
given a fairly complex production program to chart,
code, compile and test, and which will actually be used
by the installation. Each trainee is given a completely
different program.
Implementation of the training workshop
Selection process
Candidates for our training work-Qhop must pass a
State version of the IBN1 Programmer Aptitude Test.
The cut-off point is 70 percent. This test eliminates 50
percent of the candidate group. Successful candidates
are further evaluated through in-depth interviews.
Questions are asked during the interview which
will expose the candidate's self-image and professional
goals. The candidate is asked to relate experiences
which will substantiate the salient points of the selfimage. The self-image and goals are then evaluated
against the following behavioral criteria:
1. A strongly developed sense of personal motivation toward a long-term career in data processing.
2. A basic character that is conducive to developing a high degree of self-discipline.
3. An enthusiastic interest in working at a detailed
level for long periods without frustration.
4. The ability to work under pressure to meet
critical deadlines.
5. The ability to communicate.
Enrollment in our training workshop is limited
to twelve trainees. This is the maximum number of
students which we feel will allow us to maintain the
desired flexibility of working conditions.
Unique Montessori environment
Our training environment is unique because it applies
Montessori IVlethods to the training of systems programmers. These methods are the development of
seli-discipline through freedom,. all environment which
challenges and motivates on an individual basis and
encourages individual growth toward full potential.
The workshop is structured to appear to be a free
form in-group atmosphere. It is, in fact, a carefully
controlled and disciplined environment where the
ground rules for expected performance within the workshop emphasize the professional attitude expected
in the production environment of the installation.
The workshop stresses group interaction and individual
self-discipline. It utilizes the unusual horizontal interaction of students training each other as well as the
traditional vertical interaction of the instructor training the students.
Ground rules for expected perfornulnce
Ground rules for expected performance are outlined
for the trainees.
Montessori Techniques in ,xlorkshop Environment
It is emphasized that each trainee has been carefully selected for this workshop.
The workshop has been implemented to produce
qualified, first level systems programmer trainees. It
was not implemented to produce coders of higher level
languages. It is expected that the trainees will keep this
objective before them as they proceed through a difficult curriculum.
The curriculum requires an average of three hours
of voluntary homework assignment each day. These
homework assignments make it possible to cover an
extensive amount of academic material within an eight
week period, evaluate the professional motivation of
the trainee, and apply pressures of motivation and
self-discipline.
This workshop does not graduate a trainee who
demonstrates a lack of ability or who fails to meet
the expected high level of performance. The trainees
are told that the expected attrition rate within the
workshop is 10 to 20 percent and that there will be no
exceptions to the standards of expected performance.
The graduates from this workshop are expected to
be able to immediately assume responsibility for complex programming assignments with minimal supervision.
Application of the Montessori method
The application of the Montessori Method to our
training workshop has been achieved in the following
areas:
1. Intense self-discipline through freedom
The trainee has been encouraged to discipline
his own study habits and not be concerned with
the pace at which other trainees may learn.
Observation has shown that when a trainee
attempts to emulate the study habits of a peer,
he frustrates his natural mode of self-discipline.
This results in reduced performance. When the
trainee returns to his own specific form of selfdiscipline, his level of performance rises again.
The trainee is required to demonstrate responsible initiative in coming to the training
instructor for individual guidance and instruction. Every opportunity is given for special
tutoring at a time acceptable to his schedule.
Hemust, however, demonstrate a desire for help
in achieving his goal. If the instructor wishes
to remind a particular student that special
tutoring is available, the reminder is directed
toward the entire group; not toward the individual. This approach forces the student to reconsider the advantages of accepting help and
375
the alternative of possible failure to pass successfully through the curriculum. It emphasizes to
him the need for self-discipline through freedom
of action on his part in taking the proper initiative. It is made clear to the trainee that he is
responsible for properly interpreting and understanding the subject matter. Quizzes and examinations are open book to discourage memorization.
The trainee is allowed considerable freedom
ill his individual ability to demonstrate selfdiscipline. A prime example of this freedom
occurs during the study periods. The trainee
is not actively monitored during these periods.
He has the responsibility to be prepared to participate in. the next scheduled group discussion.
He cannot be a disruptive force to others who are
studying. He is given the freedom to study by
himself, study in a small group cluster where
there is a horizontal exchange of ideas and a
process of teaching each other, or he cannot study
at all.
During the study periods, the instructor will
sometimes leave the environment for a half-hour
or so. This is done to encourage a totally free
environment for individual self-discipline on an
active basis.
The training instructor keeps a detailed,
daily diary on each trainee. Particular attention is given to recording individual critical
incidents. This diary serves as a reminder to
the instructor during the weekly evaluation and
counseling session with the student. It also is
used to substantiate an outstanding performance
report or as detailed documentation required
for recommending rejection from the workshop.
2. Challenging and motivating the individual
The trainee is given increasingly difficult
assignments. He is told that the curriculum
covers in-depth systems programming concepts.
On the first day of the workshop he is given some
thirty-five technical manuals ranging from basic
programming through details concerning the
internal logic of the operating system. He is
told that he will be expected to understand and
apply the technical subject matter covered within these manuals and that he has eight weeks to
reach these expectations. The intense impact
of receiving all thirty-five manuals2 at one time
has the effect of challenging and motivating the
trainee toward full achievement of these goals.
The trainee is told that upon leaving the
workshop environment he will be expected to be
376
Spring Joint Computer Conference, 1969
immediately productive and contribute to the
upgrading of the installation. His training
has prepared him to move in several directions
of individual development. Within a relatively
short period of six to nine months he will be
expected to become a responsible programmer of
large Management Information Systems applications, a fully qualified software programmer
responsible for the operating system or a technical specialist in teleprocessing, generalized file
processors such as Gentry or 1Vlark IV, Graphics
or any other advancements in the state-of-thearts that the installation implements.
The trainee is encouraged to challenge his
environment at any point. He is asked to become
an experimentalist-to not be afraid to try a
technical innovation which has not yet been
implemented within the installation but which
seems to be a practical approach and is proven
to be theoretically possible. He is encouraged
to be an innovationalist-to not be inhibited
in making suggestions for improvement. The
philosophy of the workshop is that the newest
employee can possibly make a major contribution to progress within the installation.
3. Special emphasis on individuality
The workshop encourages the trainee to have
a deep curiosity for exploring beyond the subject
matter covered within the curriculum. The
trainee is encouraged by his own motivation to
do individual assignments beyond those required
by the curriculum and to report back to the
group. Examples of such individual assignments
have been the internal logic manuals on the
Compiler, Linkage Editor and Input/Output
Control System. The IB1vl Systems Journal,
Volume Three, Numbers Two and Three, 1964,
with A Formal Description of the System/
360 by Dr. Kenneth Iverson, 3 has been given
as a special reading assignment to several trainees who demonstrated interest and the ability
to absorb the material. One trainee, especially
qualified by his background, was encouraged to
give a session to the group on vector analysis.
This initial interest on the part of the trainee
has usually resulted in identifying a direction
for continued self-development which has been
beneficial to himself and to the installation.
conference arrangement so that the students face each
other. One desk in the group is reserved for the instructor, who, while sitting at this desk, enters the
group involvement on an active basis· and in fact becomes a member of the group,
The discussion periods are a complex environment
utilizi,ng the lVIontessori Methods of individual selfdiscipline, motivation and endeavor. Superimposed
is a group dynamic structure which is best emphasized
by the fact that a cooperative rather than competitive
attitude is developed among the group. Group motivation is stressed.
At times the group actively takes over and runs
its own training. It is they who select a peer to go up
to the blackboard and summarize the key points of
their discussion; and it is they who monitor their own
horizontal interaction. At such times the instructor
remains outside the group and does not become actively
involved unless the group loses control over the discussion.
At other times the vertical interaction is evident
between the instructor and individual students or
between the instructor and the group as a whole. The
instructor may have an open discussion with one member of the group. He may by his singular attitude
indicate to the rest of the class that he does not want
any group interference in this vertical interaction with
a selected member from the group.
The group may" go critical" with respect to vertical
interaction with the instructor. There has been in
every workshop so far a crisis point about half way
through the curriculum where the group attempts to
resist learning any more, applying any further selfdiscipline and individual motivation. This critical
period is usually of short duration, about a day, and
marks the point at whlch the group learning can go in
two directions. The whole situation can fall on its
own weight and from then on only desultory learning
and results can be expected. Or, the environmentcum-people combination can go" critical" and a kind of
self-sustaining group reaction is initiated which releases
enough motivational and learning energy to carry
the group~hrough the increasing but controlled pressures of the workshop. This occurs primarily because
of the uni/£ying foirce of the instructor's dwn intense
enthusiasm and motivation. In all eight workshops so
far the students have reacted with greater self-discipljne
to the challenge of cO!llpleting the course and becoming
productive systems programmer trainees.
Horizontal and vertical interactions
The physical environment of the workshop is made
conducive to horizontal interaction in the exchange of
ideas among the trainees. The desks are placed i;o. a
,,\1easurements for evaluating
StWCBSS
The following measurements have been applied in
evaluating the 1:luccess of our workshop:
Montessori Techniaues in
...
Measurements within the workshop
environment
1. Observation of individual motivation and se1£discipline in the mastery of the subject matter.
These observations are recorded in the daily
diary of critical incidents and are periodically
evaluated by the training instructor.
2. Successful development to the level of systems
programmer trainee.
3. Performance in written quizzes, examinations
and case studies.
4. Evaluation of the trainee's ability to relate
academic subject matter to the first production
assignment.
Long term measurements
The long term measurements of the individual are:
1. A continued cooperative attitude among the
peers working in a production unit.
2. Continued motivatjon toward self-development.
Each employee has an individual Employee
Development Plan which is kept current by
his production supervisor.
3. The ability to handle complex systems assignments in a timely and efficient manner and to
meet critical deadlines under pressure with
few compilations and tests.
4. Self-discipline which results in minimal supervision and is demonstrated by adherence to
standards and guidelines of the installation.
This measurement can best be taken in terms
of adherence to the requirement of complete
documentation of a given system.
5. The continued advancement to ever increasing
areas of responsibility within t he installation
and success in passing examinations -for higher
work classifications.
(t The periodic, written evaluation of the individual's performance by the production supervisor.
Results of our training workshop
The results of our training workshop for systems
programmers has been twofold. There has been an
immediate upgrading of programming performance
and we have identified a strong need for individual
development and continued training for all 209 persons
employed within our installation.
The upgrading of programming performanee by
graduated trainees has been demonstrated in an outstanding manner.
The trainees have continued to demonstrate a high
Wnl"ln:'hnn R".\dl"nnn-u:mt
_
..... a.t.J ...... _
~
............. y
...... _
................ _
...... ..,
'Y7'7
VI'
motivation toward long term professional careers. This
motivation is partly due to basic personality characteristics which were carefully selected during the in-depth
interview and to the fact that the training workshop
strengthened this natural motivation.
The supervisors have observed that the expected
level of accuracy and self-discipline is being maintained. These programmers require minimal supervision.
Sophisticated production assignments normally given
to experienced programmers have been given to the
system programmer trainees soon after graduation
from the workshop. These are often large scale, complex programs involving 50 to lOOK core storage,
intricate relational editing techniques, table searches,
complex mathematical calculations and dense reporting
formats. Our applications involve the construction
of large information systems within the areas of traffic control, urban planning, fiscal management, administrative support and engineering project control
as well as complex programming in the areas of bridge,
vertical alignment, traverse and earthwork. Graduates
from our trainee workshop are expected to become
immediately productive in these areas. Those who
rotate into software progr~mming have responsibility
for the operating system, the writing of all in-house
utilities and subroutines as well as being responsible
for maintaining an in-depth understanding of remote
job entry and teleprocessing capabilities and the software capabilities of any large generalized file processors
currently in use.
The programs written by these former trainees
have been logically planned using truth tables and
modular design and are fully documented. The number
of compilations and tests has been greatly reduced.
These graduates from the training workshop have
consistently demonstrated competence and understanding of the complex capabilities of the system. They have
been articulate in expressing knowledge of the system
and they have demonstrated ability to explore and
implement those areas of software which result in the
saving of machine time.
A typical example of such a contribution can be
illustrated in the fact that a graduate with less than
six months of production programming experience
researched the feasibility, recommended and then impleresearched the feasibility, recommend and then implemented the conversion of a large sequential data base
to indexed sequential access at a time when I SAM
was a relatively new and untried quantity.
These systems programmers have demonstrated
ability to maintain and modify extremely large and
:)78
Spring Joint Computer Conference, 1969
complex systems and the ability to consistently produce under critical deadlines.
Their continued interest in the field of data processing has been evidenced by their active participation in professional associations and their enthusiastic attendance at seminars -and symposiums which
have covered advancements in the state-of-the-arts.
They have continued to demonstrate highly developed
study habits which have resulted in their being thoroughly familiar with the subject matter presented
in new manuals and publications. All of the former
trainees have clearly defined goals for their own long
term professional development. Of the seventy-two
systems programmers who have graduated from the
training workshop, approximately two thirds have
returned· to take evening courses at college toward a
higher degree.
Four new programming units have been created
entirely from graduates of the training workshop.
These production units have maintained highly satisfactory levels of programming performance.
Ten pro grarruners , who received their training in
the workshop, have become part-time instructors
in advanced techniques sessions and workshops for
programmers.
Ten of the graduates from the training workshop
are now highly qualified software specialists responsible for all aspects of maintaining our operating system
and implementing teleprocessing, partitioning under
multiprogramming, Faster and the system utilities.
The lead systems prograrruners in every production
unit have graduated from our training workshop within
the last year and a half. Two graduates have underfilled temporarily as supervisors of programming units.
Attrition has been noticeably reduced since the
nnplementation of the training workshop from 27 to
14 percent in the first year after implementation of the
first workshop. At the present time our attrition is so reduced that we do not anticipate the need for an entry
level systems programmer trainee workshop before
July, 1969.
The areas of continued training and self-development
have been identified in the following ways:
1. The supervisors and experienced prograrruners
have requested continued training for themselves and these training programs are currently
being developed for them.
2. We also have an individualized employee development plan4 which includes every member of
our staff and involves 209 employees in 41
computer systems classifications. The basis
of this plan is: (a) A determination of skills and
knowledges required and desired for each and
every position and (b) each employee's background of education and experience. The differences between these two elements becomes a
-base for our individualized development plan.
This is not a "one-shot" or lightly considered plan. The dynamic nature of both computer technology and information usage necessitates continuing review, updating, and planning. In effect this plan constitutes a contract
with each employee outlining management
responsibility and the employee's responsibility
for his own self-development. The plan may
include anything from college courses to management development, depending upon a mutual
agreement as to need.
3. An up-to-date library of current periodicals,
journals, and books is being instituted by our
management.
4. The need for a full-time training program for
Computer Systems has been identified. We
have developed and implemented a training
workshop for systems analysts utilizing the
same involutional group dynamic structure
training techniques. To date, four such systems
analyst training workshops have been implemented since September, 1968. We are currently
developing several workshops for programmers
with 12-18 months and 18-24 months experience
as well as a series of workshops for computer
operators.
COKCLUSIO~
Our efforts in systems programmer training have had
immediate and long-range results. We have achieved
the level and quality of programming skills necessary
for successful operation in our third generation environment. We have recognized the need for both initial and continued training.
We have recognized immediate results from the
application of the :\lontessori Methods emphasizing
individual self-discipline through freedom, individual
motivation and endeavor towards reaching levels of
increased responsibility. Our present and future workshops will continue to utilize these training techniques
which are emphasized by the ~vIontessori :\1ethod of
teaching.
A formal individual development for each of our
209 employees has been implemented. :\10st important,
management has recognized that the development of
personnel on a planned, continuous basis is the key
Montessori Techniques in Workshop Environ....-rnent
to successful achievement of our long-range operating
goals.
RE.FERENCES
M MONTBSSORI
• TheM ontessori rnethod
Second Edition Frederick A Stokes Co New York 1912
2 E R ALEXANDER
Third generation programrner trainin(j-the workshop
3i9
approach
Proc Fifth Annual Computer Personnel Research
Conference 1967
:3 A D FALKOFF K B IVBRS01\
E H SUSSENGUTH
A. formal description of systems/360
IBM Systems Journal Vo13 No 2 and:3 1964
4 E R ALEXA~DER
A working measured development plan for computer personnel
Proc of the Sixth Annual Computer Personnel Research
Conference 1968
Variahle topology random access
memory organizations
by MARTIN A. FISCHLER and ALLEN REITER
Lockh;ed Palo Alto Research Laboratory
Palo Alto,. California
INTRODUCTION: THE BASIC CONCEPT
One of the most basic of all computer operations is
the actual or virtual construction of a data sequence
to be used either as the operand for a simple data
transfer, or as the argument of a functional transformation. In a significant number of practical situations,
the data from which the string is to be constructed
are physically scattered prior to the proposed operation
or must be scattered after the operation due to physical space limitations or for reasons dictated by the
logical structuring requirements of the application.
Powerful software schemes (e.g., the list processing
languages) have been developed to deal with the problem of treating scattered data as a contiguous string,
but they pay a very heavy price in memory overhead
(in some schemes over three-fourths of the available
memory is required to handle the addressing mechanisms) and in the processing time required to perform
the address arithmetic.
An alternative solution is proposed here which involves the addition of a small Associative Memory (AlVI)
to the addressing machinery of the computer (or
peripheral direct access storage device) . As will be
shown, this hardware modification will permit scattered
data to appear contiguous, with only a token overhead
cost in memory and processing time.
We note that the data which are to be treated as
a contiguous string can frequently be stored as a reasonably small number of physically contiguous strings.
Further, the computer operation for moving through a
physically contiguous string is the "indexing" 'operation. That is, a special register adds a fixed constant
to the address of the current data element to obtain
the address of the succeeding data element. Let us
now assume that we wish to treat (individually) physically contiguous strings AI, A2 , .. , AN as a single
string. We can do this by loading a map of the type
shown in Figure 1 into an AM which monitors the
contents of the effective address register of the computer's addressing mechanism. When an indexing
operation results in a match with the search field of
the AM, a microprogram interrupt occurs during
which the tag field of the corresponding entry in the
AM replaces the contents of the effective address
register. * The A::\1 is searched in parallel, and essentially
no time delay occurs in processing when there is no
match.
Since the strings in this example were not specified,
they can represent free storage as well as data. Thus,
by simply changing the contents of the map loaded
into the AM, the topology of the direct access storage
device (be it CPU core memory or peripheral storage)
can be altered to simplify and speed up the accessing,
storage, and processing of virtu~ or actual data strings.
The VTRAM (Variable Topology Random Access
Memory) concept presented in this paper will be most
effective in those applications in which the nmnber
of physical and/or logical** breaks in the contiguity
of a data string is small compared. to the numbe:r of
elements in the string, and also does not often exceed
the capacity of the supporting Al\1 (Associate Memory). Data structures of this type, where breaks are
the exception, occur very commonly.
Logical breaks can be handled by the VTRAM
in the same way as physical breaks. However, for some
situations we might desire that a logical break be conditional. This can be accomplished by appending an
extra control bit to the break addresses stored in the
VTRAM that permits address exchange for these
* See Appendix I for further exposition of this concept.
** A logical break in a string is defined here as either an interior
entry point in the string, or a "jump" from one interior point in
the string to another point in the string.
381
382
Spring Joint Computer Conference, 1969
Insertions and concatenations from free storage
(ADDRESS OF LAST
ELEMENT OF A1)+1
ADDRESS OF FIRST
ELEMENT OF AZ
I
( ADDRESS OF LAST I ADDRESS OF FIRST
ELEMENT OF A2)+1
ELEMENT OF A3
•
•
•
•
•
•
•
( ADDRESS OF LAST
ELEMENT OF AN-1 ) +1
ADDRESS OF FIRST
ELEMENT OF AN
SEARCH FIELD OF AM
TAG FIELD OF AM
•
Figure I-A storage map, Showll without control flags. The
order of the entries may be shuffled at will
entries only when the machine condition code
propriately set.
IS
ap-
Implications of a VTRAM for data manipulation
A generalized move operation (CPU to CPU
core)
It is frequently necessary or desirable to move a
logical data string, unaltered, from one physical location in CPU core to another. Data may be moved from
one specific area of core into another prior to bringing
in an overlay, or in order to convert a logical data string
to a physical string prior to a channel operation. (A
single transfer of data from CPU core to a secondary
storage medium or output device frequently requires
that the data be physically contiguous.) Data may
also be moved to reduce the size of the map or the
complexity of the address arithmetic necessary to
visit the elements of a data string, or simply to reset
to zero (or some other fill character) some portion
of a data string. While the existence of a VTRAM
can eliminate the need for many of these data moves,
a significant residue will still be left.
A generalized move can be executed in a VTRAM
by simultaneously loading the maps describing both
the input and output strings into the Al\1. The number
of bytes to be moved can be spec ified in t~...e move
instruction, or it can be determined by having the
AlVI create an operation interrupt (rather than an
address modification) when a match is detected between
a specially flagged entry and the current core address.
A more detailed treatment of this topic is given in
a later section,
When storage requirements for a data string are
determined dynamically, the area allocated to hold
a given string can be exceeded, leading to the necessity of either moving the string to a new (larger) area,
or setting up the machinery to handle data chaining.
As noted in the introduction, software procedures
for data chaining are expensive in storage and processing time overhead. In a VTRAM, free storage is made
available to a data string by simply deleting a section
of the map of free storage and concatenating it onto
the map for the data string after making the initial
and final address linkages. It is important to note here
that the map representing a data string (in a VTRAlVI)
does not have to be ordered. That is, the ordering of
the entries in the map descdbing the string need have
no correspondence with the logical sequencing of characters within the string.
The lnanagement of free storage is a recurring problem common to a wide variety of data processing systems. vVhile the VTRAM concept does not significantly
alter the nature of this problem, it does permit some
simplifications in its resolution. Appendix II discusses
this matter in greater detail.
Generalized data paths
It is not unusual to find problems in which the logical connectivity among a set of data elements is more
complex than in the simple linear strings discussed
previously. Consider the problem of processing a data
ring whose elements are physically contiguous. A ring
is a st~ing whose last physical element is logically
assumed to precede the first; further, the first and last
physical data positions have no special logical significance.
In moving through such a structure in a conventional
memory, a check must be made after each (address)
index operation to see if a jump to the first physical
element of the data set is required. Ih a VTRAlVI,
a single entry in the AM will cause this jump to occur
automatically when required.
Perhaps a more important consideration is the case
where data stored physically in one configuration
must be visited logically along a number of different
paths in the course of processing. Without a VTRAM,
a rather complex (and time consuming) series of instructions would be required to pick out, in turn, each of
the desired paths. With a VTRAM, any given path
can be specjfied by simply loading the map for that
path into the AM. Some examples illustrating this
discussion are given in the next section.
Variable Topology Random Access :Memory Organizations
Channel operations and peripheral storage
The potential application of the VTRAM to the
simplification of channel operations is especially significant. The necessity to physically group data (or use
some form of channel data chaining, difficult to predict in a dynamic situation) is no longer necessary.
The scatter storing of data can sjmilarly be handled
in a single operation by the hardware interpretation
of the storage map.
To illustrate some of these concepts, let us consider
a simplified example.
Assume we have a time-sharing system backed up
by a bulk Cl)re memory logically partitioned into blocks,
each of which is 0.2 the size of CPU core. Thus any
load module (represented by a single map) can contain
a maximum of five physical substrings. During a swap
operation with CPU core, a scatter read (or write)
from (or into) the peripheral store can be accomplished
by a single channel operation using a five-word A:\'I
A later section is concerned with VTRAlVr applications
to peripheral storage.
Patching of "Slow-Write" peripheral storage
One of the potentially useful applications of the
VTRAM concept is as an adjunct to optical peripheral
mass storage devices. The relatively slow writing
times make changing data undesirable, especially for
making small corrections or insertions. The logical
restructuring of data strings via the VTRAM would
permit temporary "fixes." For example, the fix could
be stored in a small, fast auxiliary memory until enough
alterations have been collected to warrant the generation of a revised" memory plate."
VTRA~1
data processing
The following terminology will be adopted for the
rest of this paper:
.A string is a lineal' sequence of elements, where
linearity is a logical coneept independent of the
physical arrangement of the elements.
• A block is a string or substring which is physically
contiguous, i.e., the logical ordering of the elements
corresponds to their physical placement.
• A map is a string of break-transfer addresses
which describes the organization of another string;
one or more maps ean be coneurrently loaded in
the AM to drive the address-exchanging mechanism of the VTRAM.
.A file is a string of maps, and is a ullit for loading
or storing the contents of the A.l\f.
383
To present a concrete discussion, let us assume in
this section that we are dealing with an IB~1 Systemj
360 computer equipped with a VTRAM. The VTRAlVi
has a small number of associative memory words (on
the order of 10 to 50), each of which has enough bits
to represent any valid core address. Corresponding
to each word of associative memory, there is a tag
memory word which can also hold an address (the
"transfer" address) plus several bits of control information. One such bit is the "end of string" bit which
signals to the VTRAM that this break address constitutes the end of a data string. A second is the "end of
file" bit which denotes the end of a string of maps.
(The VTRAl\1 may contain several such files at one
time, each file typically containing one or more maps)
each map describing a string of data.) Finally, two
or three bits can be used as a map key.
The VTRAM, of course, has the property that it
is searched for a match in parallel, and essentially no
overhead is incurred when no match is found. The
overhead in replacing the content of the register being
monitored (the "effective address register") by the
content of the tag field of the VTRAM is also negligible.
The associative memory will only have to respond to
an "equal" condition, thus reducing the cost of the unit.
In addition, the associative memory will have the
property that on being loaded it will use the first available nonzero registers; a property usually obtainable
at no extra cost and which is very useful, as we shall
observe.
Some additional IBM 360 instructions
The following commands have to be added to the
CPU repertoire to manipUlate the VTRAM:
1. ON jOFF Associative 111emory
2. Clear Associative Memory (CA ill). This will
replace the content of the associative memory
registers by zeros. A selective clear based on
the map key can also be requested.
3. Load Associative Memory (LAM), from core
location T. T is the starting location of a map.
Note that this map automatically orders the
stroage and does not itself have to be ordered;
the order of occurrence of the break-transfer
addresses in the map is of no consequence. This
is a very important property of the VTRAM,
as it greatly facilitates additions and deletions
to the map.
The loading of the associative memory continues until an end-of-file bit is encountered
in one of the entries. If the available associative memory is exhausted before the end-of-file
384
Spring Joint Computer Conference, 1969
indication is reached, an interrupt occurs (or
a condition code set) and the address of the
last entry loaded is posted. The possible remedies
t.o t.his overflow condit.ion will be discussed. K ote
that the VTRAl\f can be loaded with several
maps corresponding to several logical data strings,
at" the same time. This facilitates storage-to-storage operations.
A highly useful variant on the LAM instruction is a BLAM (Backward Load Associative
Memory), in which the break-transfer address
pairs, as they appear in the table, are interchanged when loaded into the associative memory. This facilitates the backward scanning
of a logically contuigous block or string of data.
4. Store Associative 1vlemory (SAM), used by the
supervisor during interrupts.
CAM
Clear the associative memory
(optional)
LAM TA
Load the map which describes
string A
LA::.Yl TB
Load the map of string B (note that
this is in addition to TA)
MVC B, A Start move operation, with the initial
addresses being A and B. (Note that
the VTRAM contains only the
break addresses, and not the initial
addresses of the strings.)
The l\1VC instruction will terminate as soon as
an end-of-string indicator is reached for either string
A or string B, returning a condition code corresponding
to each applicable case. An alternate possibility, in
case the end-of-string for A is encountered first. is to
fill the rest of B with, say, zeros.
The augmented MVC command
To make use of all of this machinery, the storageto-storage instructions (SS) of the 360 will be assumed
to operate using the VTRAl\1. This means that the
length specification will become unnecessary, since
a string-end condition is now explicitly represented
by break address entry with a flag.
A typical sequence of commands for, say, moving
data from string A to string B (the strings possibly
co~sisting of several blocks each) would be
CAM
LA~f
LAl\I
LAl\1
LA
LOOPJ
LH
LH
SR
SR
LA
LR
LH
LOOPK
LA
LOOPI
LH
MH
AR
ENDLOOPK * LA
LA
BeT
TA
TB
TC
RA,A
RC,e
Rl,Il
R2, n
R6, R6
R4,R4
RB,B
R7,RA
R3, n
R5, O(RB, R6)
R8,O(R7)
R8,O(R5)
R4; R,8
RB,2n(RB)
R7,2(R7)
R3, LOOPK
Matrix multiplication
As an example of generalized data paths, we will
look at a procedure for forming a product of two matrices, C = A *B. The three matrices are not assumed
to be located in contiguous storage, but may rather
be scattered all over core. We will however, assume
that each row of the A and B matrices is in one block.
(The matrices are n by Il, with each element being a
half-word integer, so that each row is 2n-bytes long.)
First clear the associative memory
Load. the maps for the matrices A, B, C
Register RA points to A(l, 1)
Register RC points to C(l, 1)
R1 is the counter for the I loop
R2 is the counter for the J loop
R6 ·has displacement from start of row for B(K, J) for J =
R4 has the partial sum for C(I, J) = ~ A(I, K) *B(K, J)
Register RB points to B(1, 1)
R7 is the pointer to A(I, K) for K = 1
R3 is the counter for the K loop
Pointer to B(K, J)
A(l, K)
13(K, J)
Partial sum
Step row address. Note that if a break address is reached, the new
transfer address gets inserted into RB from the effective address
register. Thus, the next time through the loop, when the LA R5,
O(RB, R6) instruction is executed, the correct address will appear
in R5
~Iove pointer to A(I, K) to next element in row
Go through the k-loop n times
Variable Topology Randol11 Access 1vienlory Organizations
ENDLOOPJ
STH
* LA
R4,OCRC)
RC,2(RC)
LA
BCT
ENDLOOPI * LA
R6,2(R6)
R2, LOOPJ
RA,2n(RA)
BCT
Rl, LOOPI
385
Store C(I, J)
Step pointer to C(I, J). Again note that if a break address is encountered, the transfer address replaces RC. (This works even if
breaks occur within a row in the C matrix)
Step element displacement from start of row for B(K, J)
Go through the J-loop n times
Step row address for A. Again note the automatic substitntion of the
transfer address
Go through the I-loop n times
Because of the VTRAM device, this program did
not differ substantially from any matrix multiplication
program for contiguously stored matrices. Of course,
similar procedures are used on computers not equipped
with a VTRAM. These, however, require that the
starting· row address for each row of A, B, and C be
stored in a table; with the VTRAM, only the actual
break addresses need to be stored. An additional advantage obtained by the VTRAM is that the C matrix
can be scatter-loaded randomly, without the restriction
thsJt no row can be broken.
Note that in the example it was necessary to return
the break address modifications to one of the index
registers used to control the addressing sequence because the data path was traversed in a sequence of
instructions under program control, rather than as
a single instruction triggering a micro instruction sequence. This was accomplished by means of the LOAD
. ADDRESS instruction which sums a fixed displacement
and up to two index register values in the effective
address register and then returns this sum (in our
case, to one of the participating registers). When the
effective address computed in this process matches
a VTRAM break address, the effective address is
replaced with the corresponding tag address, and this
address, in turn, is transmitted back to the index register specified as the receiver for the LA instructions.
Another example with logical data, path.
As a second example involving generalized data paths,
consider the problem of analyzing the contour of a twodimensional graphical object, which is represented
in storage by a series of fixed-length records, each
giving the (x, y) coordinates of a point on the contour
together with some additional information such as
the identity of the line segment to which the point
belongs. (The contour is partitioned into a series of
line segments which are physically contiguous substrings.) The order in which the records are stored
corresponds to the sequence in which the points occur
on the contour of the object, with some arbitrary
break point to permit storing this file structure, which
is logically a ring, as a (physical) linear string. We
assume here that there are no physical breaks other
than the one which closes the ring.
In one operation we might prefer to start with the
point having the greatest coordinate value, and count
the number of points for which the coordinate monotonically decreases. Without a VTRAM, after each
point is examined, we must check for the ring-closing
physical break address in the table before indexing
to the next point. With a VTRAlVI, storage of the break
address would cause an automatic return from the
end of the string back to the beginning if an attempt was
made to index past this last entry in the file.
In a second operation, we might prefer to find the
center of gravity of some selected subset of line segments. Without the VTRAM, we would be required
to check the segment ID of each point against the list
of desired segment numbers before including the point
in the computation; or, after each index operation,
a check would have to be made against a list giving
the starting and terminating address for each of the
desired line segments; or some special coding would
have to be written to selectively find the desired points
(based on address) without search. Regardless of which
of these methods was chosen, a certain amount of datadependent code must be written and stored, and the
execution of this code must pay a time penalty to
continually search for the logical break addresses.
With a VTRAl\1, once the logical break addresses
for the selceted line segments has been loaded in the
AM, the operation can proceed as though only the
selected line segments were present. No data-dependent code is required and no time penalty is accessed
for searching for the required points.
The overload problem
When a map for a given string gets larger than the
available number of associative memory registers,
it has to be partitioned so that the consecutive partitions of the map (submaps) now correspond to the
logical ordering within the string. Given such an organization of the map, only a part of it need be loaded
386
Spring Joint Computer Conference, 1969
into the VTRAM at one time; if a given operation
is not completed before the last break address corresponding to the end of a submap is reached, the next
submap replaces the old one; and the operation is
repeated. This process continues until the end-of-map
indicator is encountered.
When a large map is thus partitioned into submaps,
each of which is small enough to fit into the VTRAM,
it should be noted that there is no need for the submaps
to be ordered internally. This fact facilitates the sorting
process, and also allows subsequent insertions of new
break-transfer entries at any available position within
the appropriate submap.
Note, however, that even the partial ordering of
a map entails what is usually a very large overhead,
and the VTRAM should contain enough registers to
obviate the necessity for this ordering in the great
majority of cases. If it were not for this fact, we could
always assume that the maps are ordered, and would
be able to operate using an associative memory with
only one register; i.e., any ordinary register which
can monitor the effective address register would suit
our purpose. *
The reordering operation may itself make use of
the available associative memory. The use of associative memories to facilitate sort operations has been
studied in the literature. I
Some limitations
While the VTRAM mechanisms presented here
are well suited to the separate handling of logical or
physical breaks, the combination of such breaks in
the same string will cause special problems. To specify
a direct jump from the ith element of a string to the
jth element across a physi~al break, some address arithmetic using the string storage map must be performed.
The arithmetic is simple and needs to be performed
only once. Nevertheless, the computation is time
consuming and sometimes cannot be done at the time
the string is stored, but must be made when the jump
is required. For these reasons, an executable instruction
string which contains many dynamically determined
branches is not a desirable candidate for VTRAMcontrolled scatter loading.
Using a
VTRA~~1 for
peripheral storage management
A key problem which arises in many different con-
* It might be interesting to use this approach as a first apprOXImation toa VTRAM. Note that this monitoring function of the
effective address register (by switches which are manually set) is
already present in the IBM 360. The hardware modification
required to make this register addressahle from within a program
or a microprogram would seem to be fairly minor.
texts in dealing with random access storage devices
is the fact that there is really no such thing as a truly
random access device; all existing devices are actually
org~mized into groups of records; each one of which
is bounded on either side by other records. This causes
problems when the information contained in a record
changes dynamically in size; for example, it may no
longer fit into its former place. One is now typically
faced with a decision of whether to invest the time in
trying to make it fit into one place (either by pushing
aside its neighbors or by finding a different place for
it which is large enough), or to string it out in several
records by chaining the various pieces, thereby sacrificing time during retrieval. A VTRAM can be used
here to great advantage to create logical linkages
between physical records which are not physically
contiguous, thus allowing them to be written or read
using but one CPU channel command; i.e., to make
them look like a single physical record to the computer.
We will discuss two classes of random-access storage
devices; a bulk core memory, and a fixed-head rotating
memory. In both cases we shall assume that the CPU
communicates with a controller unit for the memory
in question, and that this controller is in reality itself
a small stored-program computer; it is this small computer that we wish to equip with a VTRAl\1 in order
to facilitate the restructuring of records 'without actually moving data around. It should be pointed out
that the controller will be able to perform a certain
amount of housekeeping operations "for free" if it
can do them subsequent to the completion of a given
I/O operation, since there will be periods when the
CPU is not using this class of devices. If the controller
can schedule housekeeping operations, for example
by waiting a certain time interval to give the CPU
a chance to start a second operation which might have
been present in a queue, more efficiency can be achieved.
Thus, we can in general tolerate more overhead for
housekeeping in the controller than in the CPU. On
the other hand, for a rotating device, the mechanical
aspects of the memory sometimes present critical
timing problems for the controller.
Drum memory
To lend concreteness to our, discussion, we shall
describe a specific rotating memory. This is a drum,
with 800 tracks, each of which is somewhat over 4096
byt€s long (the exact length will depend on the particular memory organization that we choose). The
drum is rotating along the tracks, so that a given track
can be read during a single revolution. Only one head
can be reading or writing at any given time, but heads
can be switched at any time at electronic speeds; hence;
Variable Topology Random Access l\tfemory Organizations
during a single rotation data can be picked up from
several tracks, but necessarily from different positions
along the tracks.
We shall assume that the drum is equipped with a
timing track, whose current content together with
the current track indicator are being read into a register which can be monitored by a VTRAM. (This register
will serve the same function as the "effective address
register" already discussed.)
Along each track, memory will be divided into sectors.
A sector is a quantum of storage, say 64 bytes long;
thus our drum has 64 sectors per track. Since, by definition, a sector is the smallest addressable unit of storage
the timing track need only carry information as to
the current (or next) sector.
Becuase of the possible time lost in head switching,
there may actually have to be a physical separation
(amounting perhaps to several byte posit~ons) between
the end of a sector and the start of the next one.
The first part of each record consists of its storage
map. (See Figure 2.) The record is addressed (by the
computer) by giving the address of the sector which
contains the map. The map is read into the VTRA1VI
in the controller; it then controls the mechanics for
reading the rest of the record by causing head switching
to take place. If the map terminates in the middle of
a sector, the data portion of the record starts inunediately. If only retrieval is desired, the data transmission to the computer need not conunence until after
the "end-of-map" indicator has been read into the
controller. For a write operation, the computer will
have to supply not only the address of the start of
the record, but the map as well. The onus of storage
management on the drum, and the decisions as to
where to put the various pieces of a record, must be
left up to the central processor. The controller is capable
of performing this function equally well, but the effi-
Figure 2-The physical organization of a record in ~torage.
The address of the record shown, from the point of view of
the central processor, is Track 1 Sector 2, which
is actually the address of the map
387
ciency of use of a rotating memory depends critically
upon the scheduling of accesses to the memory.2 To
do intelligent scheduling, the controller would have
to have access to a much larger body of dynamically
changing information than is normally feasible (except
on computers like the CDC 6600, where the controller
is itself a full-fledged CPU with full access to all of
core).
Let us look at the case of a record which is being
rewritten, but which requires more space than it formerly occupied. Instead of releasing the record's current storage to the free storage pool and then allocating
a contiguous block of storage for the entire record,
as might be done on devices without a VTRAM, the
drum storage allocator of the CPU would be asked
to allocate additional storage from a longitudinal position which begins immediately following the termination of the last sector in the current record. (Various
alternate strategies are possible if such storage is not
currently available.) That is, a piece is simply added
on at the end of the existing record, thus making a
longer record. Note that this piece can, in our case,
come from a selection of anyone of 800 different sectors.
The allocation procedure has the very important
property that the new storage block is always added
on at the logical end of the current storage. What
this means is that our maps are always orderedsuccessive entries in the map represent successive
blocks of the record. Thus, there is no need to use
the entire break-address portion of the map to monitor
the timing track. Instead, the controller can have a
pushdown stack, in which only the top element of the
stack is used to monitor the effective address register.
When a break address is encountered, the next element
(break-transfer address pair) is popped up and becomes
the new top of stack.
A basic underlying assumption in this discussion
is that the entire record is rewritten during an output
operation. This distinguishes the use of the VTRAM
device in the present case from its use for core-tocore operations as discussed in a previous section,
where a logical· unit of data could be restructured
dynamically in many ways other than addending at
the end.
To recapitualte our proposed method for handling
drum storage: each record carries along (at its beginning) a map of where the record is located; this map
is loaded into the VTRAM device and is used for automatic head switching as required. There is essentially
no overhead lost in retrieval time in this scatter storage
of a record compared to having the entire record stored
on a single track. There is, however, some overhead
paid in storage. For our drum, each map entry would
388
Spring Joint Computer Conference, 1969
consist of three 8-bit bytes: one to monitor the timing
track (for 64 possible different sectors) and two required
for the proper head selection plus some miscellaneous
bits. In the worst possible case; where a head change
is required for each sector, the storage overhead is
somewhat under five percent.
Bulk core memory as peripheral storage
This type of storage device is characterized by the
fact that there is no latency time due to rotational
delay to worry about, as was the case for the drum.
Thus, as far as the computer is concerned, all storage
locations are equally accessible, and it does not matter
where various pieces of data are stored. As in the case
of the drum, however, we will assume that the computer
deals with storage in records, and that a single record
is to be fetched or written with a single channel command. It is, of course, possible to assign much more
complex structure to the data, and have this structure
reflected in the nature of the computer-controller
communications. As this would unnecessarily complicate the ensuing discussion without contributing anything, we will assume the simplest possible structure
in the bulk core.
Using a VTRAl\l enables us to have a record consist
of many noncontiguous blocks. For bulk core, all free
storage management can be left up to the controller.
We propose a similar record fonnat as for the drum,
where the computer addresses a "header" which contains a map of the record; the computer, however, need
never see the map. The free storage handling strategies
discussed in Appendix II for CPU core are equally
valid for the bulk core as well. The significant differences for bulk core are (1) more time can be invested
in periodic recondense operations since they can be
scheduled "off-line" by the controller, and (2) the
VTRAl\l implementation need not actually involve
any associative memory, but only a pushdown stack.
When the CPU initiates a bulk core write operation,
the free-storage-map (held permanently in a pushdown stack) is used by the VTRAM to direct the
store operation. The top of the free-storage-map,
which corresponds to the storage blocks needed to con'tain the transmitted record, now becomes the map
for thi8 record.
In the case of the bulk core, the most convenient
location for the map describing a record is immediately
following the record. However, since the map itself
is a record which may have to be scatter loaded, the
initial segment of any such map must contain the
break addresses needed to retrieve the map. (This
initial segment terminates with a special flag bit.)
Thus, after a write operation has been completed,
the controller adds to the top of the map for the stored
record a prefix (possibly null) of additional break
addresses, and this augmented map is stored (under
control of the VTRA:M and the map prefix) immediately
following the record it describes. Finally, the address
of the first entry of the prefix is returned to the CPU
as the address to be used in reading the record. This
address is available for returning to the CPU immediately at the conclusion of the write operation, even
though the contents of this location will not be determined until after the map itself has been written.
For a read operation, the CPU-supplied address
is used to obtain the map prefix which then directs
the loading of the map itself into a VTRAM pushdown stack. Now the map directs the requested read
operation.
Comparison with other address-mapping schemes
Associative registers and other special-purpose memory addressing hardware are currently employed in
a number of computing systems (e.g., IBM 360/67,
GE 645, B 8500)3,4,5 to implement address mapping
for paging and segmentation schemes. These concepts
and their associated hardware organizations are significantly different from the VTRAl\l concept presented
here. Paging is a scheme for making the fast core appear larger than it actually is (virtual memory), and
is accomplished by defining a mapping function from
a large virtual space into the small physical space.
The paging hardware is employed at every memory
reference and at least one conversion per reference
is required to translate the symbolic address contained
in the instruction into a physical address. Pages of
core are usually of a fixed size, although they may come
in several sizes, This organiz9Jt.ion allows jumps jnt.o
the middle of a page to be handled easily. Maps (segment and page tables) pose a special handling problem
and entail storage overheads.
The VTRA11 concept is concerned with dynamically
restructuring the logical contiguity relations between
data within the same real space without having to move
the data. A second application of the VTRAM concept
is to reduce the programming and timing requirements
for moving physically scattered data between a peripheral device and core, or from one set of core locations
to another. The VTRAM hardware is used to exchange
one physical address for another only at the break
points specified by the active storage maps; otherwise
it does not intervene in the addressing process. The
length of eaeh block of stroage is of no consequence.
The VTRAM is intended to support operations which
index through the data, and unexpected logical breaks
can be handled only with difficulty. The storage maps
Variable Topology Randon1 Access :rvlen10ry Organizations
used by the VTRA:\I can themselves be scatter loaded
just like any other data string; this permits a saving
in space, for even though the maps may dynamically
change in size, no contiguous blocks of storage need
be reserved for them.
389
size to be exceeded, several procedures utilizing the
VTRA~\1 are suggested.
An especially important advantage of the VTRAM:
concept is its applicability to almost any reasonably
sized computing system with very little hardware
modification.
COl\CLUSIOKS
The VTRA:\:'I concept, as developed in this paper,
is a hardware organization for achieving, on almost
any digital data processor, a string processing capability, extending to channel and peripheral operations,
at very low cost. The central idea is that of "address
exchange" when a critical boundary is crossed during
an indexing operation. Implementation is achieved
by storing these boundaries in a small associative
memory 80 that many of these boundaries can be
searched for in parallel, thus avoiding any significant
processing time overhead. Given the presence of the
AlVI, it is also available for use in a more conventional
manner.
The major advantage gained via the VTRA::\1 is
the ability to do "string processing by exception"
for strings which contain relatively few breaks.
Such strings (the authors feel) are very common,
and come about as a result of insertion, deletion, or
rearrangement operations on formerly contiguous
data. They also arise when contiguous data, stored
physically in one configuration, must be visited logically
along one or more different paths in the course of processing. There are types of strings, however, such
as those consisting of executable code, for which the
VTRAlU mechanization as described here is not very
useful.
One area where the authors feel the VTRA::\1 concept has much potential value is in augmenting data
transfer machinery.
It is impossible to give a simple answer to the question
of how much core is required to adequately support
a given CPU, and similarly the question of how much
A::\I is required to optimally implement the VTRA::'U
concept with a given amount of core cannot be ans,vered
except in very specific situations. The authors feel that
there are many significnat applications where a small
fixed A::\I, say 10 to 50 words, would be very valuable
regardless of the amount of core.
For the VTRA::\I Joncept to be useful, the A::\1
size must be large enough to contain the maps generated
by the various applications. This will be ensured for
most cases by free storage management procedures
and by programming limitations dictated by the actual
size of the A::\I. In the unusual case of severe fragmentation of a given storage area, causing the A::\I
ACKNOWLEDG~1ENTS
The authors wish to express their gratitude to Professor Harold Stone of Stanford University, and to others
who read the preliminary draft, for some very cogent
conunents and ideas which contributed to this final
paper. Thanks are also due to ::\largarett X. Collins
for her able editing of the manuscript.
REFERENCES
R R SEEBER
A B
LI~ DQUIST
A.ssociative memory with ordered retrieval
IBM J Res Dev Vol 6 January 1962
2 P DEXXIXG
126-1:~2
The effect::; of scheduling on file memory operations
:~
Proc S J C C 1967
E L GLAZER J F COULEUR
G A OLIVER
System design of a computer for lime-sharing applications
Pro(' F J C C Part I Vol 30 1965 197-202
4 J D MCCt'"LLO"CGH H K SPEIERMAX
F \Y ZURCHER
A. design for a multiple user multiprocessing system
Proc F J C C Part I Vol 30 1965 611-617
5 W T COMFORT
11 computing system design for nser service
Proe F J C C Part- I Vol 30 1965 619-626
6 D E K~UTH
The art of computer programming, vol I:
Fundamental Algorithms
Addison-Wesley 1968
APPENDIX I: VTRA::\1 I~\IPLE2"IENTATION
Figure 3 shows a typical computer data flow organization augmented by an A~f. The main point to note
here is that implementation of the VTRA:VI concept
can be accomplished with minimal disturbance to the
conventional data flow paths. The essential require-·
ments are a connection to the main memory output
bus to permit the loading of the AM, and a connection
to the Address Adder (or "effective address register")
so that monitoring and address modification can be
accomplished.
To more fully utilize the capabilities of the AM,
it may be desirable to introduce additional direct
paths to one or more of the index registers. However,
all of the operations discussed in this paper can be
carried out without these additional connections.
a90
Spring Joint Computer Conference, 1969
ARITHMETIC LOGIC
UN iTIACCUMULATORI
RN
Figure 3-Typical computer data How organization augmented
by an associative memory to realize a VTRAM capability
APPENDIX II: STORAGE
STRATEGIES USING A
MA~AGE:\1ENT
VTRA~VI
A major function of the VTRAl\1 device is to facilitate
the dynamic restructuring of data, without actually
having to move the data about from place to place.
A very important application of this concept is in
storgge management for complex dynamic systems,
such as a time-shared executive system. A rough description of the environment might be a~ follows.
(This is a cross section at time to.)
• There is a collection of storage called "free storage"
which is noncontiguous.
• There are n jobs, each of which occupies some
noncontinguous region of storage. These regions
are mutually disjoint, and do not intersect free
storage.
• Each job may request additional storage from free
storage. The request will be for a certain amount
of storage, and may be allocated (by the executive)
at its discretion from anywhere in free storage.
When such an allocation is made, the storage area
is deleted from free storage and becomes part of
the job's storage region.
· Each job may release any or all of its storage to
free storage.
I t should be pointed ouf again that a VTRA:WI is
not particularly useful tor executing scatter-loaded
code, as program strings tend to have too many logical
breaks (interior entry points). The reader should assume for this discussion that the jobs are requesting
core for data manipulation. For example, a job may
wish to read in a record from a peripheral storage
device, insert a new field, and write the record back
into the storage device. Note that this operation is
precisely of the form discussed above: only one or two
breaks are introduced into a (formerly) contiguous
data string.
Let us discuss the free storage management function.
This management must perform two distinct functions:
that of allocation and that of releasing storage back
to free storage.
The management of free storage is concerned with
creating a balance between the tendency for blocks
of storage to become progressively smaller (through
the randomizing action of the allocation-release process)
and the overhe9Jd involved in rebuilding 19>rger blocks
from the available fragments.
The overhead for cond.ensing free storage can be
paid in a number of different ways, involving such
considerations as the time required to allocate or release storage, the frequency with which the condensation must be repeated to keep the average block size
above some minimal value, and the complexity of the
hardware and algorithmic procedures needed to perform
the condensing operation.
Assuming, as we are doing, that each job will manipulate its own data structures using the VTRA~i,
which has a limited storage capacity, it is incumbent
upon the executive to minimize the storage fragmentation during the allocation function; otherwise, each
job will have its storage broken into so many noncontiguous pieces that the storage capacity of the
VTRAl\1 will be exceeded very often, with a resulting
high overhead, thus negating the benefits from having
this device available. On the other hand, both the allocation and the releasing function are performed so
frequently that if the system is to function efficiently,
these functions must not take too much time.
The strategy discussed below is derived by adding
a VTRAl\1 to the commonly used "first fit" strategy:
e.g., see KXUTH, Section 2.5. 6
Free storage is represented as one string (noncontiguous), with a map of break-transfer addresses. When
a request for n storage units comes in, storage is "peeled
off" from the top by assigning an many blocks as are
required to satisfy the request. Since the end of the
request will typically fall in the middle of a biock,
a new break-address will terminate the block given to
the job, and a new start address will be assigned for
free storage. This allocation operation is extremely fast.
The storage release operation itself is equally simple.
The job denotes the area it wished released by supplying
a map; this map is addended to the free storage map
Variable Topology Handom Access l\1emory Organizations
and the operation is finished. (The reader may note
that this is conceptually identical to a "threaded list"
organization of free storage.) Since the area required
for the free storage map itself necessarily has to be
finite, the VTRAM can be used to handle this area
in a cyclical fashion (with a fixed maximum size for
the number of entries). Thus, as entries are taken off
the top and added at the bottom, the two operations
are eventually performed at the same rate, and a steadystate cyclical storage area suffices:
The disadvantage of this strategy is that storage
will become increasingly more fragmented, since no
attempt is made to find the best blocks for this particular request. If this approach is to be made workable,
a "garbage collection" operation must be performed
periodically after storage is released.
To facilitate the garbage collection, it is useful to
represent a storage map as an (unordered) collection
of ordered triplets (Bi,T i,AL.), where Bi and T i are
the break-transfer addresses as before, and ALi is
the address of the last element of the block started
by T i. That is, every ALi is equal to some B j in a oneto-one fashion. In addition, the start of a block is represented by a triplet (O,To,ALo), where the break address is empty. The reason for this redundancy is that
the break-transfer addresses do not lend themselves
to a convenient identification between a T i which
starts a given piece and a B j which terminates it.
Of course, during the use of the VTRAM, only the
Bis are loaded into the associative memory, and only
the T /s need appear in the tag part.
To return to the garbage collection algorithm: The
operation of combining contiguous blocks consists
simply of looking for matches between the AL/s and
the T/s. Anyt'me that a match T j = ALi occurs, we
simply replace ALi by AL j and delete the triplet (Bj,
Tj,AL j ) from the map. 1\10st of the overhead in this
operation is in the search operation; a function greatly
facilitated by the presence of the associative memory.
391
After the garbage collection, free stora;ge has been
completely condensed and consists of a number Of
noncontiguous areas, each of which is represented by
an entry in the map. Note, however, that the ordering
of the blocks is totally random, since there is no advantage to be gained in sorting these blocks on their
respective core addresses; nor is there anything to be
gained in sorting them by size, since the allocation
strategy calls for assigning storage from the top of the
free storage li~t.
If the associative memory is large enough to accommodate the entire T i vector, the loading operation
during the search for matches.needs to done only once,
thus speeding up the condensing process considerably.
I t might therefore pay to do the condensing quite
frequently, in order to keep down the size of the T i
vector (as well as to cut down on the fragmentation
of the allocated storage). The exact tradeoffs involved
(i.e., what is a reasonable size for the associative memory, and how frequently should one recondense, given
certain assumptions about the fob mix and probability
distributions for storage request-release operations)
will be t.he subject of a simulation study conducted
by the authors, with the results described in a forthcomihg paper.
In summary: this strategy for storage allocation
and the corresponding representation of storage blocks
is characterized by extremely rapid handling of requests
and releases. The storage representation is in a form
directly utilizable by the jobs because of the presence
of the VTRAM device. Some overhead is incurred for
the periodic recondense operation associated with
storage release, but this overhead is considerably
reduced by the presence of the associative memory.
The overall efficiency of this method will depend upon
the size of the associative memory; the exact relationship is unknown pending the outcome of a simulation
study.
Fault location in memory systelDs
by program*
by C. V. RAVI
U nivel'sity of California.
Berkeley, California
INTRODUCTIOK
The subject of automatic fault location in rnemory
systems by program so far has been neglected in computer literature. A program (A~INESA) has been
written at Honeywell that not onJy detects failures
in memory, but also diagnoses the cause of the failure.
This paper describes the approach used in the writing
of AMKESA. It is also shown that this approach can
be used for different memory organizations.
In the past, memory diagnosis has depended considerably on the intuition and experience of the Field
Engineer. Standard test routines consist in moving
information into and out of memory, comparing and
printing out the location of the error and the faulty
information. After this the Field Engineer was left
with the problem of finding the cause of the errors.
Thus, emphasis has been on the detection of errors.
.A~I~ESA goes further to isolate the cause of the errors.
Objectives
The diagnostic program was written with the following objectives in mind.
1. Special hardware which may be necessary In
order to run a diagnostic should be kept to
a minimum.
2. The diagnostic should isolate the cause of
failure to one or two circuit packages.
3. Multiple failures should not confuse the diagnostic.
4. Very little should be left to the Field Engineer to minimize downtime.
* The work described in this article was done while the author
was with Honeywell EoD.P., Waltham, Massachusetts. Present
address: Institute of Library Research, Univerisity of California,
Berkelery, California 94720.
5. Failures in the parity plane circuits should be
diagnosed.
6. Failures in the Memory Address Register should
be diagnosed.
By and large, AMNESA has achieved all these
objectives.
Necessary hardware features
Something can now be said about hardware, in
general, necessary for the running of a memory diagnostic on a: computer with a malfunctioning memory.
1. The diagnostic program has to be loaded into an
area of memory which is working correctly in order to
diagnose a malfunctioning area.
One can sub-divide the memory in most machineH
into modules between which there is very little or no
common circuitry. Assuming that all modules do not
fail simultaneously, and that the module is large
enough to contain the diagnostic, a diagnostic can be
loaded and run. ~eedless to say, the program should
be relocatable from module to module. On many of
the older machines, index registers were contained ill
main memory. In such cases, the index registers themselves must be relocatable 01' the program should be
written without using index registers. In the H-1200
and H -2200 computers, the module size is 32K charaetel'S and AMNESA is considerably smaller.
In computers that have interleaved memories, the
interleaving is usually between modules. The simplest
way to guarantee enough room for the diagnostic is
to have a hardware feature that allows the addressing
to be sequential from module to module. Such a fe2.ture
is, of course, very easy to implement.
If it is desired, however, that as little of memory as
possible should be destroyed by the running of the
393
394
Spring Joint Computer Conference, 1969
diagnostic, other techniques can be employed. First
consider fixed word-size computers with n-wayed
interleaving between (word-oriented) modules. In
order to run the di3,gnm::tic in any module there are
t\VO requirements.
a. Force the assembler assembling the diagnostic
to assemble instructions and data at word
addresses that are multiples of n. This is quite
easy as it just entails stepping the location
counter in the assembler by n rather than by
1 as usually done.
h. One also requires a feature by which the
program instruction counter (in the hardware)
is stepped by n rathel' than by 1.
In the case of varlable lIlstruction size and variable
data size machines, one would have to restrict the
program to be written in instructions that are smaller
than or equal to the word size, of each module. In
exceptional cases, this may not be possible. l\lemory
restructuring would then be necessary. Similar restrictions would apply to the kinds of data such a
program ('ould handle. During execution, however,
there is an advantage in such machines. The Program
St.atus Word (or equivalent) in such machines has
an Instruction Length Code field (ILC) which is
added to the program counter to reference the next
sequential instruction. This ILC field could then be
forced to n and the execution of the program could
be effected.
The above is to show that the problem of interleaving is not immrmountable and in any speeifi(~
case probably quite easy to solve-bot,h teehnieally
as well as economically.
If a very short memory diagnostic program can be
written, it may be worthwhile to have a Read-only
memory (that can be used in a special mode of operation) that contains the diagnostic. This may turn out
to be quite reasonable in a microprogrammed machine.
2. A parity error in the area of memory being tested
by the diagnostic should be signalled to the program,
while a parity error in the area into \vhich the diagnostie
is loaded should cause the computer to halt.
The signalling can be done by an internal interrupt
or fault which indicates a parity errol' has occurred.
Since initially it is not known where the fault is, the
diagnostic has to be loaded into different modules
until a particular module that is functioning normally
is found. In the H-1200 and H-2200 eomputers, if a
parity error oecurs in a proteeted area of memory,
an internal interrupt is generated and the program
does not halt. If the error occurs in an unprotected
area, the program halts and the parity error indicator
lights up on the console. AMKESA itself takes care
of protecting the module it is testing. Of course, the
!llodule into which Al\,I~ESA is loaded is unprotected.
The superfici3,l solut.ion of disabling t.he parit.y
geneiation and check ciicuitry neither allows the
operator to determine if the program is running normally nor does it allow the diagnosis of the parity plane.
3. Although not absolutely necessary, it may be
advisable to have a diagnost.ic mode-in additiOll
t.o the RuperviRor and m~el' modes-so that special
conditions can be treated.
Fortunately no hardware changes were required
on the H-1200 or H-2200.
Description of the memory structure in the H-1200, H-2200
The basic unit of information is a character. The
H-1200 and H-2200 are variable word-length computers,
Each character in memory consists of 8 bits plus a
parity bit. Both machines have similarly organized
memories.
The memory is a fairly typical coincident current
memory. Each plane consists of 16K (lK= 1024)
bits. There are 9 planes in a stack. Two stacks constitute a drawer of 32K 9 bit characters. The memory
is modular with respect to drawers of 32K, i.e., there
is very little conunon circuitry between drawers. Even
within a drawer, some circuits are conunon to two
stacks while others are not. A block diagram of the
memory is shown in Figure 1.
Circuitry associated with the memory can be classified into three types;
a. l\1emory Address Register (MAR) Circuitry
b. Character Circuitry
c. Bit Circuitry
The memory address register contains the address
of the location to be accessed. The register is 18 bits
long allowing a maximum memory capacity of 262K
characters.
Circuits that are concerned with the selection of
a certain location (character) are classified as character
circuitry. Failure of these circuits will result in errors
in more than one bit of a character (theoretically
all bits of a character).
By bit circuitry is meant circuits that are predominantly concerned with the bits within a character.
The failure of any of these oircuits will affect a particular bit within a character.
In addition to the circuitry associated with the
memory, there are windings in the stack that could
open up. Examples of these are X-lines, Y-lines,
inhibit lines, and sense lines. There are 8 inhibit lines
and 4 sense Jines per plane.
Fault Location in :Memory Systems
395
EACH R/W LINE DRIVES 16
TRANSFORMERS FOR A TOTAL
OF 128
EACH SS LINE SELECTS
8 TRANSFORMERS - ONE
,.--:-Y--:-WR;;:::;;:IT;:;;E;----~;::...-:==------------. PER R/W DRIVE LINE
DRIVERS
Y
Y-WRITE
DRIVERS
SELECTION
SWITCHES
o - 16
Y-READ
DRIVERS
SELECTION
Y-READ
DRIVERS
SWITCHES
o - 16
0-7
0-7
X
0-7
0-7
X-WRITE
DRIVERS
0-7
INHIBIT
DRIVERS
0-3
X-WRITE
DRIVERS
0-7
INHIBIT
X-READ
DRIVERS
0-7
DECODE
==={
C. G.
INHIBIT
GATES
0.1
TO STACK 2
= CURRENT
GENERATOR
'---_ _~
INHIBIT GATE
ENABLES A PART
OF SECTION SELECTED
BY INHIBIT DRIVER
Figure I-Block diagram of H-1200, H-2200 memory
Types of failures
The types of failures that are diagnosed by AMNESA
are the following:
1. Circuit Failures
a. Output always high
b. Output always low
c. Output inconsistent (e.g., faulty sense amplifiers)
d. Input gating diode or diodes open
Shorted diodes are not considered when the
resulting errors are unpredictable. Fortunately,
diodes usually open and cases of shorted diodes
are extremely infrequent.
2. Open (cut) windings
3. Core Failures
4. Memory address register failures consisting of
bits stuck to "0" or "1."
Testing procedures
Before one can diagnose failures, one has to be
able to detect them. In other words, information
has to be read into memory and then read out. Much
work has been done into the nature of the words
that should be utilized. There exist patterns for generating worst-case disturb voltages on sense windings,
patterns to heat up the cores and so on. In our case
it is usually enough to write and read three different
words. The first is a word consisting of all binary
I's and the second its complement (all O's). Unfortunately, on any memory using odd parity on an even
number of bits (as is normally done), the parity bit
is the same; i.e., 1 for the first two words. Therefore,
for the diagnosis of the parity plane another word
which forces the parity bit to 0 should also be used.
A:\INESA tests the locations using three different
words as described above.
Diagnosis
Temporarily removing the restriction to memories,
it is obvious that, for the testing and diagnosis of a
system, certain test points have to be made available
to the program. The tenn test point is used in a very
general sense; i.e., any internal part of the system
that can be monitored. These test points generally
consist of operands, indicators, and status information.
For memories, the only test points required are those
396
Spring Joint Computer Conference, 1969
which are anyway available-the bits in the memory.
Define any location in the memory as bad if the
information read from that location does not match
the data written in . .LA:i.n:;t fault in the memolj1 S)Tst-em
(with one exception) can be visualiz.ed as partitioning
the memory into two classes consisting of the addresses
of the locations that are bad, and the other corresponding to the good locations. Let us call such a partitioning
a pattern. Naturally, the pattern can be identified
uniquely by considering either class. Since every
fault creates a pattern, our problem of diagnosis
reduces to observing the pattern and identifying the
fault. If all faults created w-llque pat~rns, the diag~
nostic wpuld achieve Objective 2 perfectly.
If several faults cause identical patterns, the resolution of the diagnostic (the number of p.c. cards
that have to be tested by other means in order to
find the faulty card) suffers.
The exception referred to above occurs when a
fault occurs in the memory address register (MAR).
Normally there is a one-to-one correspondence between the n-tuples (addresses) in the MAR and the
2 n locations in memory. When a bit in the MAR
fails, this correspondence does not hold any longer
and the true correspondence holds only for 2 n - 1
addresses. .Addresses loaded into the MAR are in
. some cases translated into other addresses. No parity
errors will occur and a special algorithm is required.
1. MAR diagnosis. When a system has several
modules, there is usually a local MAR for each one.
If any local MAR fails, the diagnostic can be loaded
into another module. If the main MAR fails, this
part of the diagnostic should be in a separate memory
(such as a read-only memory) or should be executed
manually. One method of MAR diagnosis is to write
the address of each location into the location and then
read sequentially from the bottom of memory. This
algorithm only indirectly aims at diagnoSis. The
following algorithm is considerably better.
Let the MAR consist of n bits numbered 0,1 ...
n-l from the least significant side.
(i) Write into locations (2n-l)-2i] where i= 0,1,
... n-l, some word.
(ii) Write into location (2n-l) some word X.
(iii) Read from the locations in step (i) using the
algorithm that if location [(2n-l)-2i] contains
X, bit i is bad where i = 0,1 ... n-1.
The operation of this algorithm is not as straightforward as it looks. An example will clarify the algorithm (see Figure 2).
Let the MAR consist of 4 bits. Assume there are
two errors-bit 0 is stuck to "0" and bit 3 is stuck
to a "1."
BIT NO.
4
3
2
1
1
x
x
o
Figure 2-4-bit memory address register \vith two bit failures
(i) Clear memory.
(ii) Write into location (15) some pattern X.
The pattern we have written will not be
written into (15), but into (14).
(iii) Read (see Table I),
Table I-Memory address register diagnosis
f
Location
Actual
Location
Accessed
1110
1
I
I
I
(Location)
= X?
Diagnosis
1110
Yes
Bit 0 is bad
1101
1100
No
Bit 1 is okay
1011
1010
No
Bit 2 is okay
0111
1110
Yes
Bit 3 is bad
If (14)
(13)
(11)
( 7)
I
I
I
i
contains X, bit 0 is bad
contains X, bit 1 is bad
contains X, bit 2is bad
contains X, bit 3 is bad
Thus the diagnostic is able to detect and isolate multiple
errors in the MAR. Any number of MAR bits that
are stuck to "I" or "0" will be diagnosed.
2. Circuit and Stack Diagnosis. For diagnosis it
is necessary to know which locations were found
bad, on which (ones or zeros) test they failed, and
how many bits and which bits within a character
were bad. If one has to store exactly which locations
were bad, prohibitively large buffers would be necessary.
Thus a better system to store error locations has to
be found.
The selection of a particular X-line and Y-line
results in a particular location being accessed. For
the selection of an X·-line, an X-selection switch,
an X-current generator, an X-driver output have
to be selected (see Figure 6). In Figure 1 it is seen
that a current generator drives 8 drivers--4 drivers
in each stack.
Let us see what happens if X-driver No. 3 in stack
F'ault Location in I\1emory Systems
No. 1 is always high. X drivers are decoded from
bits R15, ROO, and R05. The above X-driver has
at its input RI5.Roo.R05. In addition, the X-current
generator with R07 at its input has to be selected.
Thus, all locations in the area RI5.Roo.R05.R07
will appear bad on a ones test. These locations are
the blocks 30 - 37 (see Figure 4.) In this case errors
would have been found because no current would
have been supplied to the X-line.
Now consider a case where the output of the same
driver is always low. In this case, all locations corresponding to R07.R15.R06.R05, R07.R15.R06.R05.
R07.R15.R06.R05. R07.RI5.R06.R05. R07.R15.R06.R05, R07.RI5.R06.R05, R07.RI5.Roo.R05 will appear
bad. This is because when these locations are accessed,
a current split takes place, i.e., the current from the
selection switch splits between two drivers-the one
selected and X driver No.3 in the first stack.
Thus, in this case blocks 00-07,10-17,20-27 in
the first stack and 00-07,10-17,20-27,30-37 in the
second stack will appear bad.
The next case to be considered is when an input
diode opens up. Assume that the diode input for R05
is open at the input to X-driver No.3. This X-driver
will come up in the following cases:
BLK. NO.- 0
L)
1
2
397
7
0
0
0
0
~
\0
C;;
(Y)
I
J
J
J
Sl L1 DO
s4 L1 DO
S3 L5 D2
S2 L5 D2
Sl L5 D2
s4 L5 D2
S3 L1 DO
82 L1 DO
82 L2 DO
Sl L2 DO
84 L6 D2
83 L6 D2
82 L6 D2
........... /" ..........
lJc
84 12 DO
83 L2 DO
83 L3 D1
82 L3 D1
Sl L7 D3
84 L7 D3
83 L7 D3
82 L7 D3
Sl L3 D1
84 L3 Dl
84 L4 D1
83 L4 D1
82 L8 D3
Sl L8 D3
0
g~6
1
t-
(Y)
37600
37620
037
040
2
0
0
\0
057
060
3
CU_
.l.JO
On
100
117
120
1~7
1 0
6
157
160
84 L8 D3
83 L8 D3
177
l
ADDRESSES
82 L4 D1
L
~o
t- t-
t- tt-rl
t-rl
Orl
t- tt- tt- rl
(Y)"';rlrl
81 L4 D1
I
t- tt- tt- rl
t- 0
rlC\J
J
t- tt- tt- rl
t-o
C\J(Y)
8 = 8EN8E LINE NO.
L = INHIBIT LINE NO.
D = INHIBIT DR. NO.
Figure 3-Functional map showing relationship between
addresses and sense, inhibit lines
When locations with: R07.RI5.R06.R05
R07.RI5.R06.R05 in their addresses are accessed.
Every memory is driven by circuits that essentially
form a decoding matrix where the decoding is done
from the bits in the MAR. (See Table II).
Table II-Memory address register decoding
Bits numbered from least significant end ROI-RI8
Circuit
MAR Bits No. 's
X - Selection Switches
ROI, R02, R03, Ro4
X - Read/Write Drivers
R05, Ro6, R15
X - Current Generators
R07
Y - Selection Switches
Ro8, R09, RIO, RII
Y - Read/Write Drivers
R12, R13, Rl5
Y - Current Generators
Rl4
Stack Select
Rl5
Drawer Select
R16, R17, Rl8
Inhibit Driver-
R14, R07, R05
Inhibi t Gates
R15, Ro6
In addition there is the property of uniqueness, i.e.,
for every combination of bits in the MAR only one
location is accessed. Thus the memory can be represented by a functional map in which the variables
are the bits in the MAR.
Such a map has been drawn for the H-I200, H-2200
memory plane (see in Figures 3, 4). For purposes
of convenience, the plane has been sectioned into
64 blocks (numbered from 00 to 77) of 16 X 16locations
each. Now the problem of determining error patterns
becomes straightforward. Except. in a few cases, all
error patterns can be classified as distinct sets of
blocks (see Figure 5). A few examples will clarify
this. Of these two cases, the second is legitimate.
Therefore, blocks 10-17 in the first stack win appear
bad.
This leads us to the problem of resolution. If it
is found that blocks 30-37 in the first stack are bad
and all other locations are okay, we can conclude
that the failure is due to one of the following possibilities:
a. X driver No. 3 in stack No. 1 may have failed.
b. The trouble may be due to an input diode
(see Table III) ..
398
Spring Joint Computer Conference, 1969
Table III-Resolution problem
Blocks 30-37 in Stack 1 Bad
R15
m
I
m
I
Rl~
I
I' ~ I
R13
I
R;3
,~I,~,ml~lm!~lm!~1
CIRCUIT
INPUT
BAD DIODE
ON CIRCUIT
X Dr. #3
Stack 2
RI5.R07.R06.R05
R15
X Dr. #1
Stack 1
RI5.R07.Rob.R05
X Dr. #2
Stack 1
RI5.R07.R06.R05
0
1
2
4
3
5
6
7
see
4 b.
R07 _R05
_1
ROb
R05 2
Ro6 _
R05
AMNES. .A... can guess whether the errors are due
to CaEe (a) or case (b). It is found that in case (b)
all the locations in blocks 30-37 are bad. Even though
there is a current split, some locations seem to work.
In case (a) all locations in blocks 30-37 look bad. .
Even though AMNESA does indicate the probable
cause of failure in this case, it also indicates all other
possibilities.
Failures of other types of circuits are diagnosed
in a similar way. From Figures 3, 4 and Table II
it can be seen that knowing the bits of the MAR
which f jed the input gating to the circuit, one can
pI e lict the error pattern that will be found when a
circuit failure occurs.
It can be seen that some patterns will be subsets
of larger error patterns. For example, when a current
generator fails, the error pattern is a superimposition of
the error patterns for 8 drivers-4 in each stack (see
Figure 5). Al\INESA does not print anything conclusive until all possible patterns are examined. It
can also be seen that multiple failures will not confuse
the diagnostic because multiple failures will only
result in superimposed error patterns. As soon as
AMNESA finds the largest error pattern, it diagnoses
the failure, prints it out and halts. Other failures
can be diagnosed by fixing the problems one at a
time and rerunning AJVINESA.
Failures in windings result in unique error patterns
which are easy to recognize. The locations associated
with each sense line and inhibit line are indicated
in Figure 3.
Failures in bit circuitry are also diagnosed by A~INE
SA. Inhibit driver and sense amplifier failures lead
to error patterns that are superimposed patterns for
inhibit or sense lines in both stacks. The decoding
for inhibit drivers is done on three decode packages.
Failures in the decode packages will result in error
patterns corresponding to failures in inhibit drivers.
However, the outputs from the inhibit decodes feed
R05 3
R15---
R05 5
R07 _ _
R05 6
Ro6 _
R05 7
I I I I I I I I I
I I
IL.l
I
I
I
I
I:I
I I
I
I
BLOCK 07
MAGNIFIED
16 X 16 LINES
R12
Figure 4-(a) Functional map showing how decoding
structure relates to addresses (b) Block 07 in (a) enlarged
inhibit drivers in all nine planes of each stack. Thus,
it is easy to distinguish between inhibit decode failures
and inhibit failures even though the error patterns
are the same. In the former case all bits of a character
are affected while in the latter case only one bit iH
affected.
Parity plane testing is outlined in Figure 7. When
errors are found by AMNESA and no error pattern
is apparent, i.e., the errors look random, the diagnostic assumes that these are due to bad cores. A
Fault Location in Memory Systems
CASE 1 - STACK 1
CASE 1- STACK 2
6~23Jt..s~r
012
--
o
3~567
o
1.
2.
1
l\\'\ l\\\ \\\' \\\'
f
399
3
3
4
4-
WRITE
PATTERN
INTO
L.QCATION
5
6
IIIIIIII
7
(b)
READ FROM
SAME
CASE 2 - STACK 1
CASE 2 - STACK 2
LOCATION
0:1.234567
o
1
o ~~~+-+-+-~~~
~~~~~+-4H~~
l.
2
&
7
YES
~---------,~
31~~~~~~~~
3
It
5
~~~~~+-4W~~
2 ~~+--+-+-+-~~~
DATA BAD
PARITY MAY
BE BAD
~ 1--I--f.~~-+--4--+--4
t--+--~~lfri-i+rr...t---t--I
6
7~~~+-~~~4-~
YES
~~L-L-~UU~~~
(c)
PARITY
BIT
BAD
~ = Y C.G. NEVER COMES ON
~
= X R/W
DR. NEVER SELECTED
(- ;.;.::. . ,= GROUNDED
1lIIIllII.::.
SENSE LINE #2
DATA AND
PARITY
OKAY
STORE
ADDRESS
AND PROCEED
Y R/W DR. NEVER SELECTED
FigUl'e 5-Examples of error patterns. In both cases multiple
error:;; are present
Figure }-Parity plane testing
memory functionally and to choose a convenient
block size so that most error patterns can be expressed
in tenus of blocks. In most cases it is enough to know
which block a particular faculty location belongs to
and the exact address does not have to be stored.
AMNESA initially just counts the number of errors
per block and then proceeds to correlate this information with expected error patterns. Memories can
generally be subdivided into blocks so that such an
approach is always possible. In addition to simplifying
programming, such a functional map helps to visualize
error patterns (see Figure 5).
AMNESA
Figure 6-Diagram showing drive line selection scheme
printout of bad error locations is provided. Examples
of error patterns are given in Figure 5.
The approach taken has been to represent the
1. General. The program itself is composed of two
segments. The first segment tests the memory drawer
with different tests and detenmnes and stores error
patterns found. This is followed by preliminary diagnostic routines that search for patterns that would
400
Spring Joint Computer Conference, 1969
be caused by failures of circuits in the "0" level (see
Table IV).
The second segment is composed of diagnostic
routines that try to correlate the failures detected
by the first segment. This part_ of AMNESA searches
for failures in circuits in higher levels.
2. Printouts. The first segment of each program has
four posffible printouts for each circuit tested. They
are:
a.
b.
c.
d.
PACKAGEFAULTY*****
NO ERROR FOUND
PROBLE::.vl SEE:\IS TO BE ELSEWHERE
TEST INCON"CLUSIVE*
The second segment can output:
e. READ WHAT THE DIAGNOSTIC HAS
PRINTED OUT PREVIOUSLY, or
f. DISREGARD PREVIOUS PRINTOUTS
XXXXXXXXXXXX
The X's above indicate an error message. An example of a printout with actual errors is shown in
FigureS.
In the case of intermittent failures in any circuit,
the second segment will print:
the fault causing the error is usually indistinguishable
between X packages. This X is referred to as the
resolution of the diagnostic.
,Vhat one would ideally like is to have diagnostic
with a resolution of 1 package for all possible errors.
Unfortunately, this is not always possible.
For all transistor failures the resolution of A..vINESA
is 1. For diode failures the resolution varies from
1 to S in the worst case.
The above is not as bad as it looks because the
ratio of transistor failures to diode failures is about
5 to 1. The chances of cases occurring in which the
resolution of AIVINESA is 8, are relatively very low.
The pity is, AMNESA isolates the fault down to
4 to S particular diodes in the worst case. Unfortunately,
these diodes can be on different packages-resulting
in a low resolution.
4. Limitations.
a. In many cases, shorted diodes will most probably
not be found by AYlNESA. Fortunately,
the probability of such failures is relatively
very low.
b. Open sense lines will lead to noise on the sense
lines. The results are also unpredictable.
SUMMARY
READ WHAT THE DIAGXOSTIC
HAS PRIKTED PREVIOUSLY
The operator then scans the first segment printouts for "TEST IXCOKCLUSIVE." If a test for
any circuit has resulted in an inconclusive test and
no other failures exist, that circuit has a malfunction.
3. Resolution. Given that an error has occurred,
DISREGARD PREVIOloS PRINTOuTS
ERROR I N PARI n
PLANE
INHIBIT URIVER NO. 0 SEEfo!S tlAC -
SEE CuMMENT 7
COl"MEI'H 7 •••••••••••••••••••••••••
CNE Of SEVERAL Tl-INGS flAY BE WRONG.
A.
GC BACK ANC LOOK AT TME RESULTS FuR THl. O'S TEST FOR
THE I"HIBIT tRIVERS.
IF YOU HAVE A tilT EflPOP AND IF UNto UR MORE OF THE INHIBIT
DRIVERS HAVE BEEN ''''CICATED FAuLTY CK iNCONCLUSIIIE. CHECK
THE PACKAGE CONTAI"'I"'G THE INHltllT DRI vERS FOR THAT BIT.
IF ERROR PERSISTS. CHECK HE THE TIOLI SEI\iS~ PACKAGES FOR THAT BIT.
IN THE CASE OF A
tI.
ilO~O
EI on I;"
Nu~
of refer.,ces
OCl:
Nu~r
of distinct documents among references
BYN:
Nu""" of bytes ;n tenn stem (h... 6)
F512 3 2 I (0) OP
correct correction
corrections
3553 2 3 I (I) JOP
3634 34 5 2 (3) J P
correlcorrelateEJ
correlation
correlations
0 3 I (5)
NO. roeS.
22
4
16
4
6
1
512 4 I
(2) OP
516 6 9
(3) OP
512 3 I I (0) OP
512 141 (I) OP
512 0 5 I (5) OP
516 3 9 2 (I) OP
516 9 II 2 (3) OP
2
F512 4 2 I
~
2
512 5 7 I (I) OP
512 II 7 I (I) OP
541 II 2 I (3) OP
512106 1(3) OP
512 2 4 I (4) OP
516 10 I I 2 (3) OP
516 8 10 2 (3) OP
I
f~}
OP
5
4
2
3
2
2
3437 8 3 I (3) OP 3124
3634 33 5 2 (3) J P
21
I
17
3
7
2
6
3
I
4
3
JOP
Figure 5-Inverted file listing (excerpt)
&191;'" wood> ;n term (hero I)
EWN:
~
of
EDS:
Nu"""
of d;ffe,ent end;ngs (hero
DeEl
CAJ':
lit to indicate variable capitalization
REfl:
NurrOer of referiMe. for the work -magnetic·
END CODE 2 (e.g.,";cs")
1099 21 I I (3) JOP
512 6 7 I (I) OP
516 10 I I (3) OP
512 9 3 I (2) OP
516 7 I I (3) OP
516 8 I I (3) OP
516 7 10 2 (3) OP
516 4 2 2 (4) OP
1030
CWl:
RFl:
END CODE l (e.g.,";c")
REFI
corcore
cores
cor- e steel
The merged shreds are processed into the inverted
file structure shown in Figure 4. This operation takes
about 1.5 seconds per document for the combined
subj'ect/title inverted file (title words and terms are
distinguished from subject words and terms by a unique
HEADER
N)
DeEl: Number of distinct documents referring to "magnetic N
HEADER
~~I~T
1
REFERENCE-WORD FORMAT
END CODE N (e.g., "s")
DeEN
REFN
I .~
f~1':~~T
~I
_-_0___---;:1 L
DDc_""""""
ATTRIIUTES
REF I.REFI
. REF 2.1
,
:~:~~:O
JI
•
ON:
I,
•
W/p:
Is t ..m a ,WIgle wOe< fo< tIN, ".Feronc. (f_ I to N)
WT:
Tho subject/mi. w';ght (Ievol).
W:
h document whol. work?
{u
I
~crrH~~~
p
PROPERTY CODE
j-:
I,,
REFERENCES
'
IW/p IWN I TN I EN I WT I W : J i 0 : I ON I
REFERENCES
:::
FOR T E R M S '
AllOW FOR
EXPANSION
{I,:
REF N.I
0-
EF
N.REFN
T
-*.BWl
467
0<
full phruoe (P)?
f~
given document.
J:
Is docu"..,t iournol article?
0:
0.- doc_ ,.floct o<;ginal work?
P:
is document wril't8'l for profesional?
Figure 4-Format for subject-term list
- - - - - GENERATION - - - - - - - ' - _
I
I
I
I
I
r
----RETR'EVAl
Figure 6-Intrex storage and retrieval system
I 2 (3)
OP
Spring Joint Computer Conference, 1969
468
diagram of the storage and retrieval programs) for the
interactive interrogation of the catalog from remote
consoles has been implemented. The system, termed the
Prototype System, has been used, in conjunction with
a data base including about 1000 documents, to begin
experiments with users as described in a later section.
15
TST7X5:
READY.
USERS = 16,
IU login mS806
25 W 1315.7
2U
35
Description of prototype system
The Prototype System permits the user to search the
data base for documents by specifying subj ects, authors and/or titles. The user may then make a selection
among the documents retrieved by requesting that
MAX = 47.
(24) TITLE
Ferroelectricity in solid hydrogen halides
2. DOCUMENT NUMBER 3430
marcus
(2t) AUTHOR
Sihvonen, Y. T.
P_ord
STANDBY LINE HAS BEEN ASSIGNED
MS806 160 LOGGED IN 08/19/68
1315.9 FROM 8O(fl77
LAST LOGOUT WAS 08/15/68 944.4 FROM BOO277
HOME FILE DIRECTORY IS MS806 CMFL01
(204~
TITlE
Photoluminescence, photoc:urrent, and phase-transition correiations
3. DOCuMENT NUMBER 3174
DUE TO HARDWARE DifFICULTIES, CTSS OPERATION MAY BE
IRREGUlAR.
CTSS BEING
l.I-sec IS TST7XS
7. DOCUMENT NUMBER 1690
R 6.166+1.016
3U
45
(21) AUTHOR
WiII_, R. H.;
resume intrex
W 1316.8
Greetings This is Intrex la. Please sign in by typing yaur name and
address as in the foll_ing exa""le:
Buehler, E. (JA)
Matthias, B. T. (JA)
(24) TITLE
Superconduc:tivity of the transition-metal carbides
smith, r i/mit 13-5251
4U
55
Output completed. Total of 7 documents found. You may nt:Nf see
additional output on these documents by making a n_ 'output' request (for
information on how to do this, see Part 8 of the guide or type info 8).
You may also select a portion of these documents by making a ~ 'infield'
request (see Part 9.5). Otherwise, you may make a n_ search (see Part
2) or make ott- requests (see Part 1).
Note that your sign-in statement should end with a carriage return.
READY
marcus, r s/mit 35-.406
If you already knt:Nf h_ to use Intrex, you may go ahead and type
in commands. (Remember, each command ends in a carriage retum.)
Otherwise, for information on how ta make si""le queries of the
catalog, type
info 2
or, to see the Tobie of Contents (Part 1) of Intrex-l Guide which will
direct you to other parts of the Guide explaining how to make more detailed
queries, type
5U
65
info 1
READY
info 2
Port 2 of Intrex lA Guide:
eu
95
(22) AFFILIATION
University of > Tokyo <. Institute for Solid State Physics;
University of > Tokyo < • Institute for Solid SIote Physics;
University of > Tokyo<. Institute for Solid State Physics
Si""le Queries
(74) MATCHSUB
Ta find documents in the system specify your query by subject, author,
and/or title tenna, as shown in the 3 exa""les below:
subject ferroelectric transitions
phase transition at 1_ tetll>erature in solid h~ halides (0).
i. DOCUMENT NUMBER 3430; RELEVANCE 2/3
author Hess, G. B./subject helium
(22) AFFILIATION
>Texas< Instruments,
title sulfurization/author Swisher
>Oollas<
(74) MATCHSUB
In order to specify additional restrictions (e.g., where author comes
from, journal, word variations not to use, etc.), see Part 9 of the Guide
(or type info 9). For other than standard output (document nurreers, mies,
and authors) see Part 8. For general lotrex cOmmand format and abbreviations
see Parts 6.1 and 6.2.
To lee Table of Contents for Intrex la Guide and how to use
the Guide on line, typ
(TITLE)
3, DOCUMENT NUMBER 3174; RELEVANCE
213
6. DOCUMENT NUMBER 1715; RELEVANCE 2/3,
2/3
(22) AFFILIATION
info 1
Sandia Laboratory, > Albuquerque < ,
Otherwise, you may make si""le queries or use any ott- c")IIIIIIQI'Id.
READY
6U
75
READY
output affiliation matchsub relevance/go
1. DOCUMENT NUMBER 2851; RELEVANCE 3/3
>N. M.<
(74) MA TCHSUB
second-order phase trarwition in peravskites (3);
first-order phase trarwltion (0);
7. DOCUMENT NUMBER 1690j RELEVANCE 2/3,
subi ect solid phase transitions
A search on your query SUBJECT solid phas-e transit-ions found 7 documents.
ia output the catalog fields DOCUMENT NUMBER, TITlE, AUTHOR an those
documents type
2/3
go
READY
This output will take about 15 seconds per document. You may terminate
this output at any time by hitting the ATTN key ONCE. Otherwise, you may
change your output request. For information see Part 8 of Guide or type
9U infield affiliation harvard/o 71/110
105 .1. DOCUMENT NUMBER 3174
infa 8
or change your field restriction (see Part 9.5) or make another request of
Intrex (see Part 1)
READY
~~
r.
DOCUMENT NUMBER 2851
( 71) ABSTRACT
The hiih.;.t~erafure series expansion of the zera-field magnetic susceptibility
"chi*f"chi**sub Curie*
1 + *SIGMA*-sub 1 l*sup *infinity**a*lubl
is related to the diagrammatic representation of the corresponding
expansion of the zero-field static spin correlation function INT. 1
Ooes the criREADY
quit
Thank you for using Intrex.
R 109.583+20.800
=
fOU
115
(21) AUTHOR
Hoshino, Sadooj
Shimaoka, Kahji (JA);
Ni imura , Nobuo (JA)
Figure 7-Sample demonstration system dialog
=
Experimental Computer-Stored, AUg!llented Catalog of Professional Literature
their catalog records contain specified information in
certain fields. Finally, he may. request that the information contained in any or all of the catalog fields be
printed out.
In order to illustrate the nature of the Prototype
System more concretely, a sample user-system dialog
is given in Figure 7. The dialog has been retyped in
~hortened line-width form from the typewritten copy
prepared on an IBM 2741 teletypewriter console attached to the time-sharing system (CTSS). For illustrative purposes each user statement is flagged by a
number and the letter U in the left margin. Similarly,
system Illessages are flagged by numbers and the
letter S.
In his first two statements the user has logged-in
to the time-sharing system (CTSS) which hosts the
Prototype System as well as many other computer
programs. Note that the user's second statement, his
password to CTSS, is not printed because the 2741 is
set to the nonprinting mode by CTSS to protect the
security of the password. This log-in procedure will be
unnecessary for individual users situated at consoles
dedicated to Intrex use.
The third user statement "resumes" the "Intrex"
system (at this point the user could have called for any
other program currently resident in CTSS) and in the
fourth statement the user "signs in" to Intrex by
typing his name and address. The" sign-in" statement,
in conjunction with the monitoring procedures (see
below), provides us; as system analysts, with a means
for keeping track of system use. It also serves to introduce the user to certain system procedures. For example, the user is apprised of the fact that his statement must be terminated with a carriage return. (Note
that a more natural statement-terminator button or
switch will be possible with the Intrex display console.)
'Vhile, at present, the sign-in statement merely serves
to aid in monitoring system use, we anticipate future
system developments whereby some history of past
users is kept so that, when someone signs in, the syst~m
can take account of his previoub experience to help
direct him.
Intrex response to the user's sign-in statement,
message 5S, is illustrative of several features of the
prompting and instructional techniques employed by
the system. In the first place, the user is told of the
various alternative actions that he may take at any
given time. Secondly, the specific form of the statement he should type to invoke one of these actions is
e~plicitly stated, where possible. Thirdly where it is
not possible to explain the alternatives completely, the
user is referred to a Guide for further details.
The Guide is available both in hard-copy form and
Part 1 of Intrex lA Guide:
469
Table of Contents
To have a part of the Guide printed out on line use the
"Info" command. For exa",ple, for Information on makinr;
simple Queries (I.e., to print out part 2), type
Info 2
PART
1
2
3
~
5
6.1
6.2
7
8
9
10
11
12.1
12.2
13
14
15
16
17
CONTENTS
Table of Contents
Simple Queries
General Remarks - How to Get Guide (printed copy)
Log-In to CTSS and Call Intr~x
Typing Errors - How to Correct
Commands, Modes (LONG, SHORT), Time Checks
Command Names and Abbreviations
Preliminary Output
Final Output
Generalized Queries
Scanning Index Terms
Interrupting System Messages
Text ~ccess
.
Library Services
User ComI'Ients and Questions
Documents In the Collection
The Catalog and Its Fields
Sample Catalog Record
Exit from the Syste'"
This online guide
INTREX lA as of
2~
Part 2 of Intrex 1A
w~s
last revised on
7/2~/68.
JUL 68
Guld~:
Simple Queries
To find docu"'ents In the system specify your Qu~ry by
subject, author, and/or tltl~ terl'ls, as shown In the 3
examples below:
subject ferroelectric transitions
author Hess, G.B./subject helium
title sulfurlzatlon/author Swisher
In order to specify additional restrictions (e.g.,
where author cOl'les frol'l, journal, word variations not to
use, etc.), see Part 9 of the Guide (or type Info 9).
For
other than standard output (document numbers, titles, and
authors) see Part 8. For general Intrex command for"'at and
abbreviations see Parts 6.1 and 6.2.
Figure R--8ections from Intrex guide
online. Selected pages of the Guide are shown in
Figure 8. The user may request that a section of the
Guide be printed online by using the INFO command
(see user statement 5U and system response 6S). The
Guide also attempts to use the techniques of presentation of alternatives, example, and reference to more
detailed information. The sections of the Guide are
sized for convenient printing and viewing online.
The user's sixth statement initiates a search in the
inverted files for documents on a given subject. Searching may also be done on title or author terms or combinations of subject. title and/or author terms. It may
be noted that the form of the user's statements is a
compromise between the precise, but esoteric and
complicated, form of many programming languages and
the familiar, but ambiguous (and, therefore, difficult to
interpret automatically), form of natural English. Command and argument names are simple and mnemonic.
470
Spring Joint Computer Conference, 1969
Format is kept simple with only three basic delimiters
required: spaces to separate arguments from each other
and from command names, slashes to separate commands, and a carriage return to terminate the
statement.
In response to the user's search request, Intrex replies with a message (7S) illustrative of several other
features of system dialog. In the first place, the system
plays back its understanding of the user's statement.
Also the system indicates, by hyphenating word endings, how it has stemmed the words in the user's search
specification. This is important because Intrex matches
these word stems to word stems in the inverted file. As
a further indication of the progress of the retrieval
process, the number of matching documents found in
the inverted files is printed. Since the user made no
special output request in statement 6U, Intrex reports
the estimated time to output the standard catalog
fields. This system message, then, gives feedback which
may interact with the user's original intentions and
expectations and allow him to redirect his search.
The points at which the system reports to the user
have been chosen in light 'of the operating characteristics
of the host CT8S time-sharing system. The intention is
to report back soon enough so that the user experiences quick response but not to report so often that
the user is forced into unnecessary additional responses
of his own. The incorporation of the buffer-controller
computer for the Intrex display consoles will improve
the operating characteristics of the time-sharing environment and may allow more frequent feedback with
less cost at the central-computer level.
In our sample dialog the user takes the first alternative (statement 7U) and the system responds with
the standard output (message 8S) for the matching
documents. The ellipses (...) in the figure indicate
where portions of the system response have been
deleted to reduce figure length.
At this point in the dialog, let us assume that the
user already knows how to make an output request or
that he refers to his hard-copy version of the Guide.
In any case, the user's eighth statement requests additional output information. Note that by appending
the GO command to the OUTPUT command, the user
signifies he is sufficiently sure of his statement not to
want Intrex to respond with its interpretation and
timing estimate but rather to print the requested
output immediately.
The system then responds (message 9S) as directed.
Note the special output information giving those subject terms that matched (lVIATCHSUB) and the estimated relevance of these terms. The relevance of a
subject term to a user query is currently estimated
simply by the ratio of the number of words in the
query which match words in the term to the total
number of words in the query.
In statement 9U the user is selecting~ by means of
an INFIELD command, a subset of the seven documents which his original search found. This command
enables the user to request only those documents in
which a specific character string (here, "harvard")
appears in a particular catalog field (here, "affiliation").
Note that, at the same time, the user is changing his
output request and using abbreviation "0" for the
command name "output" and "71" for the field name
"abstract' , .
In the system's response (message lOS) to the above
request, the user has availed himself of the interrupt
capability and halted the output at the point indicated
by the letters "INT 1." The system then responds
with the READY message indicating the user may go
ahead with other requests. The interrupt capability is
a general facility allowing the user to cut short system
messages. After the user has become familiar with the
system he can reduce the' verbosity of system messages
by entering the SHORT mode. He may do this at any
time during the dialog or even upon resuming the
system as shown in Figure 9.
resume intrex short
W 1355.1
Please sign in.
R
marcus r s/mit 35-406
R
s solid phase transitions/in affiliation harvard/o 22 abstract/go
1. 0 3174
(22) Lyman Laboratory of Physics Harvard University, > Cambridge < ,
>Mass.<; / lincoln Laboratory M. I. T., > Lexington < , >Mass.<
(71) The high-temperature series expansion of the zero-field magnetic
susceptibility, *chi*/"chi**sl)b Cl)rie* = 1 + *SIGMA**sub 1 = 1*svp
*infinity**a*sub 1*( J/k T)*sup 1*, is related to the diagrammatic
representation of the corresponding hh-tiNT. 1
are then
R
s transint*'" tions/a hoshin%
21 74 75
S: transit-ions / A: hoshino found: 1 doc
sees/doc.
0:
21, rei, msub
R
ogo
Sorry, I can't understand you.
R
go
1. 0 2851
(21) Hoshino, Sadao;
Shimaoka, Kohji (JA);
Niimura, Nobuo (J A)
(24) Ferroelectricity in solid hydrogen halides
1 docs found
quit
Thank you for using Intrex.
R 36.050+ 10.433
Figure 9-Sample dialog in SHORT mode
15
Ex-periTIlental COTIlputer-Stored, Augnlented Catalog of Professional Literature
Monitoring system use
Embedded in the retrieval system is a monitoring
system which records, on a disc file for later analysis,
all user commands and system responses as well as
certain timing information. In addition, a shared console remote from the user console may be employed to
monitor experiments in real time.
With the COMMENT command a user may input a
comment about the system, the catalogi."tJ.g,
. or the docu=
ments in the collection. These comments are recorded
by the monitoring system. Comments about the catalog
may result
modificatibns to the catalog at some
subsequent update whereas comments about the documents may get entered into Field 85 (see Table I) of
the pertinent catalog records.
in
console sessions (which lasted between about one-half
and one hour).
Results
Results of these first experiments are still under
analysis and, in any case, the small size of the sample
user population and still modest size of the data base
make it clear that these "results" can only suggest
future lines of investigation and cannot provide de:firti~
tive conclusions. With these caveats in mind we make
the following tentative observations:
1. Users learned to operate the basic features of
2.
User experiments
The users
3.
When the size of the data base reached about 1000
documents, experiments utilizing the Prototype Retrieval System were begun with users having a real need
for information. The first user was a second-year graduate student in physics (from the first of the research
groups mentioned in an earlier section) who was starting
a project to measure the magnetic susceptibility of
europium sulfide near the critical point. He had already
compiled a bibliography on this subj ect through conventional library techniques but was still seeking information on the light absorption properties of EuS to
properly set up his experimental equipment. Six additional users were taken from the ranks of the Intrex
catalogers by giving them a description of the student's
problem and asking them to serve as reference librarians
using the Intrex system.
Experimental environment
Users were seated at a 2741 console with no personal
instruction. They had previously been given a hardcopy version of the Guide (at least a day in advance) to
which they could refer during the retrieval session.
Other user aids (besides the system dialog as exemplified in Section 6), included messages pasted on the
console (e.g., "Don't forget the carriage return"); wall
charts (to remind the user how to perform common
functions); the NASA Thesaurus 16 (to suggest semantically related words for user search requests); and the
Inverted File listings (to suggest additional search
words as well as show document counts for index
terms). "Gsers were given extensive debriefings (up to
an hour and a half) by systems analysts after their
471:
4.
5.
6.
the system fairly easily and found all or most of
the relevant documents rather quickly.
The users, in the hour or so of their acquaintance with the system, mastered few of the
sophisticated features of the system nor did
they really understand the nature of the matching algorithm.
Users without previous computer experience
tended to be awed by the computer which inhibited their trying, and learning, system
features.
The difficulties listed under (2) and (3), while
not hindering user retrieval seriously for the
sample problem, could adversely affect results on
other problems and could degrade our efforts to
determine the relative merits of various augmented-catalog features.
One possible solution to some of these problems
is to advance the user's understanding in stages
by starting with simplified guides or with personalized instruction.
Users dislike and are confused by command
mnemonics that are not single English words
(e.g., ~1ATCHSLB, I~FIELD).
Futw·e plans
Enlarging the data base, improving system efficiency, improving user aids (see previous section), and
. expanding user experiments are high on the list of
planned proj ects. Incorporation of the Intrex console
and text access systems into the retrieval system is "also
an immediate prosp~ct. The first full version incorporating all Intrex subsystems will find the Intrex
console operating in a "transparent" mode so that this
console will look like a standard CTSS console and
present retrieval programs can be used essentially unchanged. As experience is gained with this siinple
configuration an attempt will be made to shift some
CTSS operations to the satellite computer associated
with the Intrex consoles.
•
472
If
Spring Joint Computer Conference, 1969
I
As mentioned in the Introduction, a number of
features have been deferred in order to get the
Prototype System into operation as soon as possible.
Spme of these features are listed below. The schedule of
their incorporation will undoubtedly be determined to
some extent by our experimental findings.
One major area under study is the question of
matching algorithms and relevance. As indicated above,
matching is done on a modified "anding" of all query
terms. One would like the user to have the ability to
specify any combination of " ands", "ors", and" nots"
among query terms, to control the relative emphasis
on words witpin the search specifications, to make
online modifications to the relevance and matching
criteria (by term ranges, for example), and to seleclively override the stemming and phrase decomposition
algorithm.
Other improvements being planned include: searching restrictions on document properties or subject
term ranges; decoding of catalog fields (for example,
"English" for "e") on output; more general INFIELD
specifications (for example, ranges on dates); online
display of inverted file terms and frequency counts;
naming lists of documents or commands for later
reference; and an overlay procedure for reading in
sections of the retrieval program from disc storage as
the overall size of the retrieval system expands beyond
core memory size.
~'ystem
Related work
Two further capabilities that we hope to incorporate into future augmented-catalog experiments have
been studied by two students working toward :\1.S.
d~s. l\1r. Richard Domercq17 has studied the automatic derivation of synonomy and hierarchical relati~ps among the subject terms on the basis of
oo-oecurrence. l\1r. William Kampe 18 has investigated
automatic methods for deriving subject terms from the
title and abstract of a document.
Throughout the work on storage and retrieval of
oo.talQg data we have been conscious of the problems
that will be encountered in scaling up a computer~red augmented catalog by two orders of magnitude.
Fo~ a collection of one million documents, we estimate
that the total information stored in the catalog will be
of the order of 2 X 1010 bits. About 15 percent of this
iQf~ation will reside in the inverted files. A· preliminary study of file organization, cost, and speed of
response of such a catalog has been conducted by
Professor A. K. Susskind.19 He has arrived at a conceptual design that will perform inverted-file searches
at an average rate of 40 per second with a storage
lktvice
that costs about $250,000. On-line storage of the
,
complete catalog entries appears prohibitively expensive with today's technology, and new mass-storage
concepts must be examined. lVlultiple reading-head,
high density, continuous motion magnetic tape devices
appear promising and are being studied.
ACKNOWLEDGlVIENT
The research reported in this paper was supported
through grants from the Council on Library Resources,
Inc., the National Science Foundation and the Carnegie Corporation.
REFERENCES
1 J F REINTJES
System characteristics of I ntrex
Proc S J C C 1969 ~
2 D R HARING J K ROBERGE
A combined display for compuwr-generated data and
scanned photographic Images
Proc S J C C 1969
3 D R KNUDSON S N TEICHER
Remote wxt-access in a computerized library informationretrieval system .
Proc S J C C 1969
4 H P BURNAUGH
The BOLD (bibliographic on-line display) syst.em
In: Schecter George ed. Information retrieval-a critical
review Thompson Washington DC 19675:3-66
5 D J SULLIVAN D M MJ:l~ISTER
Evaluation of 'USer reactions to a prototype on-li'tlR information
retrieval system [REGON]
In: Proc of the 30th Annual Meeting of the American
Documentation Institute New York October 1967
6 M RUBINOFF - S BERGMA~ W FRANKS
E R RUBINOFF
Experimental ellaluation of information retrieval through
a teletypewriter
C A C M Vol 2 No 9 September 1968
7 G SALTON
A uiomatic information organization and retrieval
McGraw Hill New York 1968
8 MM KESSLER
The "on-line" technical information system at 1lf I T
Project TIP
In: 1967 IEEE International Convention Record
Institute of Electrical and Electronics Engineers
New York 1967 part 1040-43
9 E B PARKER
Stanford physics information retrieval sysi.em (SPIRES)
Annual Report
Stanford Institute for Communicat.ions Re..Ilber of user terminals is quick
enough to test the principle of on-line browsing. It
is anticipated that the partial specifications for a
device capable of storing a much larger collection
will be among the results of the INTREX experiments.
The transmission subsystem
The transmission subsystem links the user terminals
to the central station via a unidirectional coaxial
line. The coaxial line is time shared among the user
terminals; therefore provision is made for uniquely
addressing each terminal. Synchronizing pulses for
the entire system are generated by an oscillator contained in the transmitter section of the TASC logic.
The output of the oscillator is divided to produce a
basic clock frequency of 280 kHz which is further
divided by programmable counters to produce the
horizontal-synchronizing pulses. The number of scan
lines is d~termined by a programmable line counter
that counts these pulses. The programmable counters
provide the flexibility for switching automatically
between user terminals having differing scanning
parameters.
The horizontal-synchronizing pulses are transmitted
continuously to the user terminal. The time between
pulses may be occupied by no signal, or an analog
video signal corresponding to one line of an image, or
a sequence of pulses representing a digital word.
Each frame of video is preceded by two 16-bit digital
words and followed by one or two digital words. The
digital messages are used to control the user terminals.
A 6-bit address code is assigned to each user terminal;
thus, commands may be sent to anyone of 64 possible
terminals while others remain idle. The standard
ASCII seven-bit code has been chosen for the commands
so that a full character set is available. Commands
that operate the receiver terminals such as ERASE,
ADVANCE-FIL1VI, and BEGIN -VERTICAL-SWEEP
were chosen from the ASCII control characters.
The synchronizing signals, digital address and digital
command signals, and the analog video signals are
Remote Text Access
combined in a line driver for transmission to the
user tenninals over coaxial cable. Presently base
band transmission is used but the signal format need
not be changed if it is decided to utilize a modulatedcarrier type of transmission.
A matched filter and threshold comparator in the
receiver of ef',uh user terminal separates the digital
codes from the analog video sigr,q 1. The decoder
functions as an address detector and interpreter of
the digital commands. A feature of the video circuitry
is the automatic gain control which compensates for
slow variations in the system gain which might result
from temperature variatio:r:.s and/or changes in the
separation distances between transmitter and re~eiver.
479
medium is potentially more economical in cost per
page because there is no material expenditure for each
qisplay request. If the text is always available within
seconds from a central store, it is expected that much
of the need for hard copy will be eliminated. Unfortunately, there is no existing transient-display
device with the resolution and writing speed required
for the text access system, but the direct-view electronicstorage tube comes closest among the current.ly
available devices.
Adequate resolution is achieved with the microfilmfacsimile tenninal. The output of this tenninal is a
35-mm film strip which is automatically processed in
approximately one minute and read with the aid of
microfilm viewers.
Textual-image displays
Library users are accustomed to the traditional
fonns of textual images, such as books and journals,
which provide high-quality images and many other
features including portability, browsing capability,
gray scale, color, etc. Many of these features are difficult to achieve in a remote display and a completely
satisfactory device for displaying textual images is
not yet available. Although the text-access display
may suffer from comparison with the traditional
textual fonns, this is offset by providing guaranteed,
rapid access to full text at a console conveniently
located near the researcher's working area.
The detailed requirements for the Intrex displays
have been reported previously and are reviewed in a
companion paper at this conference. The singleframe-transmission feature of the text-access system,
requiring image storage at the user tenninals, has a
significant effect on the types of displays that are
suitable for this system. The video signal could be
stored and used to generate a refreshed CRT display.
However, the bandwidth in excess of 60 ::\11Hz required
for a flicker-free display with adequate resolution is
a serious obstacle to this approach. High-order interlaced scanning reduces the bandwidth requirements
somewhat, but some brief experiments performed by
our group with pseudo-random scanning indicate
that sufficient bandwidth reduction cannot be achieved
to make the refreshed textual display practical.
Two types of display terminals are included in the
initial system. One uses an electronic-storage tube
and the other uses 35-mm film for image storage.
The cathode-ray storage tube is an erasable, soft-copy
display and the film tenninal provides a fonn of hard
copy. The soft-copy display pennits rapid access to
text because the image requires no processing. A
browsing capability requires a response time of at
most a few seconds between pages. An erasable storage
Storage-tube display
A block diagram of the storage-tube display tenninal
is presented as Figure 3. The terminal consists of two
main components, the Tektronix type-611 StorageDisplay Unit and the electronics for controlling the
display and user inputs. It is designed to be selfsufficient in that it requires no external power supplies.
The storage tube terminal is located adj acent to
the augmented-catalog console and is intended to
provide a quick-look at full text as a supplement to
the catalog searching operations. The limiting resolution
of the Tektronix eleven-inch storage-display unit is
approximately 400-line pairs in its long dimension
which is considerably less than the 1000-cycles/page
that the image-transmission experiments showed to be
a minimum for high-quality textual images. The lack
of resolution and gray-scale capability results in an
information loss particularly for small symbols for
characters, and in pictorial material. In addition the
brightness of the Tektronix 611 is marginal for viewing
in a well-lighted room. However, the display is not
intended for prolonged reading or for detailed text,
but it is appropriate for evaluating the usefulness of a
Video
Tektronix
Type 611
II-Inch
Storage
Display Utit
ErCl5e Signal
Figure 3-Storage tube display terminal
Viewing
Screen
480
Spring Joint Computer Conference, 1969
soft-copy, stored display as part Of the text-access
experiments.
In addition to the input devices at the catalog
console, a nwuber of illUt"ninated switches are located
at the storage-tube display and are connected to the
console. Two of these, PAGE-FORWARD and PAGEBACKWARD, enable the user to request the following
or preceding page in a document by pushing a single
button.
A third function switch is used to initiate the magnify
mode which is designed to compensate, in part, for
the limited resolution of this display. In this mode,
an illuminated rectangle with dimensions approximately one-half the full page size appears as an overview on the display. The rectangle outlines' the page
sector to be m3.0O'nified and can be moved t(. anyone
of nine positions by means of a pushbutton matrix
at the display. When the re-(Iisplay button is pushed,
the quarter-page sector outlined by the rectangle is
scanned and transmitte:. This gives a factor-of-two
magnification of that page .:;~ctor and improves the
legibility of small characters which might not be
recognizable on the full-page display.
Several indicator lights are included at the storap-'+tube terminal to inform the user ()f the status of his
request such as FICHE-NOT-FOUND, LAST-PAGEOF-DOCUMENT, and REQUEST-IN PROCESS. The
pushbuttons and indicators are ligtiied in a programmed
sequence to assist the infrequent user in operating
the terminal.
M icrofilm-Jacsimile terminal
resolution cathode-ray tube from the video signal.
The automatic-camera and film-processor unit will
record on 35-mm film the image of the displayed text
and deliver to the user a fully processed strip of film
in a convenient form for viewing in a microfilm reader.
A camera-processor unit that satisfactorily met
the INTREX requirements was not found to be
commercially av~ilable. The camera-processor pictured
in Figure 5 was manufactured by attaching a modified
Kodak film unit to a GAF automatic film processor. 2
This 1- :-oces.:;or utilizes a horizontal straight-line film
transport that is self-threading and accepts short
strips of 35-mm film. It should be noted that the film
processor was designed for films of 12-inches maximum
width, and for a much heavier volume of processing
than ¥t6 anticipate. It appeared after a SUiV"ey of
available film processors that the GAF machine comes
closest to meeting our needs, at least on a temporary
basis.
Initially the request for a film copy, made by the
user at the catalog console will result in a film strip
containing the entire text of a journal article if the
documunt contains eight or fewer pages. Longer documents will be filmed in 8- page increments. Provision
has been made to allow the user to combine short
documents on a single film strip.
Approximately 20 seconds is required to complete
the filming of an eight-page document after the receipt
of a request by the text-access central station. Mter
the filming of the last page in a sequence, a digital
conunand transmitted from the central station initiates
The microfilm-facsimile terminal, diagrammed in
Figure 4, consists of a high-resolution cathode-ray
tube with its associated SWeep and focus circuitry,
an automatic camera-processor, and control logic
required to operate the terminal. On command from
the central station, the microfilm-facsimile tenninal
will reconstitute a page of text on the face of a high-
C
it.
5;_1
Figure 4-The
microfilm~facsimile
terminal
Figure 5-The camera processor
Remote Text Access
the processing of the film strip which requires approximately 70 seconds.
User acceptance of the micJ.:ofilm output is largely
dependent upon the convenience of handling and
viewing the 35-mm film strips. After emerging from
the processor, the film strip is inserted into a transparent jacket which facilitates handling and protects
the film. A strip along the jacket edge can be written
on with pen or pencil for identification purposes.
The film in the jacket is inserted into a microfilm
viewer for reading.
An Addressograph Multigraph Model 3000 electrostatic copier is being modified such that 8 1/2-by-11inch paper copies can be made from the 35-mm film
images. There is some degradation in the copying
process and these copies lose some resolution compared
to the 35-mm film image. However, the modified
machine will supply, at locations remote from the
central store, a traditional form of hard copy that can
be read without the need for a viewer.
SUMMARY
A system for providing guaranteed, rapid, and remote
access to the full text of the 10,000 documents in the
INTREX collection has been described. Consideration
of the more general problem of storing and displ~ying
the textual image has indicated the practicality of
facsimile image storage on microfilm and of singleframe transmission from a time-shared central station
to the user terminals. In the initial INTREX textaccess system, photographic images of text are stored
on microfiche which are accessed by a computercontrolled storage and retrieval device. Retrieved
fiche are automatically positioned in order that the
proper frame may be scanned and transmitted as a
single frame of video to either of two user terminals.
A direct-view storage-tube display unit, placed adjacent to the catalog console, provides rapid access
to text although with marginal resolution and brightness. A microfilm-facsimile terminal provides adequate
resolution, but the film-processing time and mechanical
complexity of the terminal are significant disadvantages. Document requests are entered through the
augmented-catalog console. The processor associated
with the catalog buffer/controller maintains the
queuing and message-formatting algorithms for the
text-access system.
The text-access system is currently operating in
the laboratory and is part of the INTREX facilities
intended for user experiments. Evaluations of these
experiments should provide new insights into the
481
library user's requirements for text-access which will
lead into the incorporation of new techniques and
equipment.
ACKXOWLEDGMENT
The research reported in this paper was conducted at
the Electronic Systems Laboratory, Massachusetts
Institute of Technology, as part of Project Intrex
and was supported through grants to Project Intrex
from the Council on Library Resources, Inc., and the
Carnegie Corporation.
REFERENCES
1 J F REINTJES
System characteristics of intrex
Proc S J C C 1969
2 Project Intrex Staff
Project intrex semiannual activity report
September 15 1968
3 D R HARING
Computer-driven display facilities for an experimental
computer-based library
Proc F J C C 1968
4 C F J OVERHAGE R J HARMAN (editors)
I ntrex report of a planning conference on information
transfer experiments
MIT Press Cambridge Massachusetts 1965
5 U F GRONEMANN D R KNUDSON
S ~ TEICHER
Remote text access for project intrex
ESL TM-312 July 1967
This report based on a Conference paper presented at the
~ational Microfilm Association Convention Miami Beach
Florida April 26-28 1967
6 D R KNUDSON S N TEICHER J F REINTJES
U F GRONE MANN
Experimental evaluation of the resolution capabilities of
image-transmission systems
Information Display September/October 1968
7 A VAN DAM J C MICHENER
Hardware developments and product announcements
Annual Review of Information Science and Technology
Vol21967
8 P BROWN S JONES
Document retrieval and dissemination in libraries and
information centers
Annual Review of Information Science and Technology
Vol 3 1968
9 D R HARING J K ROBERGE
A combined display for computer-generated data and
scanned photographic images
Proc S J C C 1969
10 R S MARCUS P KUGEL R L KUSIK
An experimental computer-stored augmented catalog of
professional literature
11 P A CRISMA (editor)
The compatible time-sharing system
MIT Press 1968
A combined display for computergenerated
d~t~
anll scannell
p'hotographic images *
by DONALD R. HARING and JAMES K. ROBERGE
Massachusetts Institute of Technology
Cambridge, Massachusetts
BACKGROUND
Project Intrex (INformation TRansfer EXperiments)
is a program of research and experiments intended to
provide a foundation for the design of future information-transfer systems. The library of the future is
conceived as a computer-based communications network, but at this time we do not know enough details
about such a network to design it. Lacking are the
necessary experimental facts, especially in the area of
user's interaction with such a system. To discover these
facts, we want to conduct experiments not only in the
laboratory, but above all, in the real-life environment
of a usefu1 operating library.1.2
The initial efforts of Project Intrex have been concerned with the problems of access-bibli~graphic
aooess through an augmented library catalog, and
access to full text. This paper describes the design of
the initial computer-driven display facilities being
developed for the Project Intrex experimental computer-based library. To provide further background
information, we will first give some details of the
augmented library catalog and the text-access system
that are being developed.
For a number of reasons, computer-based libraries
that service a wide spectrum of users, such as are found
in a university, will be faced with operating on two
basically different types of data-that which is digitally
stored and that which is photographically stored in
• The research reported here was made possible through the
extended the Massachusetts Institute of Technology,
ProJect Intrex, the Electronic Systems Laboratory, under
Contract NSF-C472 from the National Science Foundation and
the Advanced Research Projects Agency of the Department of
Defense, and under Grant CLR-373 from the Council on Library
Resources, Inc.
sup~rt
some microfilm form. The latter wi11 be images of the
original full text of the documents contained in the
library, whereas the digital data will constitute the
augmented catalog of the library from which the library
user gleans information about th'~ library data and documents by conducting interactive computer searches.
One of the concerns of Project Intrex is to conduct
a series of experiments to determine how the traditional
library catalog can be effectively augmented and
combined with on-line computer operation to provide
users with a more powerful, comprehensive, and useful
guide to library resources. Present plans ca1l for augmenting the traditional library catalog in scope,
depth, and search means. For example, the augmented
catalog will contain entries for reports and individual
journal articles as well as the traditional entries for
books. Furthermore, in addition to the title and author
of each item, such things as the bibliography, an abstract, key words, and key phrases of each item will
be included as part of its catalog entry.2.3 A user will
be able to conduct searches on nearly any combination
of the data contained in a catalog entry. Present plans
also call for providing alphanumeric communications
between user and computer by means of a high-speed,
flexible display console. 2.4 ,5
Another concern of Project Intrex is to conduct a
series of experiments in an effort to devise a workable
system that will ultimately provide guaranteed, rapid
access to the full text of journal articles, books, reports,
theses, and other library materials at stations that
are remote from the central store. This goal has several
implications. Guaranteed accessibility implies that
text never leaves its store and is therefore available
to users at all times. Availability with minimum de]ay
at remote locations implies transmission of text in
--------------------------------483--------------------------------
484
Spring Joint Computer Conference, 1969
electrical signal fonn, except in special, limited situations where physical transmission (perhaps by pneumatic tubes) might be appropriate. Remote accessibility
implies more convenient library use, and in addition
is a preliminary step toward realization of a network
of computer-based libraries coupled together by means
of data communication links. 2 ,6
In order to conduct meaningful experiments, a
small-scale experimental total computer-based library
system containing some 10,000 systematically-chosen
documents in materials science and engineering is
being designed and constructed by Project Intrex. 2
The computer-driven display console discussed here
is a part of this system.
Figure 1 illustrates the general organization of the
exnerimental library. The library operates roughly as
foilows: The digitai data and th~ photographic images
are created from the original documents. The fonner
are placed into the storage of the time-shared computer
(an 1 Blll 7094 system) and the latter are placed into
a microfiche storage and retrieval unit (a modified
Houston Fearless CARD machine). In the original
system the stored data are then accessed through
augmented-catalog user consoles and text-access user
terminals, respectively. This paper is concerned with
the description of an experimental display that can
accommodate both the augmented-catalog digitallycoded data and the video infonnation generated by
scanning (in facsimile fashion) the full-text photographic-image data.
The plan of this paper is to first briefly discuss the
display requirements of the Intrex experimental
library and then to describe the display techniques
that are being developed. Because of the differences
between the storage fonn and content of the catalog
(digital, alphanumeric) and the full text (photographic
images, graphic), and because of the differences between user interaction with the catalog and full text,
we find it convenient first to describe the two displays
separately, and then to describe the combined display.
Previous papers and reports have described the
Intrex experimental computer-based Hbrary, the display
requirements, and the separate displays for the augmented-catalog and full-text data. 2- 7 These papers
should be consulted for further details of these subjects.
This paper will concentrate on the features unique to
the present display and the details of certain system
parameters not discussed previously.
Augmented-catalog display requirements
Detailed examination of system requirements,
coupled with the general intent of Proj ect Intrex to
BUFFER I
CONTROLLER
AUTOMATiC RETRIEVER,
ELECTRONIC SCANNER,
and TRANSMITTER
Figure I-Project Intrex experimental library
provide sufficient flexibility for meaningful experimentation with information transfer techniques led
to the requirements outlined in this section. A more
complete explanation of underlying system requirements is presented in References 2 and 5.
A refreshed display seems preferable to a stored
display which can be changed only with a complete
new transmission from a remote computer. The use
of a refreshed display complicates local memory
requirements, but facilitates local editing and permits
the use of a light pen for message identification.
A large capacity display which can present all the
available data about any given entry is more pleasing
than a smaller display which may require viewing
several different messages concerning a single document. Similarly, comparison of key words or bibliographies of several documents is simplified by a large
capacity display. These considerations, coupled with
the resolution capabilities of inexpensive cathode-ray
tubes (CRTs) led to the choice of an 19OO-character
display.
I t seems desirable to expand the character set
beyond the 96 visible characters of the USASCII set.
In particular, the scientific data base anticipated for
Intrex experiments makes the addition of Greek letters
and more mathematical symbols a necessity. Furthermore, it should be possible to reproduce SUbscripts
and superscripts in a natural and pleasirig manner. It
also seems advantageous to have an easily alterable
character set so that foreign documents can be cataloged fn their own alphabet if desired.
There is also the underlyihg objective of developing
a display which is economical to reproduce, since
Combined Display for Computer-Generated Data
economy is one important factor in the large-scale
acceptance of the Intrex concept.
,
485
56 CHARACTER SPACES/LINE
\
The display tube and deflection technique
Much of the expense of large capacity refreshed
alphanumeric displays reflects the cost of the CRT
and its deflection electronics, and any meaningful
attempt at cost reduction must consider this equipment.
The resolution necessary to display 1800 characters
is not demanding. The 500 X 700 line resolution of
monitor quality entertainment CRT's allows upwards
of 12 resolvable elements in both dimensions of a
character and this resolution is sufficient for highquality characters. A more fundamental difficulty is
encountered when the deflection bandwidth normally
required for rapid character generation is considered.
In order to refresh an 1800 character display at a
nominal 60 Hz rate (sufficient to prevent flicker) it is
necessary to generate characters in approximately
8.5fJ.s. Two popular generation methods are the selective intensification of a dot matrix or a pattern
from a stroke generator. The mechanization of either
a 5 X 7 dot matri~ generator (which does not produce
partibularly attractive characters) or· a 20-segment
stroke generator requires deflection-system settling
time on the order of O.lfJ.sec. The cost of this type of
deflection system for a large screen CRT is high at
the present time.
An alternative is the use of a TV type scan which
is relatively narrow band. However, a conflicting constraint is introduced by the memory. Economics
dictate the use of a serial memory such as a magnetic
drum or a delay line for display maintenance, and the
cost of scan conversion equipment for such a memory
appears to outweigh the advantages of the TV scan.
The scan selected for the alphanumeric display
consists of two parts. The basic raster illustrated in
Figure 2 is generated and applied to deflection amplifiers which drive a conventional deflection yolk. The
raster pattern provides for 31 lines of 56 characters
each, refreshed at a 57.5 Hz rate. (Actual timing
allows for 32 lines of 64 characters each, but one line
per raster and 8 character spaces per line are reserved
for retrace.) It ils important to note that the deflection
bandwidth requirements for this pattern are significantly less demanding than those of a conventional
TV raster.
A 600-kHz sinusoidal signal which provides a peakto-peak deflection amplitude slightly in excess of the
maximum anticipated character height is added to
the vertical deflection signal. This sinusoidal signal
•
•
31
LINES
•
•
TIME FOR 1 LINE SCAN :I 460p.1.
RETRA~E IN 70p.1.
REFRESHED AT 57.5 Hz RATE
Figure 2-Basic raster pattern
forms the scan pattern on which characters are generated by appropriate intensity modulation. (The method
used to generate video information is described in the
following section.) The advantage of the sinusoidal
scan is the limited bandwidth necessary to reproduee
a single-frequency sinusoid. In practice, the 600 kHz
signal is amplified by a tuned narrow-band amplifier
with a transformer-coupled output. The secondary of
this transformer i~ placed in series with the vertical
deflection coil and the output of its deflection amplifipr
to provide the scan si~nal.
The linear segments of the 600-kHz signal provide
10 scan lines per character space. In order to further
improve the quality of the characters, the phase of
the scanning sinusoid rs changed by 1800 on alternate
frames. This process is analogous to the interlacing
used in TV transmission and results in improved
resolution wilthdut i.;ncreaslng required video bandwidth.
The greatest demand on deflectipn bandwidth arises
when superscripts or subscripts are generated. In order
to display such a character, a code indicating the
desired operation is placed into the memory which
486
Spring Joint Computer Conference, 1969
contains the display data. The code adds a signal
corresponding to ± .%: or ± 72 of the nominal vertical
spacing to the vertical deflection signal. Simultaneously,
a signal corresponding to the spacing between characters is subtracted from the horizontal sweep. This
backspace technique allows inclusion of the control
code without creating blanks in the display. However
the settling time of both deflection amplifiers must
be less than the time normally used for a single character (8.5~s) for the method to be effective. Following a
time delay corresponding to one character, the elevated
or depressed character is generated normally and displayed in its correct location.
The first augmented catalog display system used a
$15 CRT from a TV set as the display element. The
deflection yolk was the one designed for use with the
tube, . modified by reducing the number of windings
on the vertical axis to approximately 20 percent of
its initial value. Figure 3 illus~rates the quality of
the characters produced by this inexpensive display
system. A moderate improvement in character fidelity,
particularly aJ, the edges of the displa'Yi ha.s been obtait"led using a monitor quality tube and an improved
deflection yolk. These improved components add
approximately $75 to the cost of the equipment.
The character generator
The choice of scan described in the preceding section
imposes constraints on the type of character generator
used in conjunction with the display tube. While use
of a digital read -only memory for character generation
is possible, this type of memory does not readily produce
video information for a sinusoidal scan pattern. An
extremely straightforward system is obtained if a
flying-spot scanner is used for character generation.
Figure 4 illustrates the major components of a character
generator using this principle.
The character set is stored ona photographic negative. (A picture of the character mask currently used
is shown in Figure 5.) This mask is located in front of
a small electrostatically-deflected CRT and can be
replaced easily to alter the character set. In order to
generate a character, the beam of the scanner CRT is
positioned to the left of the desired character. Beam
positioning is controlled by digital-to-analog converters in response to the code for the selected character. The character is then scanned by applying a ramp
as the horizontal deflection signal and a sinusoid derived
from the display-tube scan as the vertical deflection
signal. Light which shines through the character mask
is detected by a photomultiplier tube to produce the
video signal.
In order to achie,re resolution in the ~lertical direction
R""" Wavefono
Digital Inputs
Figure 3-A display of the output of the character generator
Figure 4-Flying-spot-scanner charact.er generator
Combined Display for Computer-Generated Data
®ABCDEFGHIJKLMNO
RABrLlEZH9IKAMN::O
II
f·
=11=
$%
a
I
(
)
*+
I
··'V-'~=~~cx)X·
•
/
: ++
\ abcde fgh i j k Imno
"CX{30bE~TJ8('KA.}J-V~O
PQRSTUVWXYZ[,,]"'ITPLLTTX'l'n/Le 0 °
0123456789· ; <=>?
3 'J 3 E C :::>C:::> < > !:::! ~ ex: :. #
pqrstuvwxyZ{ I}--'
7rp eT<; T tJ f cf:>x O/W £, ~ 1.. II
=
Figure 5-Character mask
compa~able to that produced horizontally, it is necessary to generate blanking pulses which are on the order
of 30 nanoseconds (ns) wide. The rise time of the
photomultiplier tube is less than 5 ns and a blanking
amplifier which switches the grid of the display CRT
40 volts in approximately 5 ns was designed for this
application. The limiting factor is the dec,ay time of
the P 16 phosphor used in the scanner CRT, and this
limitation dictated the use of a 600-kHz scan rather
than a higher value.
The monos~ope tubeS offers an alternative to the
flying-spot scanner character generator described in
thiH section. lVlonoscopes are available with 96 character targets, and two such units can share common
electronics to provide the desired 192 character set.
A disadvantage is the need to change monos copes to
alter the character set.
A more detailed description of the Intrex character
generator is presented in Reference 9.
The text-access display requirements
The differences between the augmented-catalog
display requirements discussed in the previous section
and the text-access display requirements are due to
the differences of the storage medium and types of
user interaction with the stored data. The catalog
data are digitally stored in a file that is attached to
the time-shared computer and is accessed through and
processed by that computer. The library user can
487
conduct computer searches on this data and modify
his copy of the data. Thus, if he wants hard-copy of
this data he can have the data organized in any desired
form. On the other hand, the full-text data are photographic images that are accessed through a mechanical
storage and retrieval unit that is attached to the
display facility. This data does not pass through a
computer. Its form cannot be modified (except for
magnification) and the user cannot conduct computer
searches on the data. The only access to full-text data
is by call number. Once the data is obtained, the
user can read it, can ask for other pages of the same
document or ask for a magnification of portions of
the page of the document. In short, the dynamics
and the dialog between man and computer are considerably different between the two display facilities.
With the original text stored in image form, the
problem of remote access to text becomes that of
reproducing a high-quality image at a remote point.
This usually implies scanning the stored images. Our
experiments have shown that at least 2000 scan lines,
with a total system on -axis limiting resolution of
1000 cycles per frame height from scanner to viewer,
appear to be needed for high-quality remote reproduction of microfilmed technical documents (18-to-l
reduction ratio) having average quality and containing
the SUbscripts, superscripts, and mathematical symbols
that frequently appear in these texts. 2 A two-column
page with approximate_ly 7p lines per column and an
average of eight to ten words per line is considered
to be a "typical" page.
Closed-circuit TV requires high bandwidth (80 MHz)
to achieve the desired resolution of 2000 lines per page.
Also, because the image is continually refreshed, a
separate scanner and transmission line would be
required for each simultaneous user. Hence, a facsimilelike system is used in which each text page is scanned
and transmitted only once, and the information is
captured and stored at the receiver for transient
viewing (soft copy) or printing (hard copy). This
organization permits a tradeoff between signal bandwidth and transmission time, and also permits time
multiplexing of the microfiche on which the image is
stored, the microfiche storage and retrieval device,
the scanner and the transmission line to serve a number
of users. For example, with a transmission time of
% a second per page, signal bandwidth for a 2000-line
scan is reduced to about 4.5 MHz (standard TV
channel bandwidth) and a single text-access system
can perhaps service 20 to 30 receivers, assuming that
users would request new pages at 10 to 15 second
intervals.
The soft-copy diBplay appears to be the more at-
488
Spring Joint Computer Conference, 1969
tractive because it more closely approaches the capability of providing immediate remote text access
and is potentially the least expensive to operate.
Assu...'T.ing a facsi..lTIile-type scan; tb-e following list.
summarizes the specifications of an ideal soft-copy
medium for single-page, full-text display.2.1o.11
1. Size: Display area should be approximately
872 by 11 inches.
2. Resolution: Minimum limiting resolution for
3.
4.
5.
6.
7.
8.
9.
any portion of the display area should be
equivalent to more than 1000 cycles per frame
height.
Brightness and Contrast Ratio: The viewable
image should be sufficiently bright to be comfortably seen in a room lighted for reading (60 to
160 foot-lamberts). The image should have a
contrast ratio of at least 15 to 1, a sharpness
(or acceptance) comparable to that of a printed
page.
Storage Time: At least five minutes
Viewing Position: Freedom from constraints
o-p. the user viewing position and freedom to
position an9. orient the display itself.
Gray Scale: Sufficient to faithfully reproduce
high-quality black-and-white photographs.
(eight gray levels)
Speed: Sufficient speed so that a complete
medium erase (or replace) plus write requires
approximately one second, with the time nearly
equally divided between the two operations.
Color: Sufficient color range to faithfully reproduce color photographs.
Cost: Cost of ownership (including cost of
storage medium) such that the display of a
page of text be significantly less than a hj:lro
copy of that page. (In the order of 0.01 cent
per page.)
Unfortunately, no presently available medium fully
satisfies these requirements. However, the Tektronix
Type 611 eleven-inch storage-tube display unit does
afford limited capabilities.
The storage-tube display
An evaluation of the Tektronix display unit indicates
that it can serve as a satisfactory experimental softcopy display. As regards our list of specifications for
a soft-copy medium, we make the following list of
observations.
6% inches by 834'
inches. This is adequate but preferably should
be somewhat larger.
1. Size: The display area is
Figure 6-Photograph of transmitted image as displayed on
a Tektronix storage tube
2. Resolution: Specified to be 800 cycles in the
large dimension. This is marginal, especially
for perception of poor-quality print or small
symbols and characters. Figure 6 shows typical
results obtained. (Note: There is some degradation due to the photographic processes.) It
is estimated that an improvement of approximately 25 percent in resolution is required.
3. Brightness and Contrast Ratio: The stored
luminescence of the storage tube is 3-foot
lamberts and operating contrast ratio of 2:1.
Hence, the general room lighting must be at
a lower level than normally used for reading.
4. Storage Time: Once an image is stored on the
tube, it remains until erased.
5. Viewing Position: The user must be relatively
c]Q.~ to the unit. He has a viewing angle typical
Combined Display for Computer-Generated Data
6.
7.
8.
9.
of most CRT's. Placed in the proper mounting,
the position of the unit can be adjusted to a
limited extent. The unit is not readily portable.
Gray Scale: The Tektronix storage tube has
only two light levels. Thus, the usual television reproduction of black-and-white. photographs is not possible.
Speed: Erase time is less than 0.5 seconds and
full-screen write time is approximately 2.5
seconds. These tinles ar-e acceptable in the
experimental system.
Color: The Tektronix storage tube is monochromatic.
Cost: Because of the high cost of the storage
tube and its relatively short life (approximately
1000 hours) in the storage mode, the cost per
displayed page is in the order of pennies per
page. Although too costly in an operating
system, this is acceptable in the experimental
system.
Operation of the Type 611 as a facsimile display
tenninal is straightforward. The self-contained amplifiers for the three axes have sufficient bandwidth for
the vertical and horizontal scanning signals and the
video signal. To match the erase. and writing speed
of the storage tube, the microfiche scanner completes
a 2000-line scan in 4 seconds. These signals are· transmitted to the Type 611 unit from the microfiche
scanner via a coaxial cable. The signal format on the
coaxial cable resembles a standard television signal
with vertical and horizontal synchronizing pulses
added to the video signals. Since a bus system is used
on the coaxial cable such that many display terminals
can be serviced by the same cable, digital control
signals are added to the combined video and synchronizing signal in the time slot immediately following
the horizontal synchronizing pulse (during storage
tube retrace time) to individually conunand the
various terminals. The digital control signal is in
the form of a 16-bit binary number, with the first
seven bits being the address of the terminal and the
last nine bits being the command. By this mechanism,
only the display terminal that is addressed responds
to the video signals and other control signals.
To accommodate the control functions sent on the
coaxial cable, each Type 611 display unit has a black
box added to complete a text-access soft-copy display
terminal. Specific details of the transmitted signals
and the black box design can be found in Project
Intrex Semiannual Activity Report dated 15 ::Vlarch
1968.2
To overcome the resolution limitation pointed to
above, an enlarged version of anyone of nine over-
489
lapping portions of a page of text can be requested.
The portion of the page to be enlarged is identified
by a rectangle that is displayed on the storage-tube
scre~m in the non-store mode and whose position is
under control of the user.
A combined display unit
Previous sections of this paper have indicated how
a CRT with limited deflection bandwidth is used
for a large-capacity display of digitally coded alphanumer-ic characters and how a Tektronix Type 611
Storage Display Unit is used for soft-copy display of
phot?graphically-stored material. The soft-copy display
unit is intended for operation in conjunction with the
augmented-catalog console, since it provides rapid
and guaranteed access to items which have been
discovered by means of a catalog search. Obvious
economics result if the two functions can share a
common display element.
The Type 611 can serve as the soft-copy textaccess display without modification. It would also be
possible to use thi;s unit for the display of digitally
coded datJa by combining stored-mode operation
with an appropriate character generator. There are
at least two disadvantages to this approach. First,
certain functions such as selective erasure andOlight-pen
identification which are important to the operation
of the augmented-catalog console, are not possible
with a stored display. Second, the storage tube is
expensive, and its life when operated in the storage
mode is limited to approximately 1000 hours. However,
the tube can provide a normal (non-stored) display,
and its lifetime is comparable to that of conventional
tubes when used in this mode.
The Type 611 can provide horizontal full-screen
deflection in less than 60¢" and a small-signal settling
time under 5p.s. Furthermore, the resolution of the
tube exceeds that required to display 2000 highquality characters. Note that the bandwidth and resolution capability of the Storage Display Unit ar~
comparable to those required for the refreshed alphanumeric display described in an earlier section. This
consideration led to the decision to use the Type 611
in a storage mode for soft-copy text display and, by
slightly modifying the unit, to operate it as a refreshed
display system for catalog information. The only
modifications which must be made to accommodate
the refreshed display are to include provision for the
sinusoidal scan signal and to improve the response
time of the blanking amplifier.
A transformer was added in series with the vertical
deflection amplifier output to provide the required
490
Spring Joint cOmputer Conf~rence, 1969
scan signal. Since the self-inductance of the secondary
of this transformer is small compared to the inductance
of the vertical deflection coil (1 mH), this additional
element does not alter the performance of the vertical
deflection system. A new blanking amplifier was also
designed for the Type 611. This amplifier switches
between ground and a level determjned by the setting
of intensity controls in approximately 5 ns.
SUMMARY
Two -basically different display functjons required by
a computer-based library have been discussed and a
single combined CRT display that provides these
functions has been described. The display is based
on a Tektronix Type 611 Storage Display Unit. The
first function it must accommodate is the output of
a character generator driven by the digitally-coded
library catalog data. By employing a character generator that requires a relatively narrow deflection bandwidth, only minor modification to the Type 611 is
required. When operating with the catalog data the
storage tube is used in non-store, refresh mode to
provide quick-response man-machine interaction and
to increase the lifetime of the tube.
The second function the display must accommodate
is the video information generated by scanning the
full-text photographic-image data. When operating
with the full-text data no modification to the Type
611 is required, and the storage tube is used in store
mode to provide a large amount of visual information
without external storage.
In addition to the display, a neW character generator
was described. It is basically a flying spot scanner
without lenses. A set of nearly 200 characters is defined
by a changeable photographic mask. High quality
characters are produced with relatively narrow deflection bandwidths.
REFERENCES
1 C F J OVERHAGE
R J HARMAN (editors)
Intrex report of a planning conference on information
transfer experiments
The MIT Press Cambridge Massachusetts 1965
2 Project intrex semiannual activity reports
M ! T Project !ntrex Ca..'1lbridge Massachusetts
March 15 1967 September 15 1967 March 15 1968 and
September 15 1968
3 A R BENENFELD
Generation and encoding oj the project intrex augrnentedcatalog data base
Proc 6th Annual Clinic on Library Applications of
Data Processing University of Illinois Urbana Illinois
May 71968
4 D R HARING J K ROBERGE
The augmented-catalog console for project intrex part I
MIT Electronic Systems Laboratory Report
ESL-TM-323 October 1967
Presented at the IEEE 1967 Lake Arrowhead Workshop
on Advanced Computer Peripherals at Lake Arrowhead
California August 25-27 1967
5 D R HARING
A display console for an experimental computer-based
augmented library catalog
Proc A C M National Conference and Exposition
Las Vegas Nevada August 27-29 196835--43
6 U GRONEMANN S TEICHER D KNUDSON
Remote text access for project intrex
MIT Electronic Systems Laboratory Report ESLTM-312 July 1967
Presented at the National Microfilm Association Conference
at Miami Beach Florida April 26-28 1967
7 D R HARING
Computer-driven display facilities for an experirn.ental
computer-based library
Proc F J C C 1968 December 9-11 1968255-265
8 Technical information bulletin
Type CK1414 SYMBOLRAY Character Generating
Cathode Ray Tube by Raytheon Components Division
Industrial Components Operation 465 Centre Street
Quincy Massachusetts April 15 1966
9 P F Me KENZIE
A flying spot scanner character generator
8M Thesis MIT February 1969
10 C T MORGAN J S COOK III A CHAPANIS
M W LUND
Human engineering guide to equipment design
McGraw-Hill New York 1963
11 H H POOLE
Fundamentals of display systems
Spartan Books Washington D C 1966
A study of multiaccess computer
communications
by P. E. JACKSON" and CHARLES D. STUBBS
Bell Telephone Laboratories, Incorporated
Holmdel, New Jersey
INTRODUCTION
but intricate. First, multiaccess computing is still in its
infancy. Therefore, computer system design is going
through a trial and error process ",ith a high rate of
change of system characteristics. Lacking a unified,
well-tested body of technical knowledge applicable to
the problems of multiaccess· computing, systems designers have been led to heuristic solutions to system
organization. Certain specific problems such as scheduling algorithms for single and multiple central processors have been studied in detail. No intensive, overall, general system studies, however, have been reported
with the C'onstraints of total cost minimization including the effects of system characteristics on communications costs and human factors such as reduction
in efficiency due to long turn-around times.
Second, the rate of change of the size of the user
community, the number of systems in operation, and
the introduction of new equipment and operating
systems is high. In fact, most systems are changing so
rapidly that a detailed characterization of anyone
will probably be outdated before it is completed. The
insight to be gained from such studies, however, far
outweighs the drawback of obsolescence. Indeed, this
situation calls for continued study and review.
Third, the applications of time-sharing are diverse.
Where one of the parties in the transaction is a person,
uses range from inquiry-response systems with short
call durations of a minute or less, to scientific problemsolving and certain types of business infomlation systems with call durations of 10 to 30 minutes, to computer aided learning with long call durations of one to
two hours or more. Where the transaction involves an
automatic terminal such as a telemetry device, call
durations may be measured in milliseconds. Also, the
volume of information exchanged in a computer-tocomputer or computer-to-data-logger interaction varies
widely from a small number of bits in polling, meter
The communications characteristics of multiaccess*
computing are generating new needs for communications. The results of a study of multiaccess computer
communications are the topic of this paper. The analyses made are based on a model of the user-computer
interactive process that is described and on data that
were collected from operating computer systems. Insight into the performance of multiaccess computer
systems can be gleaned from these analyses. In this
paper emphasis is placed on cmnmunications considerations. For this reason, the conclusions presented deal
with the characteristics of communications systems and
services appropriate for multiaccess computer systems.
The problem
Digital computers reqmrmg communications with
remote terminals exhibit a set of communications needs
which, in some respects, are different from those of both
voice traffic and other record communications. It is
important for the providers of data communications to
have an understanding of the broad characteristics of
this communication process so that new, more appropriate offerings can be designed to satisfy these needs.
Previous studies ** by the manufacturers and providers
of multiaccess computer systems have begun to characterize both the computer systems and their users. The
principal interest of these studies, however, has been
computer and/or user performance rather than data
communciations.
There are several reasons why the quantitative characterization of the communications process is timely
* The word "multiaccess" is chosen
to avoid confusion over the
use of the word "time-shared" which is often used synonymously
but which has a specialized meaning in some contexts.
** For example, see References 1, 2, 3 and 4.
491
492
Spring Joint Computer Conference, 1969
reading and some banking and credit services, to a large
number of bits in CRT displays, information retrieval
and file manipulation. The speed of transmission is
wide-ranging from the low bit rates of supervisory and
control terminals to megabits per second for CRT displays.
Fourth, the data required for such studies are microscopic in nature. Unlike voice traffic, which can be characterized by measures of holding times, arrival rates and
other parameters independent of a call's content, the
characterization of calls to a computer requires some
information about a call's content, e.g., timing informa-·
tion interrelating the transmission times of data
characters is essential for the design of an efficient
time division data multiplexer. An additional factor is
that some of the desired statistics on these data have
very skewed distributions. Thus, large data samples are
required. The implications of these considerations upon our study are that:
a. neW data gathering procedures and equipment
are needed,
b. data analysis procedures must be capable of
handling very large quantities of data,6
c. legal, ethical, and business requirements related
to communications and computing privacy must
be satisfied.
The problem, then, is to provide communications
services to a rapidly growing market of multiaccess
computer systems and their terminals. These exhibit
diverse and changing communications requirements.
The study described below is directed at this problem.
The modus operandi for this study is an in-depth
analysis of selected multiaccess computer communications systems. The subset of system types chosen for
detailed -study is composed of computer service providers whose systems are representative of multiaccess
computer installations. Besides representativeness,
additional prerequisites for the choice of a system to
study were that the use of multiaccess computing be
advanced, and that the provider of the particular system be knowledgeable in the communications area.
By "advanced in multiaccess usage," we mean that the
system be fully operational on a daily basis with the
initial break-in period accomplished. A final prerequisite
for inclusion in the study is the willingness of the computer service provider to participate in the study. *
* Part of the study reported herein involved the collection of
data from three operating multiaccess computer systems. In
every case these data were obtained on the premises of the
computer service provider and with this full permission and
cooperation. To ensure the privacy of the three systems under
discussion, however, they are not identified by name.
To ensure that a cross section of on-line systems was
included in the study, the characteristics of such systems were classified as shown in Table 1.
Table I -Classification characteristics for multiaccess
computer systemsjor communications study
1.
2.
3.
4.
5.
6.
7.
ComputerType
I/O Device Type
Loading (Number of Simultaneous Users)
User's Applications
User Community (In-House or Utility)
Error Control (e.g., Eohoplex)
Holding Time
In the table, by "computer type" we mean the manufacturer and model number of the central processor and
the system configuration, i.e., whether or not a separate
communications computer is used. Not all models of all
manufacturers can be covered, but at least two large
manufacturers were included for each application. I/O
device types include teletypewriter-like terminals and
TOUCH-TONE® telephones. Loading is the average
percentage of ports that are active. User's applications
include scientific and business programming, inquiryresponse systems, extended file retrieval and maintenance, message switching and mixtures of these.
Both in-house and utility systems were included.
Error control includes systems which retransmit each
character back to the terminal (Echoplex) and those
which do not';- The systems selected for examination
include short holding time systems with average call
durations on the order of one or two minutes or less
and long holding time systems with average holding
times of 20 to 30 minutes.
From the systems selected for detailed analyses,
measurements of three different categories were obtained. The first category included telephone facilities
measurements such as occupancies and overflow counts
on computer access lihes (port hunting groups) and pen
recordings of call durations from several terminal lines.
The second category of measurements was made by the
computer service providers withi~ their computer systems by identifying the arrival and departure times of
calls, the amount of central processor time used, the
serving port and an identifier of call type. Distributions
of call holding time, call interarrival time, CPU usage,
and port loading can be obtained from these data. The
third category of measurement was the collection of
data at computer ports describing the characteristics
of such microscopic statistics as intercharacter time.
The first two categories of data are being used to formu-
Study of Multiaccess Computer Communications
late traffic and engineering practices. These will be used
by telephone company personnel to provide appropriate
computer communications by properly configuring
existing telephone company equipments.
The third category of data is being employed in the
analyses reported here. These dat~ are required to investigate new systems and service characteristics such
as the desirability of various transmission speeds or
multiplexing methods, as they include detailed inforformation on the timing relationships within a call.
An analytic model of the communications process
between a multiaccess computer and a user at a remote
console is the vehicle being used to conduct these
analyses. The model describes the communications
process in terms of random parameters which give the
times between characters transmitted through the
communications network. All of the parameters are
measurable at the communications interface to the
computer, i.e., none requires the gathering of data on
internal computer processes such as the length of
various queues.
The model is used to focus on the user-computer
communications process and to exhibit how the characteristics of the computer and of the user affect communications requirements. It is also used to study the converse, i.e., how the constraints of the communications
medium affect the user and the computer. The model
does not directly represent the detailed characteristics
of the computer system or its organization or the internal operation of the user's console. Rather, it reflects
the effect of these on the characteristics of the communications signals entering and leaving the computer.
From the characteristics of the communications process, however, it is possible to employ the model to predict the effects of changing system characteristics such
as improving computer scheduling algorithms or increasing the computer's transmission rate. The following two sections further discuss this model.
The data stream model
The next two sections develop the data stream model,
the analytical model used to describe the stochastic
interactive communications process between user and
computer. In this section, the basic parameters of the
model are defined. In the next section, the relationships among the parameters are described and an expression for the holding time of the process is developed
where holding time is the duration of a user-computer
seSSIon.
Figure 1 illustrates the data stream model. A "call"
(or a connect-disconnect time period) is represented
as the summation of a sequence of time periods during
which the user sends ch,aracters without receiving, inter-
CONNECT
493
DISCONNECT
COMPUTER
USER
WRIT
SE• .,ENT
. . IT
SE • .,ENT
USER
INTER-
COMPUTER
~::
c
---L-U.J~.L.I......J..LJ...LL-......I...L.J...L..l.J...L.L..W
c
-;lr~~
t-----f -t I-USER
IITERCHARACTER
TIME
'UUS::T
I
I
~:
frmnn m D mm an
CO=~~ER
IDLE
TIME
INTER-
I
*•
TIME
1L ~:"~~R
COMPUTER
INT£RCHARACTER
TIME
Figure 1-The data stream model
leaved with time periods during which he receives characters without sending. (This implies half-duplex operation. Simple modifications to the model would allow
the accommodation of full-duplex operation.) The
periods during which the user is sending characters to
the computer are defined as user burst segments. The
periods during which he is receiving characters sent
from the computer are computer burst segments. A
user burst segment, by definition, begins at the end of
the last character of the previous computer burst segment. Similarly, a computer burst segment begins at
the end of the last character sent by the user. The first
burst segment of a call begins when the call is established and the last burst segment ends when the call is
terminated as measured at the computer interface.
Within a given burst segment, there are periods of
line activity and of line inactivity. The first inactive
period of a user burst segment is defined as think time.
That is, think time is the time that elapses from the
end of the previous computer character until the beginning of the first user character in that burst segment.
In most cases, think time is employed by the user to
finish reading the previous computer output and to
"think" about what to do next. The corresponding
inactive period in a computer burst segment is called
idle time. In some systems idle time represents time
during which the user waits for the return of "line
feed" after sending "carriage return"; in other systems,
idle time represents time during which the user's program is being processed or is in queue.· The remaining
inactive periods within a burst segment are called intercharacter times and interburst times. A prerequisite for
their definition is the definition of a "burst."
Two consecutive characters are defined as belonging
to the same burst if the period of inactivity between the
characters is less than one-half character width. Thus,
each "burst" is the longest string of consecutive characters where the period of inactivity between any two
consecutive characters is less than one-half character
width. All of the characters in a burst must, of course,
be transmitted from the same party (user or computer).
Spring Joint Computer Conference, 1969
494
For example, every character of an unbroken string of
characters sent at line speed is in the same burst.
For characters within the same user burst, an inactive time between two consecutive characters is called
a user intercharacter time. The corresponding parameter for computer bursts is computer intercharacter
time. For bursts within the same user (computer)
burst segment, the inactive time between two consecutive bursts is called a user (computer)interburst time.
Five final parameters of the data stream model are
number of user bursts per burst segment, number of
'computer bursts per burst segment, number of characters per user burst, number of characters per computer burst, and temporal character width (time from
start to end of one character).
For a gi,\rcn llser=computer enviroIln1ent, a knowledge
of the distributions of the parameters defined above
allows the calculation of some interesting measures.
Examples are distributions for (a) holding time, (b)
percent of holding time during which the communication channel carries data, and (c) amount of delay
introduced by the computer. The next section shows
how some of these distributions can be calculated from
the parameters.
Relationships among data stream model parameters
In summing expressions over these indices, the primary
index will be shown as a subscript and the secondary
index (or indices), if any, will be enclosed in parentheses.
U sing this notation, it is possible to construct an
equation relating the holding time of a call to its component parts in the following manner:
a. In burst segment 2i, in the jth burst, the amount
of time required by the kth user character is
Wk(2i, j). Summing over all k such characters in
the burst, the time required is
::vlj(2i)
L Wk(2i,·j).
k=1
Summing over all bursts in the burst ::Segment
gives
~~ i
:\1j(2i)
W;:(2i, j) .
L L
k=l
i=1
If one defines all burst segments \~here i is even
as user burst segments and assumes that the
number of burst segments per call (S) is always
even, the total contribution of user character
times to total holding time is
Let the following notation be introduced:
=
S =
T =
I =
T
B =
N =
11 =
W =
C =
holding time of call (seconds)
number of burst segments in call
think time (seconds)
idle time (seconds)
interburst time (seconds)
number of bursts per burst segment
number of characters per burst
character width (seconds)
intercharacter time (seconds)
8/2
N; i
i=1
i=1
L L
~1~(2i)
L
Wk(2i, j) .
k=1
Since S is usually large the error introduced by
assuming S even, even when it is not, is small.
Assuming the odd numbered burst segments are
computer burst RP.gments 7 the corresponding
contribution of computer character times is
S/2 N~i-l ~li(2i - 1)
The lower case letters "C'" and "u" will be used as
superscripts to B, N, M, W, and C to represent "computer" and "user" respectively. For example, ~c will
represent the number of computer bursts per computer
burst segment. The three indices of summation to be
used are:
it
given burst seg-
L
i=1
k=l
Wk(2i - 1, j) .
b. A corresponding argument shows the total
tributions of user intercharacter times are
8/2 N;i [IVlj(2i) - 1]
L L
i -to designate the ith burst segment,
j -to designate the jth burst of
ment,
L L
i=l
i=l
L
i=l
and of computer intercharacter times are
8/2 N~i-1 [:\I~(2i - 1)
and
k-to designate the kth character of a given burst.
Ck(2i, j)
k=1
L
i=l
L
i=l
L
k=l
1]
Ck(2i - 1, j)
COll-
Study of Multiaccess Computer Communications
Knowing the distributions for the 12 parameters in
Equation (1), it is theoretically possible to solve directly for the distribution of holding time. The mechanics
of finding the solution are prohibitive, however, except for very restricted cases. One method of solving
(1) is to find the moments of holding time rather than
the complete distribution. This approach will be used
here and, in fact, it will be sufficient for our purposes to
.solve merely for the mean value of holding time. In
order to arrive at the solution, we assun1e that the random variables are stationary and mutually independent. *
Taking the expected value of both sides of (1), we
obtain
c. The total amount of user interburst time is
[N~i
8/2
L
L
i-I
- J]
Bj(2i) ,
i_I
and the total computer interburst time is
8/2
rN~i-1
- 1]
:t - -L
i=1
Bj(2i - 1) .
i=1
d. Total think time is
8/2
LT
495
2i ,
T
i=1
= (8j2)[T
+
+ NuCu(Mu
and total idle time is
+ Nu:\fuWu
+ I + Be(Ne - 1)
Bu(Nu - 1)
- 1)
+ NeMeWe +
NeCe(~Ie
- 1)]
(2)
8/2
L
I 2i-
1 .
i=1
The sum of these components is the holding time for
a call. That is, the time of each burst segment summed
over all burst segments is the holding time. The time
of a burst segment equals the sum of the durations
of all bursts, interburst times, and the think (or idle)
time in that burst segment. The duration of a burst is
equal to the sum of the character times and the intercharacter times contained therein. That is, the holding
time of call f, T.c, is
8/2
Tl =
L
c. user delay (the swn of all inactive periods during
user burst segments)
W k(2i, j)
k=1
i=1
N~ dlVIj(2i) - 1]
+ L
L
i=1
Ci:(2i, j)
I 2i- 1
E
+
N~i-l ~.vli(2i -
+
L
i=1
N~i-l
+
L
;=1
J
d. computer delay (the swn of all inactive periods
during computer burst segments)
k=1
[N~i-I [
b. computer send time (the total amount of time
during which computer characters are being
transmitted)
BY(2i)
N; i IHj(2i)
+
a. user send time (the total amount of time during
which user characters are being transmitted)
[N~i - 1]
[
E IT,; + E
+L
where the symbol for each variable without a subscript
implies its mean value. For further analysis, Equation
(2) may be separated into four parts each having its
own functional significance:
L
1]
Bj(2i - 1)
The sensitivity analysis performed in the next section is an investigation of the properties of these four
parts and includes a discussion of how their interrelation affects holding time. If any of these parts can be
1)
WkC2i - 1, j)
k=l
[l\lj(2i - 1)
L
k=l
1]
Cj,(2i - 1, j)
Jl.
(1)
* Analyses of these assumptions have exposed their limitations.
However, these assumptions have been shown to be reasonable
for the analyses and conclusions of this paper.
496
Spring Joint Computer Conference, 1969
reduced without increasing others, holding time can be
reduced leading to possible cost savings.
Before discussing such analyses, it may be well to
indicate what values have been observed for each of the
12 parameters. This will allow us to concentrate our
attention on those parameters and those measures of
parameters that promise to be the areas of greatest
possible holding time reduction.
the three system averages for the given parameter.
The numbers in the column headed up. are the standard
deviations of the three numbers averaged in p. for each
paraIlleter. The analyses subsequently reported, how=
ever, are based on the actual per system average values
of these parameters.
Table III-Average parameter values
Collected data and sensitivity analyses
A
During the current study, data have been gathered
on a large number of calls to each of several multiaccess
computer systems. For each system, the data have been
partitioned into sets representing each of the 11 random parameters (the twelfth parameter, character
width, is a constant). Probability density functions
have been fitted to the data collected on each parameter from each system.6
Data from three of the systems are discussed in this
paper. These systems are labeled A, B, and C. Systems
A and B have the same computer equipment and basically the same mix of user applications (programmingscientific). System C has computer equipment different
from that of the other two systems and its mix of user
applications is primarily business oriented. All three
systems serve low-speed teletypewriter-like terminals.
System B is rather heavily "loaded" compared to Systems A and C. Table II summarizes these characteristics for Systems A, B, and C.
Table II-Characteristics of systems studied
System A
System B
System C
Computer Type
Brand X Brand X
Transmission Speed
10
10
(Characters/sec)
Primary
Scientific Scientific
Application
lVloderate Heavy
Load
Brand Y
P.
-No. of Burst
Segments
T
-Think Time (sec.)
-Idle Time (sec.)
I
Bu
-User Interburst
Time (sec.)
Be
-Computer Interburst Time (sec.)
Nu
-No. of Bursts/User
Burst Seg.
Ne
-No. of Bursts/
Computer
Burst Seg.
Mu
-No. of Characters/
User Burst
Me
-No. of Characters/
Computer Burst
Wu( = W C)-Character Width
(sec.)
Cu
-User Intercharacter Time
(sec.)
Ce
-Computer Intercharacter Time
(sec.)
uP.A
S
82.
4.3
.65
1.6
16.
11.
3.3
1.1
47.
37.
3.4
.48
.90
25.
3.1
2.8
.12
27.
.089
.00021
.00023
.00030
.000090
15
Business
Moderate
Table III .summarizes the measured values of the
model parameters. To ensure the privacy of the three
systems under discussion, these values are not shown
on a per system basis. Rather, for each parameter, *
an average value p. is given· where p. is the average of
• As the character widths W,. and we are treated in the model
as random variables, they are included in Table III for completeness. In the three systems discussed, however, they were
constant as can be delived from Table II.
One characteristic of the data summarized in Table
III deserves further comment. It is that measures
which should be most sensitive to computer characteristics seem to just that. For example, the users
of both Systems A and B have predominantly pro-.
gramming-scientific applications and the average numbers of characters per user burst segment (NuMu) are
9.2 and 10.7 for Systems A and B, respectively, versus
13.8 for the primarily business oriented users of System
C. Such relationships prevail in spite of widely different
average computer delays. The average amount of time
spent per computer burst segment in interburst delay,
(Ne-1)Be, is 1.4 seconds in System A and 35.8 seconds
in System B,
Study of :rvrultiaccess Computer Communications
497
Table IV-iVIean values of holding time components
Average Holding Time, T
:Minutes
Average User Send Time, (S/2)(N ulVluWu)
l\1inutes
% ofT
Average Computer Send Time, (S/2)(N elVIeWe)
lVIinutes
% of~
Average User Delay, (S/2)(T + Bu[Nu - 1] + NuCu[Mu - 1])
}\;1inutes
% ofT
Average Computer Delay, (S/2)(I
Minutes
+
Be[Ne - 1]
+
System A
System B
System C
l7.
:34.
21.
0.50
0.45
'~01_
'
':~t~
10
20
30
40
AVERAGE COMPUTER INTER - BURST T I M'E DELAY
COMPUTER BURST SEGMENT (SECONDS)
50
PER
Figure 2-Average holding time versus average computer
interburst time delay per computer burst segment
8/2, because when every other factor in Equation (2)
is held constant, it becomes
Holding Time
=
Constant
+ (8/2)
(I-B-T).
(3)
Note that the lines for Systems A and B are close
together. As these two systems have similar configurations of hardware and software, support is given to the
Study of Multiaccess Computer Communications
conjecture that increasing the load on System A would
lead to values of I-B-T and holding time comparable
to those of System B. Conversely, deloading System B
should result in these parameters having values comparable to those of System A.
N ext, as it appears that holding time is a function of
I -B-T and I -B-T is in turn a function of the loading on
the computer and hence on the number of simultaneous
users, an expression relating I-B-T and number of active users can be established.
To establish the relationship between I-B-T and
number of simultaneous users, both quantities were
measured on the systems as a function of time of day.
The solid curve in Figure 3 indicates the average number
of simultaneous users of System A for 15-minute periods
of the day. The average I-B-T's were calculated for
hourly periods on data from System A and a least
squares fit of a variety of curve types was investigated.
For these data the best fit is
I-B-T = (0.18) exp (0.13 u)
(4)
where
u
= number of simultaneous users,
or
u = (7.7) (1.7
+ In I-B-T).
(5)
The dashed curve in Figure 3 is a plot of u versus
time of day by using Equation (4) and the actual measurements of I-B-T versus time of day. This fit seems to
reflect the major characteristics of the data as shown by
499
the solid line in the sense that at least the morning and
afternoon busy periods are reflected along with the
intervening noontime lull.
Using (4), a plot can also be made relating I-B-T and
the number of simultaneous users. Figure 4 sho"\,,"s this
relationship as well as three curves showing the effects of
I-B-T on holding times in Systems A, B, and C. These
latter curves are plotted from Equation (3) after substitution of (4). Figure 4 indicates that above some
threshold (represented by the knees of the curves) the
computer's grade of service deteriorates rapidly as
additional users are accepted. *
Relationships between holding time and user characteristics
Tables VI and VII, below, are used to illustrate
several relationships between holding time and user
characteristics in this section and between holding time
and computer send times in the next section.
* Here an analogy can be drawn between the manner in which a
multiaccess computer reacts to increasing loads and the fashion
in which a telephone R\vitching system reacts to overloads. As
the link occupancy increaRes in a telephone office, the probahility
that a path through the switching networks cannot be found for
an incoming call increases in a manner similar to the computer
delay curve in Figure 4 (Reference 6). Such failures to complete
connections can cause the common control equipment to generate
additional attempts ~hat consume additional real time. In ('omputer systems, the analogous work is the "swapping" of URer programs into and out of central processor core. For a further
discusRion of this computer prohlem see Scherr.l Raynaud,2
Greenberger,7 and Coffman. 8
Table VI -Send time information
(all times in minutes)
Average Holding Time (r)
Average Total Send Time (R) = (S/2)C~"u~Vlu,Vu
% of r
Average User Send Time (S!2)(Nu~VruWu)
+ NcMcWc)
% ofr
% ofR
Average Computer Send Time (S/2)(Ncl\1 cWc)
% of T
%ofR
Table VI shows, for each system, the average holding
time (r), the average total send time** (R), and the
* * Average total send time is the sum of avera/l:e user Rend time
and average computer send time.
System A
System B
System C
17.
6.2
;36%
.50
3%
8%
,':).7
33%
92%
34.
,5.0
15%
21.
8.4
.4;)
1%
9%
4.5
13%
91%
40£Jo
.96
;')%
11%
7.;j
35%
89%
average user and computer send times. These quantities
are measured both in minutres and, for the latter three
categories, as a percentage of holding time.
Table VII is constructed identically for delay quantities rather than for send time quantities.
500
Spring Joint Computer Conference, 1969
Table VII-Delay infonnation
(all times in minutes)
Average Holding Time (T)
Average Total Delay (D)
% ofT
Average Total User Delay
%ofT
%ofD
Average Total Computer Delay
Systern A
SysteTrb B
System C
17.
34.
29.
85%
12.
35%
40%
17.
51%
60%
21.
13.
60%
11.
53%
88%
1.5
7%
12%
II.
64%
10.
58%
92%
.95
6%
8%
% ofT
%ofD
25
150
Ui
o
z
a: 0U
W
~S120
ILl-
2z
OW
u2
oC)
Zw
z
(5
oJ
~ 40
IIJ
~ 20~
I
O~I~I~________~I______~I__________~I____--JI
10
40
100
400
1000
COMPUTER CHANNEL SPEED IN CHARACTERS PER SECOND
(NOTE; LOGARITHMIC SCALE)
Figure 6-Average holding time versus computer transmission
rate for hypothetical short holding time system
and at 10 characters per second, this results in a 106
second holding time of which 94 percent is computer
send time. At 360 characters/second, T = 8.8 seconds
but computer send time is still 32 percent of T. At 4000
characters/second, T = 6.25 seconds of which four percent is computer send time. Figure 6 shows a graph of
holding time versus computer channel speed for the
short holding time example we have assumed.
SUl\1MARY AND CONCLUSIONS
The results of a study of the communications considerations of serving multiaccess computer systems
have been presented. A modEl of user-computer interaction, as observed at the communications interface,
has been developed. Summary data from three "long
holding time" computer systems have been given for
the parameters of this model.
Examination of these data has revealed that
a. Computer introduced delays can be a large component of holding time and, above some threshold, are acutely sensitive to the number of
simultaneous users. The largest component of
computer delay occurs during those periods when
the computer is outputting to remote users. The
conclusions to be drawn from these findings stem
from the consideration of holding time as being
composed of periods of computer outputting
activity, and periods of no computer outputting.
Study of Multiaccess Comnuter
r,nv.U.L.u.......u ..;nn ...;"'.... n
...
~
Of the inactive periods, some time is due to userdependent delays and some to computer-dependent delays, some, such as execution time,
may not be reducible and others, such as delays due to overhead, can be reduced. It should
be noted that changes in the computer system
such as changes to the scheduling algorithm,7.8.9
or changes to the communications control unit lO
can strongly influence computer delays. Thus,
it is within the compu('ing system that some reductions in holding time may be made resulting
in communications economies. As not all computer delays can be eliminated in a heavily
loaded system, the technical and economic
feasibility of employing data multiplexers at the
computer to decrease the number of access lines
should be explored.
b. The average number of characters sent by the
computer to the user is an order of magnitude
greater than the number of characters sen,t by
the user to the computer. If other parameters
did not change drastically, the availability of
higher transmission rates for computer outputting would effect significant reductions in average holding time. A computer transmission
rate of 360 characters per second would reduce
total computer send time below one half minute
per call. To achieve this rate requires either
high speed or asymmetric data sets and correspondingly higher speed output terminals.
c. Delays introduced by the user are a significant
contributor to average holding time. The average
user delays in the three systems reported are remarkably close in absolute values. As user delays are appreciable, the multiplexing of inputs
from user terminals which are geographically
clustered appears attractive and is being studied.
The data analyzed in this report are from systems
having primarily scientific and business problemsolving applications. The users of such systems demonstrate a wide range of sophistication in their use of these
systems. As users educate themselves in the efficient
use of multiaccess computers and their terminals, the
data traffic characteristics of these systems will change.
Studies of multiaccess computer communications
systems are continuing. Data are being collected from
systems with markedly different terminal types, average
holding times, and user applications. Analyses of these
data will allow the characterization of such systems in
a manner analogous to that reported above for "long
holding time" systems.
~
't"V'l't"V'll1 .....
\..oQ " .. v~~i:I
f;O~
- --
Implications of results
. The implications of the results of this study extend
mto several aspects of computer communications. The
study has produced quantitative indications of the
degree to which computer operations can influence such
communications parameters as holding time. The developers of computer systems, in turn, have noted that
the provision of computer hardware and software to
accommodate data communications i.';;; a rna ior nrohlAm
area. 1l ,12 In order to jointly optimize the cd~p~t~t~~=
communication solution to the problem, it is apparent
that closer coordination between the computer and
communications systems designers would be extremely
fruitful in terms of economic and technological improvements to overall systems design.
One of the impediments to finding rapid and robust
solutions to the problems of multiaccess computer
communications has been the unavailability of data
descriptive of the user-computer interaction process.
The acquistion of the data reported here is a contribution toward the removal of that obstacle.
These data are currently being used in systems engineering studies at Bell Telephone Laboratories to
further define the systems requirements for new systems and services to satisfy the needs of the multiaccess
computer community.
The analyses made of these data support for the
first time in more than qualitative terms some proposals
proffered in the past as solutions to the data communications problems associated with multiaccess computer
systems. The delays which are introduced by both user
and computer suggest the possibilities for effective
employment: of multiplexing techniques. For example,
it has been shown for the systems studied that the average total send time (the sum of user send time and
computer send time) is as little as five to nine minutes.
This corresponds to 15 to 40 percent of average holding
time. For the other 60 to 85 percent of average holding
time the communications channel is idle. One method of
obtaining higher utilization of these facilities is by time
division multiplexing. * The following assumes a multiplexing technique ih which the user channel is independent of the computer channel. Only one to five
percent of average holding time (or three to eight percent of the average user burst segment) is user send
time. Thus, for 95 to 99 percent of an average call, the
user-to-computer channel is idle and could be made
* Multiplex:ng ;s not always economical, of course, despite the
large idle times. Other important considerationss involve the
geographical placement of terminals and computers and several
statistical traffic characteristics other than average occupancy.
504
Spring Joint Computer Conference, 1969
available to additional users. Average computer send
times for the three systems were from 13 to 35 percent
of average holding time (21 to 86 percent of the average
computer burst segment) indicating that higher usage
of the computer-to-user channel may be realized by the
use of appropriate mUltiplexing techniques.
The asymmetric nature of the data flow in multiaccess computer systems suggests that different transmission treatments may be appropirate for computerto-user versus user-to-computer transmissions. The
large volumes of _computer-to-user data are an order of
magnitude greater than volumes in the opposite direction. The provision of computer transmission rates of
100 to 200 characters per second could reduce average
holding times up to 30 percent. As the user is capable
of generating characters for transmission at a much
slower rate, the application of asymmetric channels or
data sets receives quantitative support and is now being
studied. Provision for higher computer transmission
rates would require, of course, user terminals with accordingly higher input rates.
The final conjecture receiving quantitative support
from the above analyses is that users themselves contribute substantially to the communications costs of
their real-time computer access calls by introducing
delays. Some of these delays are likely to decrease as
users gain proficiency. Others are due to the inveterate
characteristics of human users. As they pertain to the
use of communications and to the use of computers1 •3
these characteristics are being intensively studied to
enable the design of versatile and responsive computer/
communications systems.
ACKNOWLEDGMENTS
Many people have contributed their efforts to various
parts of this study. Data acquisition was accomplished
with the considerable help of the .American Telephone
and Telegraph Company and the Bell System Operating
Companies. Contributions to the model and the analyses
and many helpful criticisms were made by ::.'viessrs.
E. Fuchs, R. J. Price and R. J. Roddy, all of Bell
Telephone Laboratories.
Our special thanks are extended to the companies
whose computer systems are being studied. Without
their full permission and very helpful cooperation these
analyses would not be feasible.
REFERENCES
1 A L SCHERR
A.n analysis of fin/'e-shared computer systems
Massachusetts Institute of Technology Projed MAC
Thesis MAC-TR-18 June 1965
2 T G RAY~AUD
Operational analysis oj a computation center
Operation" Researeh Center MIT July 1967
;~
H SACKMAN
Experinwnfal investigation of user performance in lime
shared computer sysff3ms retrospect. prospect, a.nd the
public interest
System Development Corporat:on May 1967
4 G E BRYA~
JOSS: 20,000 hours at the console, a sta'istical sllllunary
Rand COl'pol'at;on August 196i
5 P E JACKSO~
A. fourier series tes' of goodness of fi.t
To be published
6 A~OX.
Switchiug systeuts
AT & TCo 1961
7 M GREE~BERG.ER
The priurity problem
MIT ~ovember 1965
X E G COFFMAX JR
A.nalysis of two time shariil.g
limiting
a1(/o;'i:thlils de.'lig/i.ed fur
~wapping
J A C M July 1968
$1 E G COFFMAX JR
L KLEIXROCK
Computer scheduling methods and their countermeasures
Proc S J C C 1968
10 L J COHE~
Theory of the operating system
The Institute for Automation Research Inc 1968
11 W F BAUER R H HILL
Ecunurn'ics oj time shared compui'ing sysiems-Pari I I
Datamation Vol 13
12 W E SIMO~SO~
~o
1241-49 Derember 196i
Data communications: The boiling pot
Datamation Vol 13
13 W W CHU
~o
4 22-25 April 1967
A. study oj the technique oj asynchronous finze division
multiplexing jor time-sharing computer communications
Proc of the 2nd Hawaii International Conference on
Systems Sciences January 1969
A communications environment emulator
by JACK M. PEARLl\1AN and RICHARD SNYDER
Honeywell, Inc.
Waltham, Massachusetts
and
RICHARD CAPLAN
Consultant
New York, New York
The problem
Communications based systems and software, especially complex systems and software, present an exceptionally difficult checkout and debug problem to the
implementor. Conventional techniques require him to
check his often times labyrinthine maze of response
paths in a plodding, single step by single step, long
drawn out and expensive manner. He checks the noncommunications or non-real time portions of his program easily enough. The methods of testing standard
peripheral functions are well enough known and adequate tools exist for the job. The techniques for checking basic data processing logic are available with every
batch oriented system. Communication based system
checkout is complicated by the real time nature of the
systems. The give and take of on-line terminals, the
multiplicity of choice, the need to process data in
various stages of disarray, the necessity of leaving
some partially complete processing sequence and returning to it at a later time, these are the problem factors. These are the things which make conventional
checkout procedures a millstone around the neck of a
system builder.
He is required to generate huge quantities of test
data, each item of which is keyed to a specific path,
expecting a specific response. He simulates as well as he
can the action of his operational system with a console
or perhaps with a card reader or maybe a single actual
terminal. The usual scenario then calls for him to use
several actual terminals and operators, with the attendant confusion, logistic difficulties and expense. The
final step is a full blown system test sequence using all
the equipment and all the operators and he hopes that
all the parts are exercised and that all the problems are
solved.
This technique works, to a point. It does produce a
workable system. It does, eventually, succeed in resolving a large percentage of possible problems. The cost
of doing so, however, is extremely high. Devising a
specific datum for a specific path test is time consuming,
especially since the number of paths may be counted in
the hundreds or thousands. Using live terminals and .
live operators presents a major organizational problem
and requires large cash outlays. Such a system too,
. violates a prime rule of scientific investigation-reproducibility of an experiment. The programmer is
rarely positive that a fix works since he can never exactly recreate the conditions causing failure.
The solution
Taking these objections, and others, together, we
decided to find a better way to check and debug communications based systems and system software. The
result of our efforts, is "The Honeywell Communications Environment Emulator" (HCEE).
HCEE is a multi-purpose communications network
simulator whose prime purpose is to aid in the checkout
and debugging of communication software, real time or
otherwise. A secondary purpose is to permit experimentation with software and remote terminal configurations where the terminal itself is non-existent. A
tertiary reason for being is to evaluate communications software by determining its operational limits and
its response to unusual stress.
------------------------------------- 505------------------------------------
506
Spring Joint Computer Conference, 1969
The system may be quantitatively defined in terms
of its design goals. It will simulate up to 6::3 lines, with
several distinctly different classes of terminal represented, up to eight terminals per line and generate at
least 70,000 lOO-character messages per hour on an H1200 computer. It will require a minimum 65K C.P.
with about 30K taken up by instructions. It will handle
as many message types as a user cares to define and
check for as many response types as he wishes. The system will generate as many message variations as a user
provides defining entries for, in some cases using a random selection process, in others using a round-robin
technique. HCEE will eventually be able to introduce
perturbations into a data stream to simulate line control errors and other line associated faults.
The Emulator will reside in its own processor, with
the system under test (target) in second C. P. The two
computers communicate via standard communications
hardware. The target system thinks that it sees a real
communication network, with real terminals and operators, in the outside world. Actually HCEE generates
all queries and responds to all answers by simulating or
emulating the characteristics of the actual terminals
and their operators. This approach to checkout is itself
complex and by no means inexpensive. But it is far less
complex and far less expensive than conventional checkout means and carries with it many distinct advantages.
Use of a computer permits reproducibility and creation
of exhaustive system evaluation reports. By recording
every message transmitted (control and data) and every
message received, along with the system time, it becomes possible to "play back" an entire sequence as a
way of validating changes to the target system. These
same records become the basis for a complete series of
reports describing the operation of the system in detail
and the success with which various classes of messages
were handled, including deliberately created error messages. The computer, too, permits automatic message
generation and response analysis based on skeletons
defined by the user.
The product
The form which the HCEE design took was partially
determined by a number of criteria for use, not the
quantitative ones described earlier, but qualitative ones.
One major criterion was that the system be modular.
By modularity we imply that the component elements
be so loosely related to one another (or decoupled) that
any element could be readily replaced by a similar
component of greater or less complexity. That is, except for some minimum capability, new routines could
be added and/or existing ones deleted from the system.
This criterion is essential to a system such as HCEE
since its utility will be partially dependent upon our
ability to adapt it to handle changed operating conditions, and provide capabilities not originally considered. Modularity is achieved by use of elaborate table
structures and list processing techniques "'(.vhich insulate
processing routines from one another. All contact between routines is through tables, lists or well defined
interfaces to small central control programs.
A second important criterion was that the system be
able to generate large message volumes within user
defined response constraints. This implies that the time
limitations associated with program or data storage on
external media probably would become intolerable,
Consequently it was decided that the entire program
and its data base be core resident.
A further goal was to make the program usable internally by Honeywell as a systems checkout tool and
eventually externally by our customers, with a third
potential user being independent service bureaus. These
were some of the factors which led us toward residence
in a separate C.P., with independent communications
capability. We could now use this tool to debug a target
system hundreds of miles away and work with target
systems residing in non-Honeywell computers.
The last major criterion considered required that the
generated system be independent of any existing operating system. This decision 'Yas made to insure usability
in a smaller computer than would otherwise be necessary and to insure better control over HCEE operation
by not being tied to operating system conventions. We
will use operating system MOD 2 to generate the system
however, in order to take advantage of the macro assembly and linkage editing and loading facilities of MOD 2.
Phase structure
Functionally, HCEE may be considered as having
four discrete phases; Test Generation, Test Initialization, Test Execution and Test Result Analysis.
During Test Generation, the data and environment
Specifications which define the test case are integrated
into the HCEE execution phase structure. This operation is accomplished through application of the Macro
Assembly facility. Macros were selected as the prime
configuration medium for several reasons: the facility
exists; it is fairly powerful, it is well understood; macros
are relatively easy to use; they require minimal manpower to implement; they are, of all alternatives, the
cheapest to use. Macros were an expedient choice but
more importantly, they do not impose any major limitation upon either the design or the final use of the system.
One further consideration is the relative ease of change
which macros provide. Certainly as our experience with
the Emulator grows, we will find areas for improvement.
A Communications Environment Emuiator
The macro approach simplifies at least one such area.
The chief alternative to the macro approaeh, one which
is attractive for future use, is an English like language.
Unfortunately however, this choice possesses as disadvantages (for the initial system) the negatives of almost every element cited for the macro approach.
Macros defining the particular test (via parameter
lists) are assembled into table structures which serve as
the data base during test execution and provide system
specialization control information for use during test
initialization. The macro language is divided into four
logical divisions which functionally correspond to those
of COBOL. Thus, the Identification Division consists
of user specified information for unique identification of
a test run or series of runs. The Environment Division
defines the virtual terminal population being emulated
as well as user specified message volume and scheduling
constraints. The Data Division provides the templates
necessary for query generation and response analysis.
Finally, the Procedure Division defines the information
necessary to proceed through a transaction. That is, the
decision information necessary to decide "what to do
next". For example, what query to send next based upon an analysis of the last response received.
Test initialization takes the linked HCEE programs
and tables (on tape in self loading format), performs
b~ic communication startup and housekeeping functions, and dynamically generates certain table entries
from the data supplied at test generation time. In addition, the first message to be sent across every active
line is generated and scheduled.
During test execution, HCEE generates, transmits,
and logs queries and receives, analyzes, error codes, and
logs target system responses. Although a limited amount
of controlled console operator intervention during test
execution is acceptable, the execution phase is capable
of running with no outside intervention and with no
calIon external data storage except for logging purposes.
Following termination of a predetermined test interval supplied by the user, the test result analysis phase is
initiated. During this phase the Log Tape is sorted into a variety of sequences (as called for by the user specified reports) and the report generation sub-programs
are executed using the log as input, to produce target
system performance reports for diagnostic and efficiency
measurement purposes.
All four phases of HCEE may be executed contiguously on a load and go basis, or they may be broken
into three parts: Generation, Initialization and Execution, and Result Analysis.
Basic facilities
HCEE incorporates the following features:
:t.
507
Control
1. Spceifieatioll by the user of desired test interval length, and line transaetioll volume
as a time dependent f u n c t i o n . 2. Specification by the user of both the real and
virtual (terminal) hardware environment
in terms of the number, line distribution,
and type of terminals to be emulated.
3. Specification by the user of context dependent, scheduled time intervals to be applied
in initiating queries that represent the continuation of transactions.
4. Specification by the user of the syntactic and
semantic rules which establish the relationship between target system responses received and the next call generated from the
same terminal. These rules are supplied as
logical table structures which can be
probabilistic ally weighted to ensure the
generation of a prescribed transaction
mix, and the production of a statistically
vittble sample of certain expected operator
behavior patterns, as (for example) "think
time" to absorb received information.
5. Specification by the user of errors to be introduced into the transmitted data stream
either in accord with statistical measures of
type and frequency or continual generation
of specific errors.
.
b. Query Generation
1. Generation of fixed or variable length (format) queries with dynamic selection of key
user specified parameter fields.
2. Dynamic selection of the appropriate query
to generate within an interactive context
defined by the user in a transaction syntax
definition.
c. Response Analysis
Identification of fixed or variable length target
system response types fixed keyvwrd or parameter matching search methods.
d. Error Detection
1. Dynamic marking during test execution of
all response errors. These trrors include
invalid (unrecognized) target system responses as well as valid hardware and
system error conditions, such as line a..':lSOciated errors.
2. Dynamic marking during test execution of
all calls which are generated after their
scheduled transmission time, distinguishing
508
Spring Joint Computer Conference, 1969
sole and allowing the console operator to input
action requests.
7. Buffer Linker-The element which has the responsibility for linking buffers of a message together and activating the Diagrammer in the
case of a fully linked Response, or the Communications Subsystem in the case of a fully linked
Query.
8. ~:Iessage Logging Routine-The element which
logs to magnetic tape all transmissions between
the system under test and HCEE
a. deterioration in HCEE performance from
a reduction in Target System efficiency.
e. Reporting (and result analysis)
Post mortem production of a comprehensive set
of HCEE test performance analysis reports including such critical measures as response time
gra.phically plotted as a function of transaction
volume, polling delay (interval measuring operator request to actual transmission) as a function
of volume. HCEE service time by message type,
etc.
Emulator program components
HCEE incorporates various fixed and generated
components (elements). Each element, along with a
brief description of its function, is presented below.
1. Executive-The central element. It is responsible for interrupt management and time slice allocation.
2. Terminal Operations Subsystem-The generative and analytic component of HCEE. It is
composed of a fixed element, the Diagrammer;
and generated elements, the Query-Response
Lists, Vocabulary Lists, and Transition Diagrams. The Diagrammer traverses the Transition
Diagrams using the Query-Response Lists in
conjunction with the Vocabulary Lists for Query
generation and the Query-Response Lists alone
for Response analysis. The balance of the paper
will concentrate on this subsystem.
3. Transaction Scheduler-The element which provides the time increment at (relative to current
time t) at which to initiate a transaction for a
particular terminal. The decision of what at to
produce is based on user supplied volume constraints and a random number generator. The
Transaction Scheduler is activated by the Communications Subsystem.
4. Communications Subsystem-This element is
responsible for transmission and reception of all
traffic to and from the system under test. The
Communications Subsystem is. triggered by the
Executive Routine following an interrupt from
the multiline controller.
5. Path Selector-The module which has the final
responsibility for selecting which query to send.
It chooses the query on a user specified percentage basis from a population of queries selected
as a result of analysis by the Diagrammer.
6. Console Routine-The element which is responsible for outputting system messages to the con-
Figure 1 illustrates the relationships between the elements of HCEE.
The key
Before continuing with the narrative, it is advantageous to diverge slightly and define some essential
terms.
1. Query-Any message generated and transmitted
by HCEE regardless of initiating impetus. In
other words, even if the message in question is
an answer to a request from the target system,
it is considered a query.
2. Response-Any message received' by HCEE
regardless of whether solicited by HCEE or not.
3. Transaction-A sequence of messages (made up
of queries and responses) which perform an iden-
•
I
VC£CUTIY£
COMIIUfICATIONS
-
IIT£RRUPT
~ MANAGOIENT
US'tSTEM
~TOR
r----
LOG ROUTINE
I-
1
,........
tobe
~
....,
11_e!
IIIIIIecI
BUFFER
--t
LINKER
....,,
.....,
_tel
I ........
CONSOlE
ROUTINE
to be
I
j
T_.OpIr.SuIIIya.
I
I
II~
!
~--IQ-RII"I
0-,
l VaoIII. !
!
Figure I-Basic elements of HCEE
!
A Communications Environment Emulator
tifiable application function. For example, a
transaction involving a sale might consist of:
a.
b.
c.
d.
How many widgets in stock (query)
Ten widgets in stock (response)
Sell 10 widgets to ABC Co. (query)
Confirm 10 widgets to ABC Co. (response)
4. Transition-State-Diagram-A nodular structure
providing finite reference points for states of the
system. A completed action on an object may be
considered as a state of being of that object.
There are indicators and conditions associated
with that state and there is an expectation of
one or more of a finite number of future operations which might occur on the object as a
result of what has already taken place. For example, consider a ball at rest on the ground.
It's state of being may be defined as "at rest."
This state carries with it information, some of
which may be indicators, some descriptors, some
measures of expectancy of future events. An
example of an indicator may be recognition of
the fact that the ball is stationary; a descriptor
might be that it has zero kinetic energy; expectance, that it will be thrown up in the air or
that it will be thrown against a wall. Any other
occurrence is an error or failure of the system
involved. Further, consider that at the moment
anything happens to the ball, it is started on the
way to a new state of being regardless whether
what happens is expected or not. If we now d~
fine the state of being as a "node," the process of
determining which of several possible futures has
occurred as execut~on of an action routine, and
completion of that p'ocess as a.rrival at a new
state of being (node), then we have explained the
concept behind 1he opening description as a
"Nodular Structure.'" All that remains is to
emphasize that ali possible relationships are
predetermined by the user. Should he make a
mistake in defining a relationship, or if he leaves
out a relationship, the system will be immediately aware of the mistake. In that sense the
process is a heuristic one and allows checkout of
the logical dependencies between information.
509
be measured in minutes or hours), without creating an·
extremely large, highly specific test case library; with
surety that he will exercise every path through the target system· that he can conceive of and describe, including error paths. Moreover, the user is assured that
events within the network will occur in a timely manner,
in accord with volume and operator (or syetem) reaction time constraints defined by him.
The test transaction structure of HCEE is in the
form of directed strings of items (Queries and Responses) which permit an exceptionally complex set of
relationships to be described. The simplest variation is a
one dimensional sequence such as:
Complex networks which introduce choice may be constructed similarly:
•••• ETC.
For response analysis purpo~s, it is presumed that the
-paths emanating from a Query Node represent all possible responses to that Query Node (including a default
or error state) and conversely that the paths from a Response Node represent all possible queries generatable
as a result of the response. The QueryjResponse mechanism may be further improved by assigning selection
probabilities to various queries so that queries are gener- •
ated roughly with the frequency that they are expected
in the actual system. This ability has the added advantage of facilitating experimentation to determine the
effect on a system of different message type loading
within a specific overall volume.
Test data base
Terminal operations subsystem
The Terminal Operations Subsystem is the heart of
HCEE. It contains the prime processing components
and is responsible for the generation of queries, checking
of responses and maintenance of transaction flow within
HCEE. It provides a user with the ability to drive his
simulated system over a sustained interval (which may
The Test Data Base consists of a collection of transition diagrams (Transaction Logic Network) similar to
those just described, which reference a file of user
created skeletal message descriptions known as "QueryResponse List". The Query entries within the Q-R
Lists may in turn reference a set of key word strings or
"Query Vocabulary List" which supplies variable word
510
Spring Joint Computer Conference, 1969
..
I
:
-'
QII
~
R,
R2
Rill
Figure 2-Relationship of transition diagrams to query
generation tables
values for inclusion in generated Queries. The relationships are illustrated in Figure 2.
o
: : : node = state defined by the transmission or
reception of a specific message type
(nodes are either Q or R type where
Q = query and R = response).
The transition diagrams themselves are represented
by a set of variable length records, one for each X ode
in the network. They are created during the test generation process from user supplied information. The
Query K ode referred to in Figure 3 is the place at which
a particular Query is generated and a subsequent response is analyzed. Upon positive identification of the
response, control passes to the proper Response Node
for preparation of the next Query. Non-identification of
a response, indicating either a failure somewhere within
the system or a mistake in describing the system by the
user, causes control to pass to the error routine associated with the Query Node. HCEE supplies a single
common error routine. The user is free to replace it or to
add others as he wills. Query path selection using the
associated probability measure, and calculation and
assignment of the required intermessage interval, are
done by the Path Selector subroutine of the
Diagrammer.
R:>DE TYPE ::
QUERy
~-RESPONSE
: : : path = implicit execution of an Action
Routine (query generator or response analyzer) necessary to
move from one node (state) to the
next as directed by the path.
L.IST POINTER
NUMBER OF PA'mS
~TING
FROM THIS R:>DE
ERROR ROUTINE
TARGET R:>DE (R 1)
TARGET R:>DE (R ~
: : : first node for transactionn
R:>DE TYPE • RESPONSE
: : : transaction terrnination node which
corresponds to a return of the terminal involved to an idle state.
: : : Format Template for query n which is
used by the query generator to produce
the actual message.
QUERY-RESPONSE L.IST POINTER
NUMBER OF PATHS EMANATING FROM THIS R:>DE
TARGET R:>DE (Q 1)
INTERMESSAGE INTERVAL (Time of delay before
transmission of this QUERY)
FREQUENCY OF USE (A probabilistic weighting factor
to assure selection among Queries
: : : Identification template for response m
which is used by the response analyzer.
based on real system expectation)
TARGET R:>DE
W 1. . .'N k Variable length word strings (circular liILked
lists) l-k which serve as lexical source material for query building, i.e., varying data
elements such as part numbers, which are
inserted into defined fields in a query template to create a complete query ready for
transmission.
(Q~
Figure :3-Record structure for transmission diagrams
A CommurJcations Environment Emulator
Query-response list
The Query-Response List is acted upon by programs
called Action Routines, which are executed by the system while it is traversing the Transition Diagrams.
There are two basic types of Action Routines; the Response Analyzer and the Query Generator. The Response Analyzer determines which Response Node to
activate. That is, it decides which Response type of a
nlLTUber of possible Responses has actually arrived. The
Query Generator concatenates the fields specified in the
Query-Response List with values extracted from the
Vocabulary List so as to create complete messages from
the skeletal formats of the Q-R List.
POINTER
TO FIRST
LIST
ELEMENT
~RD
POINTER TO
CURRENTLY
ACCESSED
ELEMENT
LENGTH
N
Figure 4-A vocabulary list entry
TRANSITION
Q-R LISTS
DIAGRAM
QUERY
Q[,ISTl
3
ERRORRTH
VOCABULARY
LIST
36
t - - - - - -... OLIST
.. ~C!!.O_N.!_
2
--iJ.---
C
~r-
R3
c
.:~TL
RBSIIORSI
Creation of a wide variety of queries from a single
Query skeleton is made possible by the Query-Vocabulary Lists. Included in a Query skeleton record are a
series of field descriptors which define fields as constant
or variable. Variable field identifiers contain pointers to
vocabulary list records containing a series of possible
values for the particular field. Normally the values will
be selected sequentially on a round-robin basis. The
technique allows the inclusion of deliberate data errors
to check data handling characteristics of the Target
System. Figure 4 illustrates a vocabulary list field.
~~~l __ ~
_IILE
1_
--__
.;v.! __
..
FIRST PTII
CUM P'1'R
5
ITEM!
5
ITEMS
6
ITEM1_
5
ITEM3
V
X
VOCABl
... 21
RLIST1
r--
ACTIOR2
E~~i
-2_
IDLE
_
1~
1II US
RLIST2
ACTION2
_
RESPONSE
~IST3 ~
~_
-
----
~E---
Sample network
The Diagrammer is the central control routine which
coordinates the activity of the Response analyzer and
Query Generation Action Routines. At any point in
ti:l~e, for a given terminal, a set of transaction continuation possibilities exist. The set consists of those paths
emanating from the current node address of that terminal. Earlier it was stated that recognition of a particular
Response led to generation of a specific Query. Actually
there may exist a number of valid queries. When selection of a single Query from a population is needed,
control passes to the Diagrammer, which retrieves the
~RD
~
R2
Diagrammer
..
VOCABULARY
LIST POINTER
IN QUERY RE
,~~~~---~
RLIST3
ACTION2
6
REPEAT
1
7
MESSAGE
Figure 5-A sample transaction network
current node address and in turn activates the Path
Selector, which may apply a uniformly distributed
random number generator and/or path frequency information present in the node record, to select a single
query generation path. Responses are processed and
identified by a series of comparisons rather than selections.
Path selector
The prime responsibilities of the Path Selector are
selection of the next Query to generate within a given
transaction context, and calculation of the time at which
the message should be transmitted. We must distin-
512
Spring Joint Computer Conference, 1969
a.FER
Iana I
EXECUTIYE
ROUTINE
r--
_ _ _ _ _ _ _ _ _ _ .L __ _
I
-
--,
ERROR ROUTINES
I
guish two eonditions, each with its mvn scheduling requirements; initiation of a transartion and generation
of a query within nn on-going transaction.
Every line or line group (defined as a number of lines
with completely homogenous initial transaction requirements) has one or more transaction initiation
nodes (Node 0 for Query initiate transactions-Null
Node otherwise). Each possible transaction path for a
given line or line group emanates from one such unique
node. Each potential transaction carries a usage frequency (provided by the user) which the path selector
uses as a selection constraint. Scheduling for Transaction Start activity is not done by the Path Scheduler,
but rather by the Transaction Scheduler. This latter
routine selects inter-transaction intervals based upon
transaction volume constraints imposed by the user.
Query selection for on-going transactions has already
been described. Scheduling for such queries is done by
the Path Selector. This is accomplished by adding a user
defined inter-message interval to the arrival time (from
system time zero) of the activating response, and posting the result as the scheduled transmission time.
CONCLUSION
L __ _
Figure 6-Relationship of terminal operations subsystem to
balance of Honeywell communications environment emulator
We have just described a technique for providing a real
time checkout facility to a programmer or software designer writing a communication based system. The design is flexible, modular and expansible. The program
is expected to be ready by the fourth quarter of 1969.
Development of New York City's
geographic data network
by ROBERT AMSTERDAlVl
Ojfice of Adminiatration, Ojfice of the Mayor
New York City, New York
INTRODUCTION
N ew York City has begun the coordinated development
of a network of information systems which will assist
all agencies of the City government in exchanging
information needed for routine operations, planning
and analysis. The approach used. here places operational requirements in the paramount position. That
is, the methods by which agencies can receive, use
and transmit data vary widely and depend largely on
the services each agency is required to provide. Thus,
the concept frequently proposed, of a massive centralized urban data bank was found to be in~equate.
Instead, New York is developing a series of systems
using various methods for data handling as determined
by the requirements on each system. The heart of
this network is a system which stores and transmits
current information on the data elements which are
used by agencies throughout the City government.
These are elements relating to the basic geographic
environment of the city; the land, streets, buildings
and location of public facilities.
This paper discusses the factors which determined
the overall design, the principal components of the
network and the areas in which current work is progressing.
Considerations in designing an urban information system
Rationale
The reasons for developing a coordinated urban
information structure are well documented. 1 To review
them briefly:
1. Many agencies of local government need the
same information but their resources for gathering and maintaining these data vary widely.
For example, both assessors and redevelopment
planners must evaluate the condition of existing
structures in relation to the neighborhood in
which the building is located. The assessor's
department, because it has a continuing responsibility to know the use of every piece of taxable
land in the city, has developed detailed records
to maintain data on every parcel and systematic
procedures to update these records. The development planner is concerned with only a
small portion of the city, his concern is immediate and he generally does not have the
time or facilities to develop the information
base he needs.
2. Each agency generally needs its data organized
in a different fashion. Again, using the example
of the assessor and the redeveloper, the former
generapy must handle his files sequentially to
be sure that no parcel has been overlooked. The
developer needs to examine parcels in a block
or neighborhood orientation in order to determine what portion of the community is
best suited for redevelopment.
3. Many agencies in local government organize
their data according to district lines determined
by the particular service they are providing.
For example, -school districts are drawn to meet
the distribution of school-age population and
the locations and capacities of schools. Sanitation districts are drawn with consideration
for the location of incinerators and the garaging
of collection trucks. It should be noted that in
many localities the different services are performed by administrative units with overlapping
jurisdictions. Thus a suburbanite frequently
finds his water is provided by one administrative
unit, schools are administered by a different
unit, police by a third unit and fire protection
513-------------------------------
514
4.
5.
6.
7.
Spring Joint Computer Conference, 1969
by a fourth. For this reason, data which is
collected and sununarized by one agency is,
in aggregate form, useless to another agency.
Agencies frequently collect and stOie duplicate
information. Because of the reasons cited above,
or because one agency is not aware of the data
which another one possesses, there is· much
duplication of data gathering. Very often this
involves extra burdens on the public. For
example, in New York City, if an individua1
acquires a piece of property, he may be required
to register this fact in up to four different
offices.
In many cases one agency can easily obtain
information which several other agencies need
but have great difficulty in acquiring. For
example, many agencies in N ew York need
information on structural details of buildings
which can be obtained most easily from the
architect when he files his plans.
Files which have significant relationships in
common frequently cannot be compared because
of differences in the schedules of updating or
the method of data acquisition. In many cases
an agency must be cautious in combining data
from two files because they cannot determine
whether the same standards were used for both.
There are many requirements to analyze or
sununarize data contained in files which are
maintained manually. The size of the files
makes it a practical impossibility to summarize
their contents.
Obstacles to automation
In the past there have been a number of obstacles
which have made it unfeasible to consider automation
of many local government files. Large random-access
storage devices, reactive terminals and graphic display
equipment have started to change this balance but
for most cities these obstacles are still appreciable:
1. City records have a long life of usefulness. A
distinctive characteristic of most local government records is that the data is of interest for
many years after it is acquired. In industry,
by comparison, if a record is more than a year
old it would probably be of value to no one.
City records of building plans, title transfers
and birth certificates, as examples, are maintained permanently. Any plan for record automation must adequately justify the cost of
permanently storing records which may only
be searched sporadically if at all.
2. City files are large and only grow larger.
3. The records tend to be long and complicated.
They will generally contain many types of
data, frequently in a cOlilplex pattenl that is
difficult to systematize. When automation is
considered, decisions are generally made to
leave out some data elements that are difficult
to classify or not immediately useful. In many
cases the· elements omitted are later found to
be necessary and are acquired for additional
cost that could have been avoided.
4. Some data must be protected by the agency
acquiring it. Government agencies collect much
information which is generally agreed to require
confidential handling. As one example, the
number of employees in a firm could be valuable
information to a competitor. :;\tIore familiar is
the information on individuals collected by
the U. S. Census Bureau, departments of
social services and police. Where sensitive
information is involved, the originating department will always aggregate the data to
the block or district level before releasing it
to other agencies.
5. City files are hard to match because of problems
of identification. In matching addresses, for
example, a structure may be known by more
than one house number or the street name may
be commonly spelled in a number of different
manners. In addition some agencies do not
identify a property by house number. The
assessor, for example prefers to use lot numbers.
The developer, who may be acquiring or subdividing lots, may use a series of parcel numbers.
Conclusions from earlier work
I t is important for anyone who works in this field
to keep abreast of other efforts. Since much of the
activity in developing urban data bases has been
federally funded, hard-learned lessons have been very
well documented. 2 The following advice is particularly
worth reiterating.
1. A grid system (x, y coordinates) is essential in
any urban information system in order to provide
a fixed point of reference. It is also useful in
calculating distance, direction, area and proximity.
2. Data should be collected at the parcel or building
level wherever feasible and aggregated when
necessary to meet specific uses.
3. Data should be captured at its source and
Development of New York City's Geographic Data Nehvork
transmitted to a data processing center by the
source department.
4. Data files should be maintained by the source
department, if possible as a by-product of
their routine operations.
5. No organization can be expected to contribute
to an activity on a continuing basis unless the
organization receives some benefit in return.
6. "Systems for urban information handling should
not be designed to serve planning alone, but
should be able to provide data to other agencies
of local government."3
Data processing environment in New York City
EDP operations of the City of New York presently
involve eighty-nine computer installations including
those in the courts, schools and colleges. Twenty-four
computers are used by agencies directly responsible
to the Mayor. These are used primarily for batch
sequential processing of tape files running to 21 reels.
The computers are located at sites throughout th~
City Hall area. Many agencies with large data processing requirements have multiple installations.
As might be surmised, the volume of data processed
by the City is vast and any attempt to centralize the
data of general interest in one place would present
problems of administration and coordination beyond
those already discussed.
There are two factors in New York's administrative
situation which aid the objective we are concerned
with. First is the fact that all local agencies gathering
geographic data on New York City are responsible
to the Mayor. In many other communities there is
a division between· city and county functions which
makes coordination of files an impossible consideration.
Very frequently property assessment is a county
function as in Cook County, Illinois, where Chicago
is located. The second factor is that l\tlayor John
Lindsay has re-organized many departments in new
superagencies. This has started processes of centralization, cooperation and re-examination of existing
data resources and needs. These processes have greatly
aided the coordination of data sources on a city-wide
basis.
responsibilities covering the streets, the shoreline, the
land and the buildings is spread through more than
twenty separate agencies. Figure 1 presents New
York's geographic data network as it might look at
the administrative level when the network is fully
developed. All agencies shown will be routinely exchanging data with a central Geographic Information
System (GIST). In addition, many of the agencies
will be exchanging data with each other. The lines
shown between agencies indicate the most probable
links that will be required. Most of these links win
probably consist of manually transported magnetic
tapes. In some cases batch teleprocessing and on-line
communication may be required
Four components of this network will be described
in this discussion: the GIST system and the three
agencies whose data-gathering activities ",ill furnish
the principal support to the network.
GIST is intended to serve as the fulcrum or central
switchboard for the network. It will facilitate coordination and exchange of data among agencies through
various types of standardization and correlation. For
example, it will be able to identify the building corresponding to a known tax lot number; it will recognize
when two addresses on different streets identify the
same building. These are typical of the problems
which restrict coordination and use of many records
at present.
GIST will maintain files on data items of wide
general interest. Its files will be maintained and updated
through the activities of operating agencies as a byproduct of their own data processing. The GIST System
Scope of N ew York City' 8 geographic information system
General
New York City consists of five counties containing
approximately 48,000 blocks separated by 9,000 different streets. The blocks are divided into 830,000 lots
which hold over 900,000 buildings. City government
515
Figure I-Conceptual view of geographic data network
516
Spring Joint Computer Conference, 1969
will function as part of a municipal EDP Service
Center, with capabilities for processing geographic
data to satisfy various requests: simple queries, complex
analyses, matching and checking of addresses, automatic generation of maps and overlays. It may, at
a later stage of development, serve the general public.
The GIST files will be restricted to current-status
data. The files of the operating agencies will contain
the supporting historical records and detailed information which generally are used only by the agency
which collects them.
Near the center of the network are three agencies
wbich generate more than 90 percent of the data
which other agencies are interested in obtaining:
City Planning, Finance Administration and Housing
and Development Administration.
The Department of City Planning, which is the
arbiter of zoning, determines the pattern of land use
in the City, i.e., what kind of buildings may be erected,
their size, their use. It also establishes where public
improvements will be located, such as schools, parks
and highways. To support their decisions the Department conducts research on economic activities, residential trends and population movements. They assist
the Bureau of the Census in planning the censustaking in the City. Most of their research results are
available for general circulation, but partly because
of the effort of correlation needed to utilize results of
different studies, it is generally preferable at present
to focus on particularly critical areas of the City at
anyone time.
One significant file which City Planning maintains
is the Address Coding Guide. Similar files are maintained by many localities to meet the requirements
of the Bureau of the Census. The file relates house
addresses to census blocks, tax assessors' block numbers,
health areas, police precincts, planning districts and
other zones of significance. The file is used for locating
buildings and coding addresses so that data can be
sum:marized geographically for statistical purposes.
Use of the file as an index is restricted by the fact
that it is nlaintained on tape (five reels) contains
approximately 54 million characters. Almost all of
this file will be duplicated in the central GIST system.
The Finance Administration combines three departments: Registrar, which maintains the records of
property ownership, Property Assessnlent, which
determines the fair values of land and buildings, and
the Finance Department, which collects taxes on
property, water and sewer use, incomes and other
sources. These departments have complete and systematically maintained records covering all buildings in
the City. It should be noted, however, that there are
some significant weak points in their files. For example,
when properties are taken by the City, either through
condemnation or forfeiture, or when properties are
transferred by will or by court action, the title is
frequently not recorded in the Registrar's Office. Also,
since many property owners pay their taxes through
banks or mortgage companies, their identity cannot
be precisely determined. Finally, since the assessors
are not concerned with tax-exempt properties, the
records on these buildings, which include city-owned
buildings, are not always complete.
Most of the assessors' more important data are
already machine-readable. These include the lot
dimensions, building size, building use, assessed value
and current owner or mortgage holder. However,
property assessment is becoming more sophisticated,
making more systematic use of data on convenience
to public services, comparisons with similar buildings
and character of neighborhood. All of these items are
of wide interest and when captured in machine-readable
form, would be maintained in the central system as
well as in the Property Assessment System. Similarly,
the Registrar's records on ownership and mortgages
are being considered for computer conversion and
these data are also of importance to many agencies.
The Housing and Development Administration
consists of five agencies concerned with the various
aspects of new construction, relocation and maintenance
of the housing stock. Three departments are significant
here. First, the Department of Buildings which reviews
all new building plans, inspects elevators, boilers and
on-site construction and issues permits for demolition,
construction and occupancy. Next, the Department
of Development which plans and develops publiclyfinanced housing. Finally, the Department of Rent
and Housing :Nlaintenance which supervises l'entcontrolled apartments and, through various programs,
seeks to assure that all housing is adequately maintained.
A major effort is now in progress to develop a Housing
Data Bank which will enable the many operations
within HDA to draw on each other's resources. This
is being developed in conjunction with several major
applications which should greatly improve the effectiveness of housing maintenance and inspection programs.
The Housing Data Bank, as presently planned, would
reside in a combination of fast and slow random-llccess
storage. It would contain approximately 3.1 billion
characters. Only a small portion of these items are of
general interest outside HDA.
It may be noted from the above that the different
agencies are, for some programs, interested in all
parts of the city while for other activities their interest
Development of New York City's Geographic Data Network
is centered on specific areas or particular types of
buildings. There is no reason therefore, to expect that
the City's automated files ",ill be equally complete
for all data being collected nor do they need to be.
Current activities
Several components in the data network are presently
in development. The Police Department's SPRINT
System, using on-line terminals to locate requests
for help and dispatch police cars and ambulances,
will be in operation by the end of 1969. The Model
Cities Conunittee, which is developing detailed data
bases for the Model Cities areas has been using complex
matrices to determine the optimum mix of renewal
projects for a neighborhood. The Housing and Development Administration, as mentioned earlier, is
designing several major applications around a large
Housing Data Bank.
The remainder of this discussion will be on the GIST
System, its overall design and current development.
GIST is being developed by the Office of the Deputy
Mayor-City Administrator, Dr. Timothy W. Costello
under the supervision of Dr. E. S. Savas, Deputy
City Administrator.
Overall design of GIST system
1. Files
GIST will be supported by three principal files.
The items planned for inclusion in each are
shown in Tables I through III. The source
shown next to each item identifies the agency
which will provide and maintain that item. The
method and schedule of maintaining each item
in the GIST files will be established for the
convenience of the source agency. Briefly, the
files are as follows:
a. The Street-Name File ",ill contain the legal
name and commonly used names for every
street. In addition, street code designations
Table I
in wide use, such as Police and Buildings
Departments, will be included. The GIST
system will generate a five-letter code for
each street for internal identification and
sorting.
b. The Block-Face File will contain one record
for each block side. Thus, for a norma]
rectangular block, four records would be
maintained. Each record will contain 10cational data relevant to the block or
block face. This will include tax block
number, census block number, range of
house numbers, rurection of traffic and
geographic coordinates at each corner of
the block. These coordinates have been
determined through work by the TriState Transportation Conunission using.
aerial photos. Accuracy is to the thousandth
of a mile - that is, to within five feet.
Other data included will be block adjacencies. These describe the spatial relation
of the block face to its neighbors, e.g.,
around the comer, across the street, directly opposite, etc. These data will simplify
many types of districting and routing
applications where it is necessary to know
the orientation of a block side.
c. The Building/Lot File will contain one
record for each lot, major structure and
owner. If a structure occupies two or more
lots, there will be added records for the
extra lots. If there are two or more major
structures on one lot, there will be an added
record for each additional structure. If
distinct portions of a lot are held by differ·
ent owners, particularly if part of the lot
is publicly owned, there will be a separate
record for each owner.
Each file will be related to the others, that is, Table
I will serve as a rurectory to Table II, Table II as a
directory to Table III.
Street-name file
There will be one record in the Street Name File for each street name in common
use.
Item
Borough
Common Name
Official Name
Building Department Street Code
Police Department Street Code
GIST Code
517
Source
City Planning Department
Being developed
City Planning Department
Building Department
Police Department Sprint System
Being developed
518
Spring Joint Computer Conference, 1969
Table II
Block-face file
IDENTIFICATION DATA
Item
Record Identification
Borough
Tax Block No.
Tax Block Suffix
S - Street Name
Source
Being developed
City Planning Department
City Planning Department
City Planning Department
City Planning Department
t
r - Street Suffix
e
e - Street Ending
City Planning Department
City Planning Department
t
City Sectional Map No.
Census Tract
Census Block
Census Block Suffix
Type I Adjacent Block sides
Type II Adjacent Block sides
Type III Adjacent Block sides
City Planning Department
City Planning Department
City Planning Department
City Planning Department
City Planning Department
City Planning Department
City Planning Department
DISTRICTS
Health Area
Health District
Police Precinct
Fire Company
Sanitation District
Hospital District LOCATION
Street Segment Identification
Number of block sides on block
Block Side No.
High House No.
Low House No.
High Intersecting Street
Low Intersecting Street
High block side No.
Low block side No.
Geographic coordinates:
High Corner: XH
YH
Low Corner; XL
YL
Each record will be as complete as possible for information concerning building description, land description, mvnership and current pennits and violations.
It will be the user's responsibility to determine how
accurate, complete and current the file is for the items
he plans to use.
Dept. of Health
Dept. of Health
Police/Sprint
Fire Department
Sanitation Department
Police/Sprint
Being developed
City Planning Department
City Planning Department
City Planning Department
City Planning 'Department
City Planning Department
City Planning
City Planning
City Planning
City Planning
City Planning
City Planning
City Planning
Department
Department
Department
Department
Department
Department
Department
2. Operation
The capabilities, functions, and plan of operation for GIST are shown in Figure 2.
The user, representing any City agency,
will enter his data into processing together
with instructions which define the format of
Deveiopment of New York City's Geographic Data Network
Table III Building/lot file
There will be one record in this file for each building~ lot and owner.
OWNERSHIP DATA
Item
Owner/Manager's Name
Owner/Manager's Address
Mortgage Holder's Name
~1ortgage Holder's Address
IDENTIFICATION
Principal House No.
Range of Numbers for House
Tax Lot No.
Source
Finance Administration and
Finance Administration and
Finance Administration and
Finance Administration and
others
others
others
others
Finance Administration
To be developed
Finance Administration
LAND DESCRIPTION
Frontage
Depth
Irregular Plot Code
Total Area
Present Land Use Code
Special Land Features
Zoning Classification
Finance Administration
Finance Administration
Finance Administration
To be determined
City Planning Dept.
To be developed
City Planning Dept.
BUILDING DESCRIPTION
Year constructed
Type of construction
Frontage
Depth
Total area
Floor space (sq. ft.)
No. of stories
Latest alteration (date)
No. of buildings
Private garage (res.)
No. of establishments
No. of dwelling units
Finance Administration
Buildings Department
Buildings Department
Buildings Department
Buildings Department
Buildings Department
Buildings Department
Buildings Department
Buildings Department
Buildings Department
Buildings Department
Buildings Department
PERMITS AND VIOLATIONS
Demolition permit (date)
Construction permit (date)
Certificate of Occupancy (date)
Crane permit (date)
Violations (no.) :
Fire Department
Buildings Code
Health
Sanitation
Air Pollution
Buildings Department
Buildings Department
Buildings Department
Highways Department
Fire Department
Housing and Development Administration
Health Service Administration
Environmental Protection Administration
Environmental Protection Administration
519
520
Spring Joint Computer Conference, 1969
Figure 2-GIST-Geographic information system
his data fields and indicate what processing is
to be done. For regular users, standard instruction routines will be provided.
If the input records contain house addresses,
the input will first be processed in Phase I.
The street names will be verified and, if necessary, reformatted and corrected. A street code
will be added to facilitate internal identification
and record sorting. A master file such as that
in Table I will be required with a record for
every street name in common use.
If a street name is not recognized, an error
message will be produced by a method which
facilitates correction. Subsequent tasks will be
determined by the user's instructions. In the
simplest case, he may want a new item, such
as health area or assessor's lot number, added
in a designated field on each record. These
items would be obtained from Tables II or
III. The end product would then be a tape
with the same number of records and in the
same format as the original but with the requested data added.
The' user's initial input could be identified
by means other than house address. For example,
data could be identified by tax block, by street,
by health area or by geographic coordinates.
It will be possible to request data concerning
buildings within a given set of geographic
boundaries or within a circle of given radius
from a focal point.
More complex tasks will be supported as
they become feasible: records may be combined
or split on the basis of master file data, records
may be selectively updated, etc. The variety
of tasks can be gauged from the items included
in the GIST tables.
Another series of tasks will be required so
that input data can be used to update the
master file. This will involve splitting and
consolidating existing records. Initia!ly, the
files will be stored on tape. When the system
is fully implemented, the files will be located
on random-access devices. It is expected that
eventually the system will be modified to
accept data and queries entered from on-line
consoles.
The output of Phase I processing will be
in the form of a tape. Dependent on the user's
instructions, t:his 'Will be returned to the user
for further processing at his own installation
or it will be entered in GIST Phase II.
Phase II will select and sort data from
designated input files which have been through
Phase I processing. These can be one or more
files which the user has supplied, either from
his own agency or frolD other cooperating
agencies or from the GIST files. Various manipulations and data transformations could be
performed. Output would be in the format
specified by the user. Tape, cards, printed
output, or maps would be produced, at the
option of the user.
Each task described win probably require
a number of programs to accomplish, and a
set of user instructions will be required to
specify the various tasks. RPG and natural
language are among the instruction vocabularies being considered.
Current development of GIST
Full implementation of the GIST system is expected
to take five years. However, two capabilities planned
for GIST will be available by the end of 1969. These
should assist the solution of specific information
handling problems which are present in many City
agencies.
1. Standard A ddress Generator
The first is a set of programs which will accept
any file of machine-readable records that contain
street addresses and reformat and standardize
those addresses for computer handling. If the
house-number field overlaps the street-name
field, the two fields will be separated and reformatted for subsequent processing. The street
name will be verified and minor spelling errors
corrected. If the street name cannot be verified,
an error message will be produced. In the final
program output, for each record successfully
Developm.ent of New York City's Geographic Data Network
processed, a field will be added to the start of
the record containing the reformatted identification data. Included in this data will be a
five-letter street name contraction.
This output tape will be available for sorting,
matching or other processing that the user
chooses. These programs include the functions
shown as steps 1 and 2 in Phase I processing
in Figure 2. This application will facilitate the
analysis of data in street address files and
permit matching of data contained in address
files of different departments which are in
incompatible formats.
The prog1,'ams will operate on IBM 360/30
or larger machines utilizing 16K DOS/TOS
operating system with core storage of at least
32 K bytes. It will be a modification of a set
of programs produced for the U. S. Bureau of
the Census.
2. Geographic Conversion and Mapping
The second capability is a set of programs
and files which can operate on standardized
addresses (such as those obtained through the
Standard Address Generator) to provide certain
kinds of locational information. It will, for
example, provide the health area, tax block or
census block number for a given address. It
will provide the approximate geographic coordinates for an address, and it will have the
capability of drawing maps.
Thus, for example, it will be possible to
generate a map of registered voters showing
the number of registered voters in each building.
It would prepare maps showing the distribution
of ambulance calls in a borough. It would also
be possible to generate a map showing the
addresses and locations where new construction
permits or demolition permits had been issued.
It could select and map any information which
could be identified by street address or located
to a geographic area.
The output could be a tape with the desired
locational data added to each record. It would
be possible to use this tape selectively for
plotting and mapping. Figure 3 shows a map
section which has been drawn by a computer
as a demonstration of the mapping capability.
The map is of a section of upper Manhattan.
The number, obtained from the Board of
Elections list of registered voters, shows only
_I
_I ! 3 ! I ! • \.,
1. .
1
I
I
t
D~D
...1 • I !
I,
~I
,
..
,D
~!
I~
L
I
;/
I • • •I
, '"I
•
•
wi
'1 ..
!
t..
rat
'
D
!
,
~I
~.1:M
r'.
L
Era'1
Figure :{-Computer-generated map showing addresses of
registered voters
the houses where registered voters live. This
capability should have use in a variety of
planning and resource allocation activities.
REFERENCES
1 SYSTEM DEVELOPMENT CORPORATION
Report of the APOF conceptualization study
Santa Monica California March 31 1966
2 CITY ENGINEERING DEPARTMENT
A.n information retrieval system for urban areas
Vancouver British Columbia May 1967
EAST-WEST GATEWAY COORDINATING COUNCIL
The role of locational control in an information system
St. Louis County Missouri September 1967
S ARMS
Jfap/model''51/stem-t.echnical concepts and program
descriptions
Portland Oregon February 1968
COUNTY EXECUTIVE
Management information system
Nassau County New York March 1968
METROPOLITAN PLANNING COMMISSIONKA~SAS CITY REGION
Integrated information system for urban planning
Kansas City Missouri August 1968
:3 METROPOLITAN DATA CENTER
Metropolitan data center project
Tulsa Oklahoma 1966
Requirements for the developlllent of
computer-based urban information
systems
by STEVEN B. LIPNER
The M a8sachusetts Institute of Technology
Cambridge, Massachusetts
INTRODUCTION
Since early in this decade urban planners and systems
analysts have advocated the development of computerbased urban information systems. Such systems would
store detailed data about the environment in which
planning agencies and governments operate. They
would be organized to lend integration to data from
diverse sources, to provide quick preparation of reports
and to simplify and automate numerous clerical
functions. Many attempts have been made to develop
urban information systems with the characteristics
mentioned above. Most have been unsuccessfuP for
a combination of technical and organizational reasons.
This paper considers some technical requirements for
planning information systems which deal with data
associated with urban locations. The requirements are
developed on the basis of experience in providing a
prototype urban information system to the Boston
~Iodel Cities program. The next section describes
briefly the experience of providing an infOlmation
syst~ to the Boston Model Cities program. Succeeding
sectIOns draw on this experience to develop general
technical requirements for urban information systems.
~ tec~ique for aggregating data by geographic area
IS presented and its implications for system file structure
and utilization are explored.
Information system for the Boston Model Cities
Administration
During the spring of 1968, M.LT. staff members
held a number of meetings with members of the staff
of the Boston Model Cities Administration to determine
how M.I.T. might assist Boston's IVlodel Cities program. One of the major desires of the :NIodel Cities
staff members was to see if an urban information
system could be used to aid their planning and program
evaluation activities. The Model Cities Administration was undertaking a survey which would det~rmine the land use, building condition, and building
Slze associated with each parcel in the Model NeiO'hborhood Area. It was agreed that this data would m:ke an
acceptable basis for a prototype urban information
system. l\10del Neighborhood residents employed by
the M.odel Cities Administration were trained in key.punchmg and prepared approximately 8000 cards, one
for each parcel in the area. (For comparison, the city
of Boston contains about 100,000 parcels.)
The survey data was input to the ADIvIINS2,3
system operating on the time-shared 70944 at the
MIT Computation Center. ADMIKS is an interactive program capable of performing data selection
and cross-tabulation. It was designed for use in the
analysis of social science surveys, and is best suited to
operating on small files of coded or integer-valued data
items. It is weakest in the areas of data modification ,
large file handling, and real or alphanUllleric data
manipulation.
Initial preparation of the data for AD1VlIKS analysis
was judged too complicated and machine-oriented a
task to be performed by persons with little computer
training. Accordingly the data was prepared for
analysis by MIT personnel experienced in programming
and in the use of ADJVIINS. The data preparation
was simplified by the ability of ADMIXS to accept
data in arbitrary codes and formats and by the interactive mode in which it is used. Errors in the data
were reported by ADMINS programs and corrected
by using the time-sharing system's general purpose
editing capabilities to modify the input files.
The analysis of the 1\10del Cities survey data was
performed by three groups of people: MIT staff
523----------------------------------
524
Spring Joint Computer Conference, 1969
members with substantial computer experience, professional urban planners with little or no prior computer
experience, and ~1odel Xeighborhood residents with
neither computer experience nor extensive formal
education. All three groups easily mastered the mechanics of producing desired cross-tabulations, although
a natural "fear" of .the computer terminal had to be
overcome by those new to it.
The response of the planners to the prototype urban
information system was both interesting and significant. Although they had been instructed in the use of
ADl\1INS at the terminal, and given freedom to
produce reports as needed, the planners preferred to
contact l\lIT or :\10del .xeighborhood personnel,
describe verbally the required tables, and have the
resulting hard copy delivered to them. 'Vhether this
phenomenon was caused by the lack of proximity of
the planners to the terminal, by the relatively tedious
ADlVIINS language, or by a basic reluctance of planners to use the computer directly remains undetermined.
(Placement of a terminal at the Model Cities office has
been planned for some months but has been delayed
by various administrative and operational problems.)
When the planners have more direct access to a terminal and are provided with a system which, unlike
ADl\lINS, is designed to serve as a true urban information system, it should be possible to detem1ine if
experienced planners without computer experience
can successfully be trained and encouraged to use a
computer as a planning tool. The implications of such
a determination are discussed in the next section.
The analytic results produced for the planners
using ADlVIINS were useful, and all agreed that they
were pleased with the results of the analysis. The
limited computer experience, however, whetted the
planners' appetites for more diverse capabilities. These
capabilities included:
1. The ability to aggregate data by arbitrary
geographic areas such as school districts, without being required to list explicitly every block
contained in each area.
2. The ability to produce maps and graphs as
well as tables.
3. The ability to merge data gathered by operating
agencies and survey research organizations
with stored data.
4. l\10re general capabilities for numeric and
alphabetic data processing than those provided
byADMINS.
The experiment in computer-aided lVIodel Cities
planning has been successful in two senses. First, it
provided valuable insights into the capabilities required
of an urban planning information system. Second, it
introduc'ed a group of planners to computer-aided
analysis. In th;j future these planners should provide
valuable data on the mode of man-machine communicatioll appropriu,tc for all urbal1 p!annillg illformatio11
system.
Requirements for urban information systems
The experimental provision of computer support
to planners described in the previous section provided
several insights into the capabiJities required of an
urban infonnation system and the specific features
required to implement them. Perhaps the most im=
portant capability indicated is that of combining and
using in a single information system data from a
variety of sources. Special surveys are BJn expensive
and short-lived source of planning data when compared
\-vith operational data which must be maintained, often
in machine-readable form, by agencies other than the
planning department. Operational data from a given
agency, in order to be useful to the planner, must be
combined with planning survey data and often with
data from other public or private operational agencies.
Since different agencies often use different identifiers
for each parcel, and since the street address is the only
corrunon and (presumably) unique parcel identifier,
t.he conclusion is reached that a useful planning information system must deal with parcels identified by
street address. Address matching programs5 have been
developed which standardize the formats of street
addresses keypunched in free format. They must be
included in an urban information system, along with
file structures appropriate for the identification of
parcels by street address. The need to merge data
from differing sources implies the possibility of varying
amounts of data describing a single parcel. Such
possibilities must be handled by a flexibJe but efficient
data file structure.
A second major requirement of an urban information
system is the ability to aggregate parcel data by
arbitrary geographic area. This ability is especially
important in view of the numerous overlapping administratjve and planning districts into which urban
areas are divided. Programs have been developed6 ,7
which aggregate data into districts by first assigning
coordinates to each parcel, and then testing each parcel
to see if its coordinates lie within a distIict. Such
programs work but seem suited mainly to sequential
storage systems using fast computers. The reasons for
this observation and an alternate technique based on
street addresses will be presented in the next section.
The importance of graphical display of data to
planners was emphasized during the initial work with
model cities planners. Any really useful urban infor-
Requirements for Development of Computer Based Urban Information Systems
mation system must produce graphical as well as
tabular output, preferably with minimal user description of coordinates, scales, etc. Existing programs
and systems8 are capable of producing a wide variety
of graphic outputs. The major problems in applying
these to urban information systems are, first, assuring
that the outputs they produce are those required by
planners and second, integrating the graphic components with data management components to minimize the complexity a.nd cost ot producing the outputs.
The area of man-machine communication is one
which may be critical to the success of urban planning
information system design. The experiment described
above produced results which can only be described as
inconclusive. However experience in the use of computers by engineers9 would seem to indicate that the
use of computers by persons who are not computeroriented is greatly aided by the availability of interactive problem-oriented languages. In order to produce
definitive results in the area of communication between
computer and planner it will be necessary to provide
both better terminal access and a problem-oriented
language superior in both power and usability to that
of ADlVIINS. The growing presence of planners who
have had computer training should provide further
assistance in improving man-machine communications.
In re-examining the requirements developed in this
section, we find that all except those of geographic
aggregation of data, address matching and graphical
output would be common to any powerful information
system: file structures which allow items to be described by varying numbers of attributes, file structures
for rapid data retrieval, and powerful problem-oriented
retrieval languages are all provided by many modern
information systems. 1O ,ll Of the required features
which appear unique to urban information systems
the mosL significant seems to be that of geographic
aggregation of data. Address matching is essentially
a preprocessor function· and graphic output an important output processor, while the geographic aggregation method will have a significant effect on the
cost of many retrieval requests and some influence on
internal file organization. For this reason, the next
section is devoted to a brief description of an alternative
to existing schemes for geographic aggregation of data.
A technique for geographic aggregation of parcel data
The problem of geographic aggregation of parcel
data in urban information systems has typically been
handled by "point-in-polygon" programs. 6 ,7 Such
programs require that each parcel which is included in
the information system be identified by its x-y coordinates. An area for which data is to be aggregated
525
is described as a polygon by specifying the coordinates
of its vertices. Each stored parcel is tested by counting
the intersections of a ray of arbitrary direction originating at its identifying point with the sides of the
polygon. If the count is even, the point (and hence
the parcel) is outside the polygon. If the count is odd,
the point is inside (Figure 1).
A1though the point-in-polygon test is a workable
technique for geographic aggregation of data, it poses
two problems. First, and less significant is the probleln
af assigning coordinates to every parcel. This problem·
is easily solved by representing every street as a
sequence of line segments and using the numerical
value of each parcel's address first to select the segment
containing the parcel and then to define the parcel's
coordinates by interpolation between the segment's
end points. The second and more serious problem
presented by the point-in-polygon technique involves
processing time. Since the point-in-polygon technique
is a test on one parcel, every parcel recorded by a
system must be tested to determine which parcels
should be aggregated into a given area. Thus, the
technique is ill-suited to systems employing directaccess storage devices which could allow selective
access to desired parcel data. Furthermore, the calculations required to determine whether or not each
parcel lies in a given area involve one line intersection
for each side of the area. On some small computers
this calculation may be relatively time-consuming.
Thus even if the parcel data base were recorded on
tape, the time required to select those parcels in an
area could be governed by processing time rather than
by the time required to move and read the tape.
Techniques have been ~uggested12,13 which, by
dividing an urban area into subareas, would reduce the
sequential file searching required by the point-inpolygon algorithm. These techniques would require
checking of the retrieval area for overlap with preestablished subareas before individual parcels i.n the
8
--+--------------------4--
Count • 2;
Point 8 outside
__-+__---'~------+_- C 0 u n t • 3;
Point A inside
Figure I-Point-in-polygon test
Spring Joint Computer Com'erence, 1969
526
subareas were examined. If the check showed no overJap, no further examination of the subarea would be
required. Otherwise every parcel in the subarea would
be checked. The disadvantages of this method are
principally associated with the size of subareas. A
large number of small subareas requires a large number
of overlap tests, while if a small number of larger
subareas are used, there will be a large number of
parcels requiring point-in-polygon testing included in
each selected subarea.
An alternative to the point-in-polygon technique
for the geographic aggregation of parcel data was
suggested first by FarnsworthI4 and later proposed
independently and in more detail by Parsons. IS The
algorithm involves using a map of the street network
of the urban area within which new geographic areas
are defined. Given a list of the names of the streets
surrounding the area of interest, the algorithm produces
a list of those parcels within the area. The paragraphs
below present an illustration of the algorithm, followed
by comments on the map file struct.ure required to
implement it.
In considering the map of Figure 2, let us assume we
wish to isolate the area bounded by streets A, H, D
and E. We first scan the street A until we locate the
set of street segments (portions of a street between
two intersections) on it between E and H. We then
scan street H, marking the segments between A and
D, street D for the segments between Hand E, and
street E for the segments between D and A. Since the
list of bounding streets was given in a clockwise direction, we know that blocks inside of the desired
area are to its right. If we have recorded the numbers
of the blocks to the right and left of each segment,
seen facing in the direction of increasing addresses,
we may nmv isolate those blocks L,'1side the bounding
streets. To do this we record blocks to the right of
XI
I
XII
Xli!
A
X
I
II
III
XXI
I
IV
V
VI
XX
I Vll
VIII
IX
----I
I
B
c
o
I
I
E
\
XIV
XV
INCREASING
ADDRESSES
I
I XVI
segments whose increasing address direction coincides
with the direction of the area boundary (street A and
E) and blocks to the left of segments whose addresses
run opposite to the boundary (streets D and H).
Applying this procedure we obtain the list of contained
blocks in Figure 3.
As we make the list of contained blocks, we may also
make a list of non-contained blocks (Figure 4). These
are blocks opposite the contained ones which lie just
outside (to the left) of the area boundary. Now we
may make a list of blocks adj acent to those blocks
listed in Figure 3, excluding blocks already listed as
contained or non-contained. This list contains only
one block, block V. Enumerating the blocks adjacent
to block V we find that all have already been listed as
contained. Thus all blocks within the area of interest
have been isolated. From the list of blocks in the area,
we may develop a list of the address ranges along COlltained streets or of the parcel numbers of parcels
contained in the area.
The algorithm and problem described are reliable
only when used with a street network in which no
two streets intersect more than once. Techniques have
been developed by the author which generalize the
algorithm to handle cases in which two streets may
intersect more than once, by eliminating resolvable
ambiguities or by reporting the presence of irresolvable
ones. The generalization requires changing the initiai
analysis of the list of streets bounding the area from a
one-pass to a multiple-pass operation. The first pass
isolates all possible sequences of segments which could
surround the desired area. The second and succeeding
passes eliminate incorrect paths by searching for
discontinuities in the transitions from one street to
the next. The process is continued until one correct
path femains Of until no further incorrect ones can be
detected.
Two files are used to allow a computer program to
implement' the algorithm described above. The first
contains data about street segments for every street
in the map, whiJe the second contains lists of the blocks
Figure :3-First list of contained blocks
XI, XII, XIII, XIV, XV, XVI
XIX XVlII XVII
I
I
F
G
XVII, XVIII, XIX, XX, XXI, X
H
Fignre 2-Map for geographical ret,rieval
Figure 4-List of non-contained blocks
Requirements for Development of Computer Based Urban Inforll1ation Systems
adjacent to every block in the map. The first file is
used to isolate the sets of blockg just inside and outside
an area described by its bounding streets. The segments
along a street are ordered by increasing address range,
and aach segment is described by left and right block
numbers, beginning and ending node numbers, .and
intersecting streets. Additional data on street address
ranges and node coordinates for each street are typically included to broaden the utility of the segment
file. The block file must include the numbers of the
blocks surrounding each block, and should contain
data to allow conveTIlion from the numbers of the
blocks in the desired area to the data themselves-either
as street names and address ranges, as parcel numbers,
or as disk identifiers of data records. Both files described above may' be produced as by-products of the
DL'\IE editing technique16 described by Cooke and
::\laxfield.
The algorithm outlined above for using a street
network to facilitate geographic aggregation of parcel
data has both advantages and disadvantages when
compared to the point-in-polygon technique. Its
principal advantage is that it is essentially a directaccess technique. The time required to isolate the
identifiers of those parcels in an area is proportional
to the number and length of the streets surrounding
the area and to the number and complexity (number
of adjacent blocks) of blocks in the area. Small areas
may be isolated very quickly. If some sort of directaccess storage is used for parcel data, the parcels in the
area are the only ones retrieved. If sequential storage
is used, the algorithm can at least produce a list of
parcel identifiers (for example address ranges) which
will allow much speedier checking of individual parcels
than would be the case with the point-in-polygon
routine. The principal disadvantage of the street network technique is its limited flexibility. While the
point-in-polygon technique may be used to select
parcels in any area, the network technique is clearly
applicable only to areas made up of whole blocks. This
problem is potentially most serious in analyzing areas
such as new highway corridors which do not follow
~)lock boundaries. I t seems possible that performing
such analysis by using the point-in-polygon technique
on a set of parcels selected by the network technique
might be more economical than applying it to an
parcels in a city. However, this hypothesis must be
verified.
File structure
The basic implication of the geographic aggregation
technique proposed above is that a direct-access file
system is very desirable. The principal requirement of
527
this structure is that it be capable of being tied to
the block data of the street map file. One flexible
way of establishing this tie is to use street address as
the major identifier of each parcel and to store street
names (or identification numbers) and address ranges
in the block file of the street map. The street names
and address ranges defining all block faces (one side
of a segment) in an area could be merged together
and sorted into an order corresponding to that of the
parcel data file. Then retrieval from the parcel file
could be directed by the sorted output of the aggregation algorithm. Retrieval of data about those parcels
in a given area could proceed at a speed governed
only by the efficiency of the parcel file's indexjng scheme.
Variable amounts of data for a single parcel could be
stored either in variable-length data records or in
multiple files each using street address as primary
identifier. Two major advantages of using street
address as the primary parcel identifier are, first that
an inquiries about parcels by street address would
be facilitated and, second, that additions or deletions
of occupied addresses within a block face necessitate
no alterations to the network data describing that
block face.
If a sequential file structure is to be used for parcel
data, for reasons of restricted data access, economy,
or data volume, the comments about using street
address as primary identifier still apply. Although
sequential processing becomes imperative, the simplicity of processing allowed by using street address
ranges as output from the geographic aggregation
algorithm will still minimize the actual processing
time required to select parcel data. This minimization
may be important when processing data on a small
machine or in a partition of a large one.
A planned experimental system
The techniques used above are to be put into practice
in an experimental information system for use by the
Boston Ylodel Cities Administration and :VIIT Urban
Systems Laboratory. The system will include a street
network file and street network geographic aggregation
algorithm. The street network file will be tied to a
parcel data file by street addresses. ::VIultiple parcel
data files will be used to handle multiple data sets
(initially housing survey and demographic survey files)
on direct-access storage. Control and problem-oriented
language faciJities will be provided by the ICES
systemY The system should be implemented by June,
1969 and will be operated as a planning aid for the
IVIodel Cities Administration by N[odel Cities and
lVIIT staff members. In addition to providing basic
statistical and cross-tabulation facilities, it is hoped
528
Spring Joint Computer Conference, 1969
that the system will allow the addition of analytic
and modelling capabilities by planning researchers.
ACKNOWLEDGIV[ENT
The work reported here was aided and influenced by
many people over the last year. Especially worthy of
mention are Professor Charles ~Iiller, Professor Robert
Logcher, ::\1r. William Parsons, NIr. Ronald Walter,
lVlr. Donald Cooke, and J\'liss Betsy Schumacker of
M.I.T., J\Ir. Edward Teitcher and Mrs. Colette Goodman of the Boston Redevelopment Authority, and
Mr. Nlichael Warren, J\1r. Richard Harris, ::vlr. Samuel
Thompson, and lVlr..John :Vlyers of the Boston ::Vlodel
Cities Administration. The work reported herein was
conducted at and sponsored in part by the Urban
Systems Laboratory of the l\IIassachusetts Institute
of Technology.
BIBLIOGRAPHY
o
2
:{
4
5
.E DIAL
Crban information systems: A bibliographic e.-:say
Urban Systems Laboratory MIT H)6~
S MciNTOSH D GRIFFEL
The ADM INS primer
Center for International Studies MIT
S McINTOSH D GRIFFEL
The language of ADMINS
Center for Internationai Studies wi I T
P A CRISMAN
The compatible time-sharing system: A. pro{frammer's guide
MIT Press
H H COCHRAN
A.ddress matching by computer
Proc Sixth URISA Conference 1968
ti It B DIAL
SI reel aridresN C()lwef'sioh pro(J/'a1/i
Urban Dab, Cen.ter University of Washington
7 S ~()nBl'~CK B It YSTEDT
Con~puter carlo{jraph,1J poinl-in-po!yuon PJ'o(f!Ylnl8
BIT 7 1967
8 D F COOKE
Systems, yeocoding and mappinu
Proc Sixth URISA Conferenee 1\)6~
H C L MILLER
Jfan-machine communications in civil enfjineerinf/
I )epartment of Civil Engineering MIT
10 R E BLEIER
Treating hierarchical data structures in the Sf)C Hmeshared data mana(fement systems (TDll,fS)
Proe A C M ~at.i()nai Conferenee H)67
11 E W FRANKS
£t data mana(femenl system for lime-shared .file pmc('.8.'1iny
Ilf::,in(f a croso'?-index .file and self-definht{l enlries
Prot S.J C C 1!l66
12 K J DUEKER
Spatial data system .:;
:'\orthwestcrn UniverHity
1:1 S B LIP~ER
File structures for urban information 8:t!idems
Internal Working Doeument :M I T 1!l6R
14 G L F AR~S"YORTH
Contiguity analysi,<; using censw~ data
Pro(' Fifth Annual URISA Conferenee 1967
15 W A PARSONS
l Tnpnbli8hed class project report
MIT Subject 1 152 1968
10 D F COOKE W II MAXFn~LD
The development of a geographic base .file and ito'? 1I.<:e.<; fo/"
mappinfl
Proc Fifth Annual UH.ISA ConferenC'e 1967
17 D ROOS
ICES system: General description
Department of Civil Engineering MIT
Automatic traffic signal control
systems-o-the metropolitan 'l'oronto
•
experIence
by JOHN D. HODGES, JR.
UNIVAC Division of Sperry Rand Corporation
Los Angeles, California
and
DOUGLAS W. WHITEHEAD
Metropolitan Toronto Roads and Traffic Department
Toronto, Canada
INTRODUCTION
Like a number of fast growing North American cities,
Metropolitan Toronto is faced with the ever increasing
problems of greater motor vehicle traffic volume, congestion and accidents. Metropolitan Toronto today
has more than 700,000 vehicles registered in its 240
square miles, for a per capita density that rates behind
only Los Angeles. In addition over 100,000 vehicles
from outside the area converge daily on the City.
In 1957, Mr. S. Cass, Metro's Commissioner of
Roads and Traffic, along with a consulting firm began
to explore the methods open to them to improve existing roads and streets and, in so doing, gaining greater
traffic throughput per dollar in comparison with the
building of expensive, new main arteries. The concept
of computer controlled traffic signals to co-ordinate
and thus improve traffic movement seemed to be an
answer, providing it was feasible.
Their preliminary investigations indicated that
if a general purpose computer were operated in realtime and on-line, it could:
sidering the existing traffic speed and direction
of flow.
3. Directly control the individual signals to produce optimum conditions.
4. Check the signal operation and resulting traffic
movement to ensure that conditions were optimum.
It was further shown that a real-time computer could
alleviate many of the restrictions and problems confronted in~Ousing the normal electro-mechanical or more
specialized analog equipment to control signals. A
computerized traffic signal control system would allow
for:
1. Flexibility in changing certain signal phase
arrangements and concepts by only changing
the computer programs and not the signal
equipment.
2. Co-ordination of data between a variety of
types and makes of signal equipment and vehicle
detectors.
3. Having a variety of operational plans available
and implementable in very short periods of
time.
4. Collecting current, complete and accurate traffic flow information from all system signals
for use in determining system performance.
reliability, and optimum traffic control plans.
0
1. Take in traffic information from a large number
of vehicle detectors, determine the interval
length required at each individual intersection,
and optimize these for overall system efficiency
considering existing conditions.
2. Determine the optimum time relationship or
offset between individual intersection, con-
529
530
Spring Joint Computer Conference, 1969
The computer based traffic control system concept
was seen as the best approach to the problem of moving
more traffic through ::\1etro Toronto's streets in less
time, but some doubts were still raised as to its oper!1tional feasibility. So, in the summer of 1959, the l\letroDolitan Traffic Department began a pilot test of an
Automatic Traffic Signal System. Xine traffic signals
along 1. 7 miles of one of Toronto's busiest streets
were linked to a computer and automatically controlled until the Spring of 1961. A comparison of this
automatic system with the usual time-cycle control
of traffic lights produced these results: in the evening
rllsh hours, computer control reduced the a,rerage
delay per vehicle by 11 percent; in the morning rush
hour by 28 percent; and it reduced congestion by
25 percent. TheRe dramatic resultR were achieved
with a very limited test system and gave credence to
the concept of computer controlled traffic signal SYRterns.
•
In 1961 the Metropolitan Council decided to go
ahead with the installation of a l\1etro-wide automatic
traffic signal control system. At that juncture, a time
phased implementation program was begun. By the
end of 1969, some 850 intersections will be under computer direction. As of February 10, 1969, 594 traffic
signals are under the control of a UNIVAC 1107UNIVAC 418 computer system.
The most important factor in the ~letro Toronto
system and the one that makes it the most flexible
yet attempted, is that every l\fetro street with signalized intersections is to have sensors reporting to a
central computer. Computer decisions are based on
traffic situations at different levels. Certain decisions
are made at the individual intersection level without
regard to anything else. Other decisions are made at
the control area level (15 signals), the group level
(6-7 control areas) or the system level (5-6 groups).
The computer can detect and analyze major traffic
movements and make traffic signal adjustments to
prevent potential congestion.
As the installation of the system progressed, theories
were put into practice; some worked and others fell
by the wayside. Through trial and error, two basic
modes of control have emerged as practical methods
for the system. Due to the flexibility of the system,
the computer is able' to implement control gradually
across the City and combine a simple mode with a
more sophisticated and ultimate mode of control.
At the present time there are several different levels
of sophistication. Many areas of the City are entirely
pre-programmed 'With all changes in signal timing
initiated by time of day or manual intervention. 2\1any
other areas have traffic responsive control at critical
intersections (TR2 mode) but have area strategy
changing by time of day. A few areas have traffic
responsive control (TR2) at critical intersections and
traffic responsi\Te area control. One area has all intersections traffic responsive and complete traffic responsive area control.
The traffic control system dynamically senses
traffic from detectors strategically placed at each
intersection. Acting like an inductance loop, they
detect the presence of a metal mass and transmit
signals to the central computer site via telephone lines.
The computer complex consists of a UNIVAC 418
Real-Time Computer that acts as a com.lJ.lunications
and message switching device interfaced to a U~IVAC
1107 thin-film memory computer and its peripheral
equipment. The 418 :b..as controlled 500 sigp..aJs in a
fixed time mode without the 1107.
The actual traffic count is maintained by the computer. By the use of audio tones, signals are sent over
telephone lines connected to a ::\fultiplexer at the
central site. Through it, the signals are distributed to
their correct address in the Input Scanner, which, in
turn, is looked at several times per second by the
UNIVAC 418. Thus, a detection followed by the
absence of a vehicle presence is one car count to be
stored in the computer memory. After some data
reduction in the 418, the information is transmitted
to the 1107, which determines the optimum traffic
light pattern for the City and returns the information
to the 418.
. From there, the information goes to the Output
Distributor. The Distributor contains electlical relays
that relate to specific signal locations, which open or
close in response to the 418. Thereby each unique
traffic control bbx at an intersection can be addressed
by the 418 computer.
~lonitors in the traffic control boxes provide data
to the 418 computer to confirm that the controller
responded correctly to instructions. Should any part
(or all) of the system malfunction, the computer "Will
relinquish control of the signals effected to local phase
timers in the traffic control boxes. To provide complete
protections, the 418 must report constantly via a hold
relay to- each controller; otherwise, the controller will
automatically take over on a pre-set time cycle. The
complete cycJe of examining the traffic situation
throughout ::\1etro Toronto, and taking. action if
required, is performed once every second. At the
same time, the 1107 stores data for future analysis and
runs other programs concurrently. The benefits derived
from such a control system are numerous:
1. The optimization of traffic control signals has
..A~utomatic Tra...~C Sigr~l Control Systems
greater throughput and fewer involuntary steps.
2. Flexibility of control allows the system to be
tailored to specific areas and situations within
the whole system.
3. Manual control of signals by police is reduced,
permitting better allocation of police manpower.
4. Accidents and abnormal traffic congestion are
sensed and correction methods automatically
implemented where possible.
5. Nlillions of dollars worth of wasted citizens'
time and capital equipment can be saved.
6. Reduction in accidents due to better control
can save citizens an estimated 1~ million dollars
annually, not including doctors' fees, lost time,
lawyers' fees and court awards.
The computer system
The computer system consists of a large UNIVAC
1107 general purpose scientific computer with a
UNIVAC 418 real-time process control computer as
an on-line input-output front end for interface between
the 1107 and the traffic signal control and traffic
detection equipment.
Primary computer complex
The primary computer, which is used for control
and data processing functions, is a UNIVAC 1107
Central Processor equipped with:
1. A thin film control memory having a capacity
for 128 words of 36 bits each with an access
time of 300 nanoseconds.
2. A ferrite core memory having a capacity for
32,768 words of 36 bits each with an access time
of three micro-seconds. This can be enlarged to
accommodate 64,000 words, if necessary.
3. A real-time clock providing time resolution to
one millisecond and having interrupt capability.
4. Input-output capability for simultaneous transmission of 250,000 words per second over 16
in, or 16 out, channels.
5. Control console featuring a ten-character per
second buffered type printer and enter keyboard
along with 15 index, 16 arithmetic and 36
control registers.
Peripheral equipment directly associated with the
1107 comprises:
1. A magnetic drum memory having a capacity
for 4,700,000 alphanumerical characters with
a transfer rate of 360,000 characters per second.
2. Six magnetic tape handlers each providing a
recording density of 1,000 bits per inch with an
531
inter-block spacing of three-quarter inches and
tape speed of 100 inches per second, with a
transfer rate of 180,000 characters per second.
3. A high speed printer capable of providing
either single or multiple copies at a rate of 600
lines per minute with 128 characters per line.
4. A card reader with a capacity for 600 cards per
minute, each having 80 columns.
5. A card punch capable of producing an output
of 150 cards per minute, each having 80 columns.
Secondary computer complex
The secondary computer, which acts as the on-line
input-output device for the 1107 to which it is coupled
through a special inter-computer synchronizer, is a
modified UXIVAC 418 having:
1. A ferrite core memory for 16,384 words of 18
bits each which can be modified to give 8,192
words of 36 bits. In each case, the access time
is four microseconds.
2. Input-output capability over eight channel:s
for 18 bit, or four channels for 36 bit words.
3. Control console featuring a ten-character per
second buffered type printer and entry keyboard.
4. Input-output facilities using punched paper
tape, operating at a rate of 200 input or 110
output characters per second in six columns.
Operation
The basic function of the computer is to inspect each
individual signal once per second and to determine if
its aspect should be changed. This is done by comparing
the elapsed time for the current indication with that
time considered necessary to satisfy both the needs of
the alternating traffic flows and the system as a whole.
Control plan
To provide for predictable variations in the requirements (both at and between individual signals) and
to facilitate the implementation of special arrangements
(such as flashing operation) many different control
plans are available. They are maintained either in
memory or on drum depending on their frequency of
use. The plan actually in effect at any time may be
changed either manually by console type-in or automatically by time of day and/or volume criteria.
Traffic data file
The computer itself maintains a traffic data file
532
Spring Joint Computer Conference, 1969
which is continuously up-dated to show in one second
increments for each intersection or vehicle detector:
1. The elapsed time for the current interval.
2. The presence or absence of a vehicle on a
secondary detection.
:3. The occurrence of a pedestrian push button
actuation.
4. The number and duration, in :32nd of a second,
of the pulses coming from each primary detection.
The 1107 processes the raw data to give traffic
volume, speed and density over sampling periods of
any desired length. By using appropriate input parameters, estimates of delay, congestion, etc., can also
be arrived at; thus, a very complete picture of current
traffic conditions can be obtained.
Signal control
The control procedure governing the operation of
any signal and repeated continuously at intervals of
approximately one second, is as follows:
1. Read-in the Signal ~lonitor Code.
2. Ideiltify the current interval and note the time
fo,r which it has remained unchanged.
3. Check to ensure that the monitor code is valid.
4. If not valict, repeat check in three successive
scans. If still not valid, the signal will be dropped
from computer control and the operator notified by console print-out that this action has
been taken.
5. If the code is valid, check whether or not any
pre-emption is allowed or necessary. If so, set
the special function selector and terminate the
interval.
5. If no pre-emption is required, determine whether
the interval may be extended.
7. Determine the required interval length.
8. Issue the change order when the computed and
elapsed time equate.
Interval length
For a pre-determined mode of operation, the exact
length of all intervals will be specified in the parameter
list. However, for traffic responsive operation, only
minimum values will be given for those intervals whose
duration may vary. The need for extension beyond
these minimum values is detenuined by a special
computer sub-routine. A great many different time
determination procedures may be used. These may be
either for different signals, for the same signal at
different times of the day, or f-or different traffic
conditions. For any signal, the actual procedure to be
used at any instant will be specified by the control plan
in effect. In the general case, variations are only required
in the length of the nonnal green time. But, in certain
instances, the advanced green tim.e IP..ay also be made
responsive to traffic demand.
Where all signals operate independent of each other,
the length of the normal green indicstions can be
calculated in any way desired including predetermined,
semi-and fully-actuated and fully traffic-responsive.
There are very few signals of this nature in Metropolitan Toronto.
Where the operation of signals on a given street or
in an area must be co-ordinated to permit progressive
movement, the determination of interval lengths must
be made in accordance with modified routines designed
to accept the limits imposed by the required cycle and
offset relationship.
Pickup and dropout
With the computer correctly loaded with appropriate
programs, a manual type-in at the 1107 console engages
the pickup routine which automatically brings the
selected signals under computer control. If the field
equipment does not respond to the pickup instructions,
a fail message will be printed out and further attempts
at activation are made by direct manual instruction
from the operator.
Pickup occurs at each intersection as its timing dial
reaches the appropriate point. The whole system can
be under control in little more than two local cycles
which is never more than about three minutes.
A manual type-in terminates system control of
signals. A dropout routine is actuated and adjusts the
offsets of each group of related signals to a good otrpeak compromise which can then be provided by the
local timing dial. When the correct relationship has
been established, the timing dial is started by the
computer and operation continues without interruption. Following dropout, the operation of each signal
is monitored for approximately five minutes and any
deviation from normal is indicated by a console printout.
Accomplished in this way, dropout may take up
to fifteen minutes to complete, but the signals will
hold in the correct relationship for weeks if necessa..-ry,
Analysis
The computer can carry out a series of analytic
functions on a pre-determined schedule or on demand.
These include both on-line and off-line analysis.
Automatic Traffic Signal Control Systems
On-line analysis
Aspect changes at anyone signal or vehicular movement past anyone detector can be displayed on the
418 console as they occur. This provides useful information for service peIsonnel engaged in checking equipment. Aspect infOl'mation is available even when the
system is not under computer control.
A RECORD routine analyzes and prints out information from a.ny four signals together with a.ny sixteen
detectors to show, at one second intervals, actual clock
time, signal aspect, the number of vehicles passed
during the previous second, length of the pulse produced by the last vehicle, and the existence of congestion for each approach.
A SEKSOR routine is designed primarily for testing
the acceptability of detector information. Results are
printed out at fifteen minute intervals to provide an
inunediate record of traffic conditions and an indication of the need for servicing.
Off-line analysis
-,
Various routines are available for off-line analysis
of information stored on magnetic tape. These routines
can perform the following functions:
1. Print volumes, average pulse lengths, and lane
2.
3.
4.
5.
6.
7.
occupancy for individual detectors, or groups
of detectors, for any time interval from one
second to several hours, and for any combination
of days. The information can be presented in
numerical or graphical form.
Produce summaries of actual aspect timing on
a second by second, cycle by cycle or hourly
basis.
i
Draw space tme charls of co-ordinated arleries
on a second by second basis.
Simulate delays, stops, queue length, etc., for
one intersection based on the real vehicular
inpllt and actual signal aspects.
Calculate congestion for up to 200 approaches
individually and as a group.
Produce graphs of delay for a variety of offsets
and graphs of stops for a variety of offsets,
based on an average platoon arrival distribution
that is calculated from recorded data. The
computer also produces a figure of merit which
estimates the imporlance of co-ordinating a
parlicular link.
Produce volume figures which are corrected
for double lane counting losses so that computel
produced volumes are within ± 10 percent of
actual volumes.
533
After four or five months have elapsed, the detector
information contained on the original data tape on a
second by second hasis is averaged over 1;) minute intervals, to provide for long-term data storage and more convenient preparation of weekly, monthly or yearly
comparisons. One tape can hold a year of data in this
way. This compressed data tape may be analyzed at
any time to provide any required information except
that concerning signa] aspect. The original data tape
is normally cleared and re-used after six months, unless
some Court action is pending.
Performance
Area control
On almost every street there is, at some point, a
natural discontinuity for through traffic. On the other
hand, there are many areas in which signals are so
closely spaced or traffic conditions are so similar that
close co-ordination and a more or less identical mode of
operation is mandatory. Combining these two factors,
some sixty so-called Control Areas, each of which can be
considered as more or less independent unit, have been
created. Signals in these Control Areas can be operated
in any required way without reference to conditions in
adjacent areas. ~1any of these Control Areas include
signals in network formation, only those on a single
street, or those on a section of a major arterial route.
The Control Area concept has simplified programming, data handling and evaluation, while increasing
operational flexibility. Insofar as is practicable, both
the initial connection of signals into the system and all
future development work is carried out on a Control
Area basis.
Route control
To provide a thorough check on equipment and a
later basis for comparison, the initial operation of each
group of signals on a conunon street has been in a strict
pretimed progressive mode, using plans prepared by
the computer. A comparison between this mode of
operation and the previous non-coordinated arrangement shows a very distinct improvement. Over a large
area, travel time and the number of involuntary stops
decreased by an average of some eleven and forly-five
percent respectively. The average speed and number of
vehicles passing in a given time increased by some thirteen and ten percent respectively.
During the next stage of development, the same
predetermined plans were used. However, critical intersections were put in the TR2 traffic respoI13ive control
mode and area control parameters were selected on a
534
Spring Joint Computer Conference, 1969
volume basis as well as a time of day basis. The thinking
here is that any feedback control system must have an
inherent lag in response time in order to be stable.
Secondly, the time scale on which area control parameters are determined and implemented is quite large.
Thirdly, providing the appropriate area strategy, for
say the peak of the morning rush houI, creates small
problems if done too soon and creates large problems
if done too late.
Therefore, if the traffic responsive mechanism has
not ini tiated a particular rush hour plan by a certain time,
then that plan will automatically be implemented by
time of day.
This type of traffic responsive operation proved quite
successful in that the duration of peak hour congestion
was considerably reduced, though it was not eliminated,
while the increased· flexibility allowed the system to
automatically adjust for the variations in traffic demand
resulting from holidays, spOlting events, etc.
In periods of light traffic, one of the major problems
lay in the close spacing of many minor signalized intersections which prevented two-way progressive' movement at any reasonable speed. To overcome this problem, secondary detectors have been installed and a
number of these intersections operated in a semi-traffic
responsive mode. Their yield point has been determined
by the through street requirements and the minor street
use times. Another method used is to have several
minor signals operated in a flashing mode, with red
presented to the side street and amber to the major.
One hundred and fifty signals currently operate in such
a way at certain times of the evening.
Critical intersection control
TR2 control
To overcome uneven traffic flow at critic';}.l intersections, the proportion of green time allotted to either
phase can vary almost directly with instantaneous
demand, while retaining a fixed cycle length. It was
found that during pe9.k periods the average delay per
vehicle could be reduced by some twenty-seven percent.
TRI control
A very few major. arterial intersections are sufficiently
isolated that they cannot be considered as part of a
progressive system on either street. In these cases best
results have been obtained using an improved volume
density type of control. In these instances both cycle
length and split vary in accordance with the aJmost
instantaneous demand. With this type of operation, it
has been possible to reduce the averagE' delay per vehicle
to about thirty seconds, or ten percent, while handling
a peak volume equivalent to some fourteen hundred
vehicles per Jane, per hour of green.
With both these modes of controJ, it has been found
that serious trouble could develop if volume alone, or
volume and density alone, were used as the basis for
split variation. If, for any reason, congestion developed
on one approach and not on the others, in a given sampling period the detectors might indicate that the street
on which free flow was taking place was carrying the
larger volume and hence it would be given the larger
share of green time. This process could be cumulative
until the congested street is actually receiving its minimum allowable green in spite of its urgent need for more
time. To overcome this, a congestion identification
routine is used. This routine detects congestion by
an2lyzing pulse lengths and volumes. The routine provides compensation by artificially increasing the count
on the affected street, for TR2, and by ensuring a large
minimum green time for TRl.
Turning movement control
At a great many intersections where turning movements present a problem but are not sufficient to warrant a completely separate phase, conditionshave been
greatly improved by using a split phase arrangement.
In this arrangement the green for one direction comes
on in advance of that for the other. During this usually
short interval, the green for the favoured direction is
caused to flash rapidly, this alerts the drivers to its
presence and duration while, at the samr time, allowing
the feature to be omitted at any time without the need
for special signs. To provide for clearance and increased
safety, the flashing green is changed to a steady indication for about two seconds before the opposing direction is allowed to move.
It is hoped that this selection can shortly be made in
accordance with traffic demand at least at those intersections where separate turning lanes are provided and
detectors can be located to record the movement,
Accident control
A comparison 'was made of Police statistics for two
similar downtown sections of the City, each approximately two square miles in area with some ninety signalized intersections. It was shown that in one where
no change was made in signal operation, traffic accidents
increased by five and one-half percent over a two year
period, while in the system where control was introduced, there was an accident decrease of about seven
and one-half percent. A comparison of conditions on
three major arteries has shown that accidents have
Ant0111atic Traffic Signal Control Systems
decreased by some sixteen percent although the volume
of traffic has increased by some twelve percent.
Snow plans
It has been found that during even light snow, control
efficiency drops sharply simply because of the time required to start a vehicle on slippery pavement. (This is
especially true for any approaches on inclines.) On the
thcorJ that once movement has started it should be
allowed to continue for as long as is reasonable, special
plans have been designed to provide considerably longer
than norma.] signal intervals. Longer ambers are also
used with these plans.
Economic benefits
Given the amount of accident reduction that the computerized traffic control system has produced (some 10
to 15 percent), it can be safely projected that the system should be saving the citizens of Toronto and its
enviro~ some 172 million dollars a:rmually. This is based
on the fact that property damage from auto accidents
in Toronto runs to well over 15 million dollars annually.
The sa.vings from the increase in traffic flow has been
estimated at about 18 million dollars per annum, based
just on vehicle operating costs. If the personal time
saved could be estimated in dollars, this figure would
increase dramatically. Thus, we have a community
savings of some 20 mil1lion dollars per year ona capital
outlay of only five million dollars for the total system.
When the computer was moved recently from the
535
old City Hall to the new Police Headquarters, Toronto
residents found themselves caught up in a three-week
traffic jam since the lights were on their own automatic
controls. ::\Iotorists were warned of the move and cautioned to leave for work earlier than usual. Once the
Computer System, that hae reduced traffic tie-ups by
20 percent was no longer controlling the traffic lights,
motorists found that in some cases they needed up to
an extra hour to get to work. The earlier system predictions of the saving of some 9,000 vehicles hours of
delay per day proved to be a gross understatement during those hectic weeks.
ACKXOvVLEDG.:.UEXT
::\'fuch of this report is based upon the efforts and
documentation of .J. T. Hewton, ::\Ietro-Toronto
Traffic Control Center, Senior Operations Engineer
from 1963 to .January 1968,
REFERENCES
A
CHRISTEXSE~
R B CODY
Jlethods of traffic signal control with on electrON compllter
Traffic Research Corporation
:2 KCS LIMITED
it centrally-controlled traffic signal s,l/stem for
metropolitan Toronto
;3 TRAFFIC RESEARCH CORPORATIOX
The control of traffic signals in nwtropoWon Toronto with
an electronic comp'uter
4 D \VHITEHEAD
The Toronto system: Intersection evaluation and control
Metropolitan Toronto Roads and Traffie Department
A panel session-Education of computer professional
ELLIOTT I. ORGANICK, Chairman of Session
University of Houston; currently at
Massachusetts Institute of Technology
Cambridge, Massachusetts
Inter-relating hardware ·and software in
computer science education
by JACK B. DENNIS
Massachusetts Institute of Technology
Cambridge. Massachusetts
The major portion of graduates from curricula in
computer science will be professionally involved in the
design, specification, implementation or theoretical
foundations of computer-based information systems.
They will participate in the selection of computer
hardware, or will be called on to judge the merits of
proposals from suppliers. To be competent in exercising
these responsibilities, it is essential that students of
computer science thoroughly understand the relationship between computer organization and the implementation of programming languages and information
systems.
Given this objective, there is a serious anachronism
in the teaching of programming and computer organization in contemporary university curricula: Computer
organization is often taught as the final example in a
course on logical design by instructors who do not
profess knowledge of compiling techniques and software
issues. Conversely, programming courses are based on
conventional assumptions of computer organization
(Von Neuman) as if they were axioms of nature.
Moreover, the communication paths that could lead to
reorganization and accommodation of the intellectual
substance of both areas are frequently blocked by
circumstances: Either the areas are the "property" of
separate academic departments, or the faculty is
divided by disparate interests.
There is critical need for cooperation between faculty
in programming and in computer organization to jointly
develop curricula that interrelate hardware and software
principles for realizing the functional requirements of
computer systems. The ACM Curriculum Proposal does
not represent sufficient progress toward this objective.
In the undergraduate Computer Science program of
the M.l. T. Department of Electrical Engineering, we
have developed a three subject sequence in computer
systems and programming intended to interrelate
software and hardware principles:
1. Programming Linguistics
2. Computation Structures
3. Information Systems
Students enrolling in the sequence are presumed to have
had the experience of expressing programs in an
algebraic language and seeing them run (with success
and failure) at a computer installation.
The first subject, "Programming Linguistics," treats
the important concepts in describing. and interpreting
algorithmic procedures on the basis of a formal semantic
theory. Features of practical programming languages
are related to the theory. Discussion of hardware is
deliberately omitted so an unencumbered appreciation
of linguistic principles can be achieved.
In "Computation Structures" the student learns the
properties of memory and logic components that
interact strongly with the process of planning a computer organization. A graph model of parallel computations is used both to describe modular hardware systems,
and, as a starting point for developing combined
537
538
Spring Joint Computer Conference, 1969
hardware and programming techniques, for realizing
the linguistic features studied in the first course.
The subject "Information Systems" makes use of the
material from the preceding subjects in studying the
analysis, design and implementation of computer-based
informations systems.
The second subject of this sequence is the key to
inter-relating hardware and software concepts. A significant difference from conventlonal curricula is that
students begin in their study of "Computation Structures" with a thorough. understanding of the features
found in a variety of source programming languages.
With this background they are prepared to study the
principles by which these features may be made
available to computer users through the combination of
hardware technology and programming concepts. An
outline of this subject as it is currently taught at
M.I.T. is given below.
Computa;tion structures
Join and quit primitives; Dijkstra semaphoresthe pes) and yes) operations. Process interlocking
problems and their resolution.
6. Nesting and Recursion: Representation of an
operator of one schema by a second schema.
Naming of input and output quantities. Occurrence of multiple activations of a procedure
through parallelism or recursion. Local data
areas; use of stack storage allocation for single
process implementation; base registers.
7. Information Structures: An information structure is modelled as a directed graph, without
directed cycles, containing a directed path (not
necessarily unique) to each node from a particular node called the root. Static operations on
information structures; implementation by use
of indexing. Dynamic operations; implementation by linked blocks in a location-addressed
memory; garbage collection; implementation
with associative memory.
1. Logic Design: Elementary combinational circuit
2.
3.
4.
5.
synthesis; registers and gating; asynchronous
modular systems (macromodules); sequential
circuit synthesis; elementary implementation of
arithmetic operations.
Memory Systems: Physical principles; name
space-value space; distinction between locationaddressed and associative memories; addressing
by key transformation for associative retrieval.
Computation Schemata: Representation of a
computation (in digital logic or as an abstract
algorithm) by a set of operators that transform
the contents of a set of memory celis. The domain
and range cells of the operators are indicated by
a data flow graph. The constraints that govern
the sequencing of operator applications are
specified by a precedence graph. Necessary and
sufficient conditions for deterministic (unambiguous) operation are formulated. Extensions
are made to represent procedures involving
decision and iteration.
11achine Organization: Study of the principal
forms of single-sequence processor organization
and the corresponding techniques for compiling
arithmetic assignments and conditional expressions: A simple single address machine; a
stack·{)rgapized machine; macbines having multiple general registers; machines having several
functional units.
Parallel Processing: Multiprocess computer
systems; process state, supervisor programs and
scheduling; primitive procedure steps for representation of parallel computations: The fork,
Let's not discriminate against good work
in design or experimentation
by GEORGE E. FORSYTHE
Stanford University
Stanford. California
I am distressed that graduate education in computer
science is forcing students into a theoretical mold, and
away from the vital practical problems of software
engineering, I therefore urge that graduate computer
science departments pay attention to the problems of
experimentation and design in computer science. This
might be done, for example, by employing faculty with
interests in design and experimentation, by offering
courses and examinations in these areas, and/or by
accepting Ph.D. dissertations involving substantial
designs or experiments of high quality. I believe that
the last is the most important action to be taken now.
I t seems to me that one main function of an educational system is to furnish society with imaginative
performers and potential leaders in all the various areas
of life. Within the computing field, there is a huge need
for persons to create well designed, well documented
software systems that exploit computers in the manifold
ways we know to be possible. While the field will surely
be advanced farthest by the creation of good new ideas,
there remain enormous steps to be taken in exploiting
Education of Computer Professional
ideas already known. Thus our educational system in
computing should do three things:
1. teach the leading ideas now believed to be
relevant to computing, and inspire students with
the desire to keep on learning after they graduate;
2. seek out and inspire a few leading minds capable
of augmenting our stock of ideas 'with good new
ones and show them how to do it;
3. inspire a generation of students to design and
e;Periment with good systems with the ~ethods
now known and soon to be discovered, and show
these students how to do a good job of it.
By accepted custom, the Ph.D. degree requires the
student to perform in steps (1) and (2): he passes
examinations in relevant ideas, and he writes a dissertation whose main requirement is to contain some
original theoretical work. I believe these two steps are
entirely correct for a Ph.D. in a theoretical subject like
pure mathematics.
But the very point of founding schools of engineering
and departments of computer science was that society
needs concentration on work relevant to today's
technology. This implies a certain abandonment of
learning for learning's sake, in favor of work on problems
whose solution is actually needed. In the computing
field, this implies to me that we must not confine our
students to Ph.D. dissertations that are of the classical
type, but should be prepared also to accept first class
work in design or experimentation.
Students are attracted to computer science because it
has a lot of action, rather than just contemplation. From
the start, our students are creating programs that do
things, and they enjoy it. Many of them are eager to keep
on designing and programming systems, and it seems
almost criminal to tum this eagerness off. Instead, our
graduate departments should be accepting this urge to
produce, and concentrating on channeling the design,
experimentation, and production into worthwhile
projects, done with high standards.
It has been argued that design and experimental work
are fine, but should be rewarded with a different
degree-one analogous to the degrees of Engineer or
Doctor of Arts. I disagree, mainly because different
degrees tend to acquire different levels in the hierarchy
of snobbery, and I refuse to admit that excellent work
in design is any less important than excellent work in
theory. The Ph.D. degree has become the accepted
reward for first class performance in graduate school
(e.g., in experimental physics), and should be retained
in that function. Any further assessment of the quality
of a person's work can be passed along in personal
letters of recommendation. If my recommendations
539
were followed, I would expect to see more Ph.D. theses
with titles like
"A very high-performance compiler for PL/1 on
System/360" ;
"Study of all calls on the scientific subroutines
on the CDC 6600 at NYU in October 1969, and a
resulting proposal for reorganizing the library."
In summary, the purpose of our educational establishment is to reward students for developing their educational and performance potential as much as they can.
Let us use the Ph.D. as a reward for first class work in
any aspect of our field, and not discriminate against
work in design or experimentation.
Applied computer science
by LOTFI ZADEH
University of California
Berkeley, California
It is a truism that we are in the throes of an information revolution of which one obvious manifestation is a
very rapid growth in the number of users of computers
and computer-like information processing systems.
It is also evident that the number of computer users
is growing much more rapidly than the number of
computer scientists and engineers. As a result, computer
science may become user-influenced to a much greater
extent than other fields of science and engineering. This
was in evidence at the .1968 IFIP Congress in Edinburgh, at which the ratio of non-professional users to
computer scientists was far greater than, say, the ratio
of non-mathematicians to mathematicians at the 1966
International ::\Iathematical Congress in ::\1oscow.
The overwhelming preponderance of computer user~
over computer specialists is certain to have a profound
impact on computer science education in the years
ahead. One likely effect is that much of the training in
the use of computers will be taking plaee outside of
computer science departments and will be tailored to
the needs of students in particular fields. Another
possible effect is a splitting of computer science into
pure computer science and "applied" computer science
a la the division of mathematics into its pure and
applied branches.
If one believes, as this panelist does, that an organiza-
540
Spring Joint Computer Conference, 1969
tional fractionation of computer science into "pure" and
"applied" components is undesirable, then greater
attention will have to be devoted to making it possible
for a computer professional to receive a Ph.D. or
equivalent degree on the basis of a thesis that is
primarily applied in nature. By this is meant a thesis
which contributes not to computer science per se but to
a nontrivial application of it in some field external to
computer science. For example, an acceptable Ph.D.
thesis of this nature might deal with the application of
computers to medical diagnosis; or to problems in air
traffic control; or to simulation of neural nets, etc.
It is essential that a student electing to do his
dissertation in an applied field should devote a substantial amount of time to familiarizing himself with it.
Thus, if his thesis is concerned with, say, the medical
diagnosis by computer, he should be prepared to spend a
month or two in a hospital acquainting himself with
various aspects of medical diagnostics. The Ph.D.
dissertation of G. A. Gorry* of Project ::\'IAC, ::\I.I.T.,
is an excellent example of a thesis of this type.
In summary, although one can find isolated examples
of Ph.D. theses in what might be called "applied"
computer science in various institutions, this panelist
believes that a conscious effort should be made to
encourage work of this type within computer science
and electrical engineering departments and accord it the
same respectability as research in pure computer
science.
Identifying and developing curricula in
software engineering
by ALAN J. PERLIS
Carnegie-Mellon University
Pittsburgh, Pennsylvania
One basis for developing an education program is the
recognition of a continuing need for a certain class of
professionals in our society. The need may be redressed
because:
An influential or significant part of the society may
have a need for professionals that is not being met by
the educational system.
An influential or significant part within the education
system may observe an unrecognized need of society
and begin to prepare what will eventually be needed.
* G. A. Garry, "A System for Computer-Aided Diagnosis,"
September 1967, MAC-TR-44.
The educational system may not respond to external
pressures because it sees the need as temporary or
non-critical, or it just may not be interested in such
problems. The educational system may say it hasn't the
resources to provide the professionals or settle for a
merely adequate solution. It may even delay solving the
problem by an act of generalization or systematization
that, at best, functions to postpone.
The present graduate programs of computer science
arose from the second process. As a result th~re is an
aspect of computer education that is not being provided
in response to a situation of the first kind. I refer of
course to the education of a class of people that I shall
call software engineers whose training and goals are
quite different from those of our current computer
scientists.
These badly needed people are engineers and their
domain of specialization is software-its design, production, and servicing, Actually this is too restricted a
view: Their specialization is computerware, both hard
and soft. Actually they deal with a spectrum of st~;\tes
of computer matter each stable only in certain
environments.
It requires little insight or sleuthing to see that such
engineers are in very short supply and the need for them
is acute. Accepting this state of affairs, certain questions
need to he put and then to be answered by the educators
and the employers of such people.
1. Should training be conducted in the university
or in technical or trade or junior college schools
or indeed in all?
2. If in a university, in what department or
discipline or school should it be conducted?
3. If in a department or interdisciplinary program,
at what levels should degree programs be offered
and in what order of priority?
4. Do these programs exist in the steady state as a
separate discipline or as a minor or option or
modification of existing ones?
5. Is the need going to persist and, if so, will it
persist in its present form? Will the people be
educated for the coming generations of systems
problems?
6. Why do we speak of engineering and not
science?
I t is here suggested that the proper place to start is at
the master's level. From that program one can move up
to the doctoral and down to the bachelor's programs.
The master's program should not be a faceless one
turning out computer scientists whose grasp and reach
could not attain the computer science doctoral degree.
The engineering component of this education is
Education of Computer Professional
paramount. The goal should be concentration on known
tools and their effective use and not on periods of
intense innovation or discovery. The choice from
competing designs is more important than the discovery
of the existence of designs. The issue of stability is more
critical than that of growth and change. The determination of task magnitude is as important as the discovery
of method. The directing of teams is as critical as the
spark of breakthrough. The professional accomplishment of mean tasks that are of peripheral importance to
the society are distinct from the devotion only to the
bizarre, rare and new.
At the moment there are few studies being made
of the problems of training these people. Rather than
reproduce a curriculum here, I should like to list
questions that a trained engineer should be able to
answer:
1. Given a software task, similar to familiar ones,
and a set of computers, evaluate the machines
and the task to make a meaningful choice of
machine and representation of the software
system that is optimal. HoI What is optimal?
How relevant are the issues of manufacturer
support? Compatability? Stability? X atural
gradients for change, growth, and improvement?
2. Given a software task, what is a rational
schedule for its completion given various person-
3.
4.
5.
6.
7.
8.
;341
nel situations? How do you get, train, or even
recognize adequate programmers? Hmv do you
set up work loads?
If n people are programming a system, what do
you do when the n + 1st arrives, etc. ?
How do you test t3, system? What kind of a
system do you organize to handle and respond to
pressures on a system?
Hmv do you market a system? What makes a
system useful'? How do you copy someone else's
system?
How and what do you learn from building a
system? vVhat goes into the inventory stockpile
after spending time on a software task?
What are the tools of the trade? How are they
catalogued? Related to diverse hardware?
How do you tie together disjointed systems into
coupled ones solving enlarged tasks?
I look upon the professional education of software
engineers as an amalgam of mathematics, management
science, computer science and practical experience
gained from contact with actual software systems and
associated problems.
Some of the master's may continue onto the doctorate
in computer science, but the program is not seen as
being merely preparation for a doctorate in computer
science.
SAL-Systems Assembly Languages
by CHARLES A. LANG
University Mathematical Laboratory
Cambridge, England
INTRODUCTIOl\
state clearly the computing operations he wants performed; further, the program must be clear to read
both by himself and others. A high level language such
as FORTRAX, ALGOL or AED meets these requirements better than assembly code, but these languages
fail to meet the other requirements discussed below.
The Cambridge Computer-Aided Design group is
writing some general purpose software tools that aim to
assist scientists and engineers to apply their problems to
the computer with maximum ease. These tools include
a storage allocation system, a data structure package, a
compiler-compiler for mixed graphical/verbal on-line
languages, a package of procedures for generating pictures and transmitting them to a display, plotter, or
file, and programs for operating a link between a multiaGcess computer and a satellite computer. When the
group started late ,in 1965 it had to determine what
language to use to write these systems. After struggling
with the difficulties of assembly code for some time for
those programs for which FORTRAN was unsuitable,
we decided to design and implement a more suitable
language; Systems Assembly Language (SAL) is the
result. The purpose of this article is to explain the thinking behind SAL rather than to expound on the finer
details of the language itself. We feel that this type of
language which combines the freedom and flexibility of
assembly code with many of the facilities normally associated with high level languages, could be useful to
many other workers. Further, this type of language
could perhaps usefully be provided on all computers.
Effectiveness
The language itself must be easy to learn (a short
programming manual is desirable), and capable of being
compiled efficiently to produce efficient code. These
requirements must not be achieved at the expense of the
language's generality or practicability. The target is a
high "power to complexity" ratio, the view being taken
that if the basic operations provided by the language are
well chosen, then these provide the tools with which the
programmer may fashion more complicated and specialized operations. We have tried to achieve this by making
the syntax of SAL very general, avoiding exceptions and
special cases as far as possible. Also as much as possible
has been left out of the language rather than the reverse. For example, a stack is frequently used in -system
programs, so at first we planned facilities to set up, operate and destroy stacks. Later, however, we abandoned
this idea as we realized that the kind of stack we were
planning (a first-in, first-out stack which stacked single
computer words), might not be the type of stack required by all. Furthermore, such a stack could very
readily be programmed using other features of the language. To build in the generality for all possible forms
of stack would have been too complicated for this type
of language. We have met our target of producing the
compiler, documenting it and writing a programming
manuaP in a single man-year. None of the contending
languages available in our laboratory, FORTRAN,
ALGOL, and CPL meet the above requirements; they
were, of course, never intended for use primarily as
languages for writing system programs.
Design requirements for SAL
The design of a programming language is a compromise between various requirements; the requirements
for SAL are now discussed.
Clarity
A programming language provides the conceptual
framework within which a programmer must think
about his problem, so influencing his method of solution. The language should enable the programmer to
543
544
Spring Joint Computer Conference, 1969
There exists a whole spectrum of languages starting
with assembly code at the lower end, then higher level
machine dependent languages, then higher level machine independent languages, and eventually reaching
the highest level ones such as P AL2. To put SAL in perspective it comes somewhere inbetween a simple machine independent language such as BCPL3, and a machine dependent language like PL3604 , both of these
languages being intended for writing compilers and
systems. In PL360 assembly code type instructions are
written together with ALGOL-like declarations, iterative and conditional statements and a block structure.
SAL contains several high level facilities not available
in PL360, so is roughly parallel in the spectrum with
YIOL940,5 a language for the SDS 940 which "permits
the expression of clear, co~cise algorithms and the production of efficient tight code".
Suitability for writing system programs and
machine dependence
The language must contain basic features required
for writing system programs. In particular, these include
explicit address manipulation, data structures, control
of iterative and conditional operations, bit manipulations, character manipulations, arithmetic and logical
operations, intercommunication between separate program modules (perhaps written in different languages),
cont.rol of peripherals, and the ability to separate program and data (so that a single copy of a program may
be shared in a multi-programmed environment). SAL
attempts to provide these facilities as described in a
later section, though it is not currently strong on character manipulations.
While we applaud machine independent progra.mming
wherever possible, we recognize that there are times,
even if very few, when machine dependent programming
is desirable, for example when very high efficiency is
essential, or intimate control is required over the machine such as in the control of peripherals, or loading of
machine registers. SAL caters for this machine dependence in two ways. First, machine registers may
be referred to in any arithmetic, logical or conditional expression. Second, assembly code may be
embedded quite freely anywhere in a SAL program
and may refer directly to declared variables. This
permits easy communication between the assembly
code and the rest of the program. This feature was
specified in the ALGOL 60 report6 and has been included in many implementations of ALGOL and FORTRAN and also in AED.7 Both PL360 and ::VIOL940
include both of these features.
No run-time system
The language must have no run-time system of any
kind. That is, nothing shall be loaded along with the
program "behind the users' back", such as an input/
output package, or run-time routines to operate stacks
or dynamic use of working space. In this sense, SAL is
like a conventional assembly language. This requirement allows SAL to be used to write any type of system,
leaving the programmer quite free to control everything loaded into the core along with his system program. Further, the consequence of each statement
should be clear to the programmer.
Ability to run together programs written in
different languages
The general purpose system programs we write are
intended to be used as tools by other programmers for
particular applications. Despite the many attempts, no
programming language has yet been devised which is
suitable for all programming tasks. Apart from this the
more comprehensive a language becomes the more unwieldy the compiler and system that goes along with it
tends to become also. The user of the tools must not be
forced to write his own application programs in the same
language as used to write the tools. Rather, he should be
free to write his programs in whatever language is most
suitable for his application. This means that SAL programs must run within some mixed language system
where programs written in separate languages may be
compiled separately but loaded and run together. Many
such systems exist, but often the methods used for interlanguage communication (which are a function of the
loading system as well as the languages) are limited to
the FORTRAN requirement. This provides one way of
calling procedures and passing arguments, plus communication via "COMMON." As a result of these restrictions, some languages, notably ALGOL, are not included in a mixed language system. The same loader,
however, is sometimes used to load into core the compiled code of these languages, and of languages within
such a mixed language system. A further requirement
is that a SAL program must have equal freedom to assembly code programs, to communicate with programs
written in any language that may be loaded into core
with a SAL program by the same loader.
Examples of mixed language systems are the Projject MAC system on the IBM 7094 where assembly
code, FORTRAN, MAD, AED, etc., programs may be
loaded together, or the SCOPE system on the CDC
6600. The system at Cambridge is known as The Mixed
Language System (:MLS) and will be referred to later.
SAL
The language
The language description is divided into t,vo sections.
First there is an example, rich \vith comments, that
uses many features of the language. Second, the unusual
or special features of the language are described. The
syntax is listed in the appendix. SAL is designed for the
Titan (Atlas II) computer, which has a 48-bit word.
Floating point operations use the single 48-bit accumulator. There are 128 index registers (called R-lines) of
24 bits each. All integer arithmetic is performed on
half-words (24 bits) using the index registers as accumulators.
Examples of SAL programs
The following examples show what a SAL program
looks like. An attempt has been made to use as many of
the facilities of the language as possible rather than to
write the most succinct program. These examples, in
conjunction with the syntax of SAL in the appendix,
attempt to convey eoncisely the facilities of SAL. Only
the more unusual facilities are descrihed in more detail
in the sections below.
Program 1 generates a picture of a cubic and transmits it to a satellite computer 'with a display. Program
2 is a group of procedures which may be used to
generate a picture consisting of Hnes and points for the
Digital Equipment Corporation PDP7/340. Roth programs are highly annotated, comments being introduced by a bar (/) and terminated by a bar, semi-colon or
newline. They have been tested and proved to work.
It is suggested that readers take a first quick look at the
program example here. They should not, hO\vever, expect to understand the details until they have finished
reading this paper.
PROORAM 1
Imain program to plot e cUbio on the d1sp 1 eY
GLOBAL LABEL BUFFER,POINT,LINE,SEND lentry pOints to procedures
lin program 2
GLOBAL LABEL START lentry point to this main program
INTEGER X,XTHIs,YTHIs,XLAST,YLAST,WSPACE(15),DFILE(1&e)
SLINE 2 ARGl,ARG2,ARG3 9& LINK
Iset up variable space for pure procedures
GLOBAL LABEL DUMP
START, S77-PTR WSPACE(9)
OSELECT &
loutput stream se1ecteO for me •• ages
X-1
Iset up buffer for display file
ARGI-PTR DFILE(t)I ARG2-1&&, ARG3-0FERROR,
LINK-MAINl, GOTO ~UFFER,
MAIN1,
Iplot a po1nt at &,41 ARGI-a, ARG2a4,
LINK-MAIN2, GOTO POINT
MAIN2, XLAST-e, YLAST-4
LOOP,
WHILE X<11 DO
XTHIS-X*le, YTHIS-X*(X*(X-2)+3)+4
ARGI-XTHIS-XLAST, ARG2-YTHIS-YLAST
X-X+1
X~AST-XTHIS, YLAST-YTHIS
LINK-LOOP
GOTO LINE
REPEAT
Isend display file to tne satellite
LINK-DONE, GOTO SEND
DONE,
OSTRING IIDISPLAY FILE TRANSMITT~O
II,
STOP
DFERROR,
uSTRING •• DISPLAY FILE OVERFLOW
II,
STOP
FINISH
546
Spring Joint Computer Conference, 1969
PROORAM 2
idispiay file system
Ithis routine contains procedures bUffer,point,11ne,send
Ithe procedures are written as pure prooedures, so Use external
Ivariables rather than global, local, or common variables
larguments are passed to the procedures bY value in index registers
IB2,B3 •••••• etc, and the result, if any, 1s returned 1n ~l.
Ion entry to the procedYre the return addreSs is 1n age
BUFFE~,POINT,~INE,3END ientry pOints to procedures
RELSTART INTEGER a77 e
INTEGeR 877 DFLOC,DFOVER,DFNEXT,DFEND,~ODE,NEXTrtOD,TEMP
BLINE 2 ARG1,ARG2,ARG3 9& LINK lmnemonic na~es for index registers
GLOBAL LABEL
iset up manifest constants
PARWD IS 014117, XCOrt IS 022&&0, YCOM IS 0222eee
OXYCOM IS 02eee3e~, ENDCOM IS 0492eee, HA~F IS 04
IbUffer(dfloo,dfsize,dfover)
Iprooedure buffer is called to set up a bUffer at address dtloc
land size dfs1Ze in whioh the display file is to De built, one word
lof dlsplay file per half word. 1f 1t overflo~s exit from cuffer
lis made to address dfover
BUFFER,
IpicK up first argument
idfend marks ena ot display file buffer
DF~OC-ARGl
DFEND~ArtG2+ARGl
DFOVERaARG3
If1rst word in the display f1le is parameter
Imode, setting scale,1ntensity anj light pen sensitivity
MODE-PAR
'mode of last word 1n tile is parameter
DFNEXTcDF~JC+HALF Idfnext marks the next free buffer location
GOTO LI~K
I return to call1ng program
~DFLOCzPAR~n
Ipoint(x,y)
Iprocedure point adds two commandB to the ~l.play file to set x ana Y
Ix and y must be positive and leas then lea4
INTEGER B77 COORD, RETURN
POINT,
I set d1spaly file to recelve polnt mo:!e word.
RETURN-POINTl, NEXTMUO-PO,
GOTO MODE
POINT1,
Icheck to see if therei. apace 1n t~e at.Play file buffer
IF OFNEXT+l GE DFENO THEN GOTO OFOVE~ END
COORO-ARGl AND 1&23
COORO=COORD SHIFTRC 3
~OFNEXT-XCOM+COJRO
Ix polnt comman4
DFNEXT-OFNEXT+HALF
COOROaAHG2 AND 1&23
COORD-COORD SHIFTRC 3
~OFNEXT·YCaM+COJRO
Iy polnt command
DFNEXT-DFNEXT+HALF
GOTO LINK
Ireturn
SAL
Iline(delx,dely)
Iline adds words to the display file to generate lines.
Idelx and dely may be in the range -le24127*N DO N-N+l, REPEAt
INCRX=DE~X/N,
INCRY-OELY/N
REMX-DELX-INCRX*NJ
REMY-DE~Y-INCRY*~
Ibuild display file commands
IF OFNEXT+N/2
IN/2 as each command occupies a nalf wordl
GE DFEND TnEN GOTO OFOVBR END
RETURN=LIN~l,
NEXTMOO-VEC,
GOTO MODE
LINE1, FOR N-N STep -1 UNTIL 1 DO
DEL.X-INCRX
IF REM X GT e THgN REnX-R£MX-l, D~LX·DELX+1 END
IF ARGl LT & TH~N DELX-DELX AND 02eee END Ineg bit
DE~Y·INCRY
IF REMY GT e TH£N REMY=REMY-l, D~LY-DELY+l END
IF ARG2 LT & THeN DELY=DELY AND 02e&e END Ineg bit
D!~Y-DELY
SHIFTLC 8
~DFNEXT-DXYCOH+DELX+DELY
SHIFTRC 3
DFNEXT-DFNEXT+HALF
~~tNEXT.~DFNEXT
REPEAT
GOTO LINK
lend of procedure !1ne
Iprocedure send transmits the display file to the satellite
SEND,
Iclose off disRlay f11e
IF DFNEXT+l GE DFEND THEN GOTO DrOVER END
RETURN-SENul, NEXTMOo-SUa, GOTO MODE
SENDl, ~DFNEXT-ENDCOft, DF~EXT-ufNEXT+HALF
ble~DFNEXT-DFLOC
Inumber oft words
Bll-2eee
laddress in satel11te
d12-e
IData word for satellite
B13 a OFLOC
1811
a
e
~
'select link to satel11te
le13
1&
13
e
Isend display file
GOTO LINK
ICO~P HOD 9,016&e&&,18
Iparameter word
INTEGER 877 MODNijM
PAR,
IF NEXTMOD-PAR THEN GOTO RETURN END
Iset up mode change in previous word
PARI,
IF NEXTMUDcPO THEN MQONUM-1 ELSE
IF HEXTMOD-veC THEN KODNUM-4 ELSE KOuNUK-7 END END
MOD(DFNE~T-HALF)-KODNUM
hODE-HEXTMOD, GJTO RETURN
547
548
Spring Joint Computer Conference, 1969
Ipoint mode
PO,
IF NEXTMOD~PO THEN GOTG RETURN EUD
J
GOTO PARl
Iveotor mode
Ivector mode words are treated differently. They must
Ifirst escape into parameter mode by addition of a single bit,
Ithen a whole new parameter word with the required mode ohange
I must be added to the display file
VEe,
IF NEXTrtODzVEC THEN GOTO RETURN END
·(DFNEXT-HALf')c~(DFNEXT-HALF)
OR 04ee&ee 'add escape bit
IF DFNEXT BO DFEND THEN GOTO OFOVER ENO
·DFNEXTz~
iset null parameter word
DFNEXT-DFNBXT+HALF
GOTO PARl
Isubroutine mode
SUB,
GOTO PARl
FINISH
Special features of the language
Sections of program ending with the word FINISH
are known as routines. A routine may itself contain
several procedures. Note that statements may be terminated either by a semi-colon or by a newline.
Declarations, control of space, and intercommunication between programs
Particular attention has been given to the ability to
write pure procedures, i.e., separation of code and data,
control of data space, and communication between programs, whatever language they may be written in.
Variables may be declared in different data spaces as
explained below. Most operations in SAL are carried
out with 24-bit words, called half-words in Titan terminology. Variables may be declared either as type
INTEGER (for want of a better name) or as type
LABEL. This paucity of types simplifies the compilation process, and gives the programmer more flexibility,
as he can assign any conceptual type (integer number,
logical, string, character, list head etc.) to an integer
variable and mix these conceptual types in arrays and
other forms of data structure. Integer variables may be
declared in several ways as discussed below. A special
feature of SAL is that labels may be mixed with integer
variables in arithmetic and logical expressions (see
next section).
NQ floating point operations are provided in SAL
except by using embedded assembly code. REAL variables may be declared (distinct from integer variables
as they are 48-bit numbers) for use with this embedded
assembly code as well as for communicating with FORTRAN programs.
Local Integer Variables
e.g., INTEGER X, XTHIS, YTHIS
These variables are local to the routine in Which they
are declared. Space is assigned for them by the compiler
at the end of the code of the routine. Consequently, the
local integer variables of separate routines do not share
the same space in core.
Global Variables
e.g., GLOBAL INTEGER RED, WHITE, BLUE
Global integer variables allow for communication between separate routines.
e.g., if routine A declared:
GLOBAL INTEGER RED, WHITE, BLUE
and routine B declared:
GLOBAL INTEGER GREEN, RED
then both routines may reference the same variable
RED. Space for global integer variables is allocated by
the loader at load time.
External Integer Variables
External integer variables provid three facilities: the
ability to write re-entrant code, dynamic allocation of
space, and a further method of communication between
routines. These variables are not referenced directly,
but relative to an address held in an index register. It is
the programmer's responsibility to store in an index
register the address of some space that is to be used for
the variables.
SAL
three of which are:
INTEGER B77 DFLOC, DFOVER, DFXEXT
Before such a declaration is made, however, the user
Program 2, for example, uses index register 77, and
declares several external integer variables, the first
must declare where, relative to the address in the index
register the variables are to be allocated:
e.g., RELSTART INTEGER B77 0
This allows variables for different routines, referenced
relative to the address in the same index register to be
separated. For example, another routine might make
the declaration:
RELSTART INTEGER B77 7
549
identical in each section of program (the address of an
area in core for use by these variables) then P, Q,R
would use identical locations to OAK, ASH, EL::\1.
Finally, routines may communicate via external
integer variables. For example, if two routines both
declared:
RELSTART INTEGER B25 0
INTEGER B25 P,Q,R,S
then P ,Q,R,S would be accessible to both routines.
Index register 25 could be set up by either of these
routines, or another one.
Index Registers
The space used by the external integer variables in Program 2 is set up in Program 1 by the statement:
Index registers may be referred to by giving their
number prefixed by B, for example, B2, B3, B4, B90, or
they may be referred to symbolically by making a declaration:
B77 = PTR WSPACE(O) (PTR is explained
in next section)
e.g., BLINE 2 ARGI, ARG2, ARG3 90 LINK
N ow let us consider the three facilities mentioned
above, starting with re-entrant code. As external integer
variables are r~ferenced relative to an address in
an index register, a new set of variables may be
referenced by changing this address. The Titan operating system is multi-programmed, and saves and restores index registers for each program when switching
between programs. Hence, several users may share the
same program, each one setting up the same index register to contain the address of space to be used by the
variables. Single users too may have requirements for
re-entrant code to implement recursive procedures, or
to handle program traps (for example from the satellite
computer). In this single user case, it is the user's responsibility to ensure that the address in the index
register is set up before re-entering some code.
External integer variables also provide a method,
under user control, to dynamically allocate space, producing an effect similar to that provided automatically by some block structured languages. Suppose, for example, there was declared in one section of code:
RELSTARTINTEGER B250
INTEGER B25 P,Q,R,S
and in another:
RELSTARTINTEGER B250
INTEGER B25 OAK, ASH, ELlVl
then assuming that the content of index register 25 was
This declaration makes ARGI, ARG2, ARG3 equivalent to B2, B3, B4 and LINK equivalent to B90.
Common Variables
Common variables are included in SAL purely to
permit communication with routines written in FORTRAN:
e.g.,
CO~VEvl0N
/SHAPES/ ROUND, SQUARE
The name between the / / enables named common to be
referred to for communication with FORTRAN IV
programs.
Arrays
Single dimensional arrays are declared by giving the
size of the array after the name:
e.g., INTEGER YLAST, WSPACE(05) , DFILE(lOO)
INTEGER B27 A, B(50), C(50)
GLOBAL INTEGER D,E,F,G(IOOO)
COMMON jSHAPEj PENTAGON(5)
Space for arrays is allocated in the same way as for
single variables. Local integer arrays are assigned by the
compiler at the end of the routine, the user must set up
the space for external integer arrays, and the loader
assigns the space for global integer arrays, as it does for
common integer arrays which are actually assigned
within the common area.
550
Spring Joint Computer Conference, 1969
e.g., -7 ( -7A) = -7 (B
Reals
Real variables may be declared for use with embedded
machine code, and as arguments when calling FORTRAN procedures (see section on procedures), by the
declaration:
e.g., REAL NUMBER, RESULT
-7 X =
-7 (
+ 2 * C)
-7 ( -7 ( -7 D)))
+1
To illustrate further the use of a labei in an arithmetic expression and the -7 operator, suppose TABLE is
the label marking the beginning of a table of addresses
and an offset is in OFFSET, we could write:
GOTO
-7
(TABLE + OFFSET)
Labels
A local label is declared automatically by placing one
-in a progra...T!l:
e.g.,
~VIAIN2,
XLAST = 0; YLAST = 4
A label may be declared GLOBAL by the declaration:
e.g., GLOBAL LABEL BUFFER, POINT, LINE,
SEND
Global labels are used for communication between routines, in particular to provide entry points. Thus a
global label may be declared in several routines, but
placed only in one routine. For example, BUFFER is
declared global in Program 1 and Program 2, but
is placed only in Program 2. The section on procedures
explains how labels are used to define procedure entry
points.
Address manipulations
SAL has very flexible facilities for handling addresses,
as may be seen from the syntax. A label (global or local)
may be used in any arithmetic or logical expression.
When an expression is being evaluated the value taken
for a label is the address assigned to that label, whereas
the value taken for a variable is the contents of the address assigned to that variable; these are sometimes
referred to as left and right hand values, respectively.3
Thus, if L is a label we could write:
A=L+2
Indirect addresses are indicated with -7. Thus:
means take the value (see above) of A and use that as
the address to store the value contained in the address
given by the value of D, plus 2. The generality of the
syntax (see appendix) permits the -7 operator to operate on expressions:
since any arithmetic expression may follow a GOTO
statment. The GOTO statement transfers control to the
address given by the value of the expression following
GOTO. A simple case is GOTO L, the value of the
arithmetic expression L being the address of label L.
The address of a variable may be obtained with the
PTR (pointer) operator:
e.g., A = PTR D
hence -7 (PTR A) is identical to A.
Data structures and components
The comprehensive address handling facilities described above plus the component feature provide the
basic means for building and manipulating data structures. They are particularly suited to list, tree and ring
type structures.
The component feature, similar to that in AED,7
allows data to be read from or written to any field in
any half-word in a contiguous block of store. The block
of store is referenced by a pointer, which is any expression whose value is an address.
A complete half-word may be referenced using a component defined by a name and an offset:
e.g., ICOMP NEXT 0
This declares NEXT to be an integer component,
with offset 0 as shown in Figure 1. Suppose PI contains a pointer to a block of store, then a value may be
set in the first half-word with a statement:
NEXT(Pl) = 1024
Suppose we declare the next half-word (half-words are
indicated by the increment 04, a rather unnatural
Titan convention) to be a component SIZE:
e.g., ICOlVIP SIZE 04, 0770
I0
indicates octal.
This time we have further declared that the component
SAL
551
Embedded assembly code and the lack of an Algol
type block structure
1024 IEXT
Titan assembly code may be freely embedded at any
position in a SAL program. Declared variables may be
referenced, so providing communication between assembly code and other statements. Index registers may
be referred to by their declared names. The four parts of
a Titan assembly code instruction are:
SIZE
Figure I-Components
SIZE refers only to that part of the word specified by
the mask 0770. When reading to or writing from such a
field, only those bits corresponding to ones in the halfword are referenced.
If it is desired to shift data to the left before writing,
or to the right after reading, then a count for the shift
may also be specified:
e.g., ICOMP SIZE 04, 0770, 3
Op. code Index register (Ba) Index register (Bm)
Address or number
Suppose we want to send a block of 1000 words of
data to the satellite computer attached to Titan
Data is in array J
B1 = 1000
B2
=
3000
If the half-word offset by 04 from PI contained 0123456,
where data are to be
sent
1013 1 0 J
would change it to 0123776.
The pointer may be specified by any arithmetic expression. We could, for example, set the SIZE component in the block pointed to by the NEXT component of
PI, as shown in Figure 1, by the statement:
SIZE(NEXT(PI»
=
53
Reference to machine registers
As explained earlier the Titan computer has 128 index registers which are used as accumulators for integer
arithmetic. These index registers may be referred to
directly in any expression:
e.g., B27 = A
+ B26 + -+ B25 + NEXT(B24)
or if names have been declared for the index registers,
then:
BLINE 24 POINTER, ADDR, ABC, RESULT
RESULT = A
(POINTER)
+
ABC
+
~
ADDR
+
set B2 to some address
I. in satellite
I
then the statement:
SIZE(P1) = 077
set B1 to number of
words
to be sent
I
send data to satellite
I using assembly
I code order
IF A
=
2 THEN . . . ..
I
carry on with rest of
program
SAL does not have an Algol-like block structure. We
could not convince ourselves that it would be any advantage to have one in this simple type of language.
The advantage of being able to use the same name for
different variables in different blocks is minimal. We
had a strong incentive not to use a block structure with
any automatic dynamic allocation of local variables
within the blocks, as we wanted to be able to freely embed assembly code without restrictions. This includes
the ability to jump using assembly code to any label or
computed address. If there were a block structure the
programmer would have to take special action when
jumping into or out of a block, unless it was a purely
lexicographic block' structure as in PL360. An earlier
section explained how the programmer may achieve the
effect of automatic allocation by using external integer
variables.
NEXT
This feature allows efficient use of the machine registers while using high level statements, without the
need for lapsing into assembly code.
Procedures
As several conventions for passing arguments to procedures have grown up in the laboratory, we decided
not to include any set way of defining or calling pro-
552
Spring Joint Computer Conference, 1969
cedures in SAL. Any piece of code, however, may be
considered as a procedure, with global or local labels
marking the entry points (there is usually only one),
specific code having t.o be wrlttf'n to pick up the arguments depending upon how they are passed. Calls to
procedures must set up the arguments, save the return
address, then jump to the entry point.
There is, however, an exception to this. SAL runs
within the ~\Iixed Language System CULS) where as.sembly code, FORTRAX and SAL programs may be
compiled separately but loaded and run together. Within :\ fLS the standard method of passing arguments and
calling procedures is the method required by FORTRAX. A general SAL feature allows calls to be made
to procedures uRing this method. by preceding the call
with .\ILS:
e.g., :.'IlLS SETUP (A, B, C)
A = }ILS CALCULATE(B)
the latter example ha vinga value. The syntax allows
the argument list to be preceded by any declared name.
I t is very useful permitting this name to be a variable,
the value of which is the address of the entry point to
the procedure. This is not quite as general as BCPL
where the identity of the procedure may be given by the
value of an expression.
e.g., INTEGER CHOICE
CHOICE
=
~
(TABLE
+ OFFSET)
I Table contains entry points
]\'ILS CHOICE(10)
This standard method of calling procedures could not
be universally adopted for SAL since FORTRA~ procedures and calling sequences are not pure procedures.
One of the strong points of SAL is its ability to communicate with programs written in other languages. To
ease this problem further :\ [. Richards has suggested
declaring the names to be used for procedure calls to
indicate to the compiler the type of call that must be
setup:
e.g., FORTRAN SETUP, CALCULATE
ALGOL CUBIC
BCPL STRING, LIST
Calls to procedures need not then be preceded by a
special ,yard as at preRent. (:\ILS).
P.g., RETep(A,B,C)
x = CURle(y)
LIST
= LIST
+1
Z = LIST(P.Q,R)
Input/ output
The input/output facilities are very Titan dependent
so are not explained in any detail. Data transfers in
Titan are arranged in "streams," enabling data to be
read from any input device and sent to any output device in a genemlized vvay. Facilities are provided to
select an input or output stream, read or write n. single
alphanumeric character, a string of characters, or n.
binary chan-tder (12 bits). :\ [ore complient.ed operatioIls
such as reading or writing numbers in different formats
must be specifically programmed (probably by procedure call).
Implementation
The SAL compiler has been implemented using the
Brooker-:Uorris compiler-compiler. 8 At the beginning
of the project we chose to use the compiler-compiler as
we believed th,LT, <,LE
T
T
TT T
l\,K
Declarations
GLOBAL LABEL name [,name*?] terminator'
INTEG ER declaration-name [,declaration-name *?]
terminator
SAL
GLOBAL IXTEGER declaration-name [,rleclamtion-naJne*?] tel'lninator
RRLSTART IXTEGER b-line constant terminatoJ'
TXTEGER b-line decla1'ai1~on-naJJle [,declarahonname*?] terminator
REAL cleclaration-n01ne [,decla1'a#on-name*?l
terminator
B LIXE [b-list*] terminator
b-list = [bnum?] name [,nallle*?]
bnum = b-line, [digit*]
CO:.\L\fOX [c-list*] terminator
c-h.c;;t = / [name?] / declaration-name
[,declaration-name *'?]
ICO:.\fP name constant [,constant?] [,con.~tant?]
terminator
Setting up half-words of data
l-rw 1)8
wldres.'l-cxpressioi/
=
[,(((ldre.'l:,!-().r:7)}·ess/'oll *'?]
terminator
Reserving space
I{ESEHVE address-ex]J1'essiot/ termil/otoj'
Input and output statements
Omitted as they are ~o Titan dependent. They pr()vide for ~ett.ing up and manipUlating input and output
streams and reading or writing; a binary number, a
character, or a "record" (a f5tring of eharaet,{'rs terminated hy a "('arriag(' cont.rol charH,rter". FOJ"(·xampk.
a "newline").
Preset (compile-time) declaration
SET declaration-name [TO declarahon-name?]
address-expression [,address- e,r:pression *?]
terminator
.555
Procedure cans using the
~LS
conventions
:\fLS name (argument [,argument*'?] terminator
= ~\fLS name (argument [,arg1l7l1ent*'?])
terminator
rle.~tination.
Compile time constants
name IS address-expression terminato)'
End of a routine
FIX ISH terminato]'
Placing a label
REFEHE~CES
label,
H
Assignment statements
destination
destination
destination
destination
destinat?:on
deshnation
=
=
=
=
=
=
expression terminator
character-string terminator
term AX]) term terrm:nator
tenn on term terminator
X 01' term terminator
term shift term ternu:natol'
Transfer of control, iterative and conditional
statements
GOTO expression terminator
STOP terminator
FOR de8tinaMon = expression STEP expl'essioll
UNTIL expression DO state1nents terminator REPEAT
terminator
WHILE expression cond1'fion expression DO statements terrninator REPEA T
terminator
IF expression condition expression THEX statements [ELSE statements?] EXD
~achine
code statements
op ba bm address-expression terminafor
BW)\V~
SAL Ilser'8
lIIanual
University Mathematieal Laboratory Cambridge .June l!)6~
2 A EVAXS
PA.L-A lan(Jllaye desi(Jlled for leachin(J PJ'o(J!'(wlllliny
lin(Juistic8
Proe 2;{]'<1 Xational AGM ConfeJ'en(~e )1)61-\
;{ M RICHARDS
RCPL: .-l tool for compileI' wrihil(! and systellls pro(frallllltiltf/
Proe S .J C C IH6!l (t.his issue)
4 ~ WIRTH
P L360 A proY1'01I//)/ill(J lan(fllaye for the 8{)O
CO/II /IlIlel8
J AeM Yol 15 Xo 1 January HWlS
f) H HA Y
.J F HCLIFSOX
.l!()L.IJ.~O: PJ'eliliduary specificatio" fur UII .1l{/ol-likl'
II/achilll' oriel/ted lallYl/auc for Ihe 8/)8
Interim Tedl Report 2 Projeet flS!IO Stanford Hesea)'('1i
Institute March 1n6~
6 p ~AGR Editor
Revised report on the algorithlllic lultuuaue .llgol fiO
Computer Journal Vol .~ p ;~4\1 January 1116:{
7 j) T ROSS
.lED-O prOfjrallllllin(/ malllwl
Preliminary Release
~lassachusetts Intititut.e of Technology (ktobel' 1~164
H R A BOOKEH et al
The cO/llpilel' compilel
Annual Review in Automatic Pl'Ogramming
Pergamon Press 196;{
HPJ BROWX
The Jf L/lmacro processor
C AC:\f Vol 10 X 0 10 October 1\167
n·w
BCPL: A tool for compiler writing and
system programming
by l\1ARTIN RICHARDS*
Univer&ity Mathematical Laboratory
Cambridge, England
INTRODUCTION
The language BCPLI (Basic CPL) was originally developed as a compiler writing tool and as its name
suggests it is closely related to CPL2,3 (Combined
Programming Language) which was jointly developed
at Cambridge and London Universities. BCPL adopted
much of the syntactic richness of CPL and strived for
the same high standard of linguistic elegance; however,
in order to achieve the efficiency necessary for system
programming its scale and complexity is far less than
that of CPL. The most significant simplification is
that BCPL has only one data type-the binary bit
pattern-and this feature alone gives BCPL a characteristic flavour which is very different of that of CPL
and most other current programming languages.
BCPL has proved itself to be a very useful compiler
writing tool and it also has many qualities which make
it highly suitable for other system programming applications.
We will first outline the general structure of BCPL
and later discuss how well it is suited to applications
in the fields of compiler writing and system programming.
The language
BCPL has a simple underlying semantic structure
which is built around an idealised object machine.
This method of design was chosen in order to make
BCPL easy to define accurately and to facilitate machine independence which is one of the fundamental
aims of the language.
* The work was started while the author was employed by
Massachusetts Institute of Technology. It was supported, 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
Nonr-4102(0l).
The most important feature of the object machine
is its store and this is represented diagrammatically ill
Figure 1. It consists of a set of numbered boxes (or
storage cells) arranged so that the numbers labelling
adjacent cells differ by one. As will be seen later, this
property is important.
Each storage cell holds a binary bit pattern called
an Rvalue (or Right hand va1ue). All storage cells are
of the same size and the length of R values is a constant
of the implementation which is usually between 24 and
36 bits. An R value is the only kind of object which can
be manipulated directly in BCPL and the value of
every variable and expression in the language will
always be an Rvalue.
R values' are used by the programmer to model abstract objects of many different kinds such as truth
values, strings and functions, and there are a large
number of basic operations on Rvalues which have
been provided in order to help the programmer model
the transformation of his abstract objects. In particular,
there are the usual arithmetic operations which operate
on Rvalues in such a way that they closely model
integers. One cal~ either think of these operations a:;
ones which interpret their operands as integers, perform the integer arithmetic and convert the result
back into the R value form, alternatively one may
think of them as operations which work directly on bit
patterns and just happen to be useful for representing
integers. This latter approach is closer to the BCPL
n
n+1
n+2
n+4
Figure I-The machine's store
557 - - - - - - - - - - - - - - - - - -
!l58
Spring Joint Computer Conference, 1969
philosophy. Although the BCPL programmer has direct
access to the bits of an R value, the details of the binary
representation used to represent integers are not defined and he would lose machine independence if he
performed non numerical operations on R values he
knows to represent integers.
An operation of fundamental importance in the object machine is that of Indirection. This operation has
one operand which is interpreted as an integer and it
locates the storage cell which is labelled by this integer.
. This operation is assumed to be efficient and, as will
be seen later, the programmer may invoke it from within BCPL using the rv operator.
Variables and manifest constants
A variable in BCPL is defined to be a name which has
been associated with a storage cell. It has a value
which is the R value contained in the cell and it is
called a variable since this Rvalue may be changed by
an assignment command during execution. Almost all
forms of definition in BCPL introduce variables. The
only exception is the manifest declaration which is used
to introduce manifest constants.
A manifest constant is the direct association of a
name with an R value; this association takes place at
compile time and remains constant throughout execution. There are many situations where manifest constants can be used to improve readability with no loss
of runtime efficiency.
process of finding the Lvalue or Rvalue of a variable is
called Lmode or Rmode evaluation respectively. The
idea of mode of evaluation is useful since it applies to
expressions in general and can be used to clarify the
~~emantics of the assignment command and other
fEatures in the language.
_"imple assignment
The syntactic form of a simple assignment command
is:
El
E2
where El and E2 are expressions. Loosely, the meaning
of the assignment is to evaluate E2 and store its value
in the storage cell referred to by El. It is clear that the
expressions El and E2 are evaluated in different way:::;
and hence there is the classification into the two mode:::;
of evaluation. The left hand expression El is evaluated
in Lmode to yield the Lvalue of some storage ceil and
the right hand side E2 is evaluated in Rmode to yield
an Rvalue; the contents of the storage cell is then
replaced by the Rvalue. This process is shown diagrammatically in Figure 3. The only expressions which
may meaningfully appear on the left hand side of all
assignment are those which are associated with storage
cells, and they are called Ltype expressions.
The tenns Lvalue and Rvalue derive from consideration of the assignment command and were first used by
Strachey in the CPL reference manual.
Lvalues and modes of evaluation
As previously stated each storage cell is labelled by
an integer; this integer is caned the Lvalue (or Left
hand value) of the cell. Since a variable is associated
with a storage ceil, it must also be associated with an
Lvalue and one can usefully represent a variable diagrammatically as in Figure 2.
Within the machine an Lvalue is represented by a
binary bit pattern of the same size as an Rvalue and so
an Rvalue can represent an Lvalue directly. The
The lv operator
As previously stated an Lvalue is represented by a
binary bit pattern which is the same size as an Rvalue.
The lv expression provides the facility of accessing the
El
1=~t1on
Lvalue
;-\
Name
Lvalue
E2
1~uat1oD
Rvalue
I'
~
I
i
:=
Identical
bit patterns
\
\
\
\
\
Rvalue
Figure 2-The fOlm of a variable
.../
Lve.lue
,I
II
~ep~~.
in the cell
~_s_to_r_ag_e_ce_l¥
Figure :3-'T'~~ process of assignment
BCPL
Lvalue of a storage cell and, as will be seen, this ability
is very useful.
The syntactic form of an lv expression is:
559
E
TV
Rmode
1
evaluation
lv E
where E is an Ltype expression. The evaluation process
is shown in Figure 4. The operand is evaluated in
Lmode to yield an Lvalue and the result is a bit pattern
identical to this Lvalue. The lv operator is exceptional
in that it is the only expression operator to invoke
Lmode evaluation, and indeed in all other contexts,
except the left hand side of the assignment, expressions
are evaluated in Rmode.
Rvalue
,,
~
"
'.
Identical
bi t pat terns
/
""
/
~
Lvalue
The rv operator
The rv operator is important in BCPL since it
provides the underlying mechanism for manipulating
vectors and data structures; its operation is one of
taking the contents (or Rvalue) of a storage cell whose
address (or Lvalue) is given.
The syntactic form of an rv expression is as follows:
Figure 5-The evaluation of an RV expression
appear on the left hand side of an assignment command,
as in:
rv E
rv p
and its process of evaluation is shown diagrammatically
in Figure 5. The operand is evaluated in Rmode and
then the storage cell whose Lvalue is the identical bit
pattern is found. If the rv expression is being evaluated
in Rmode, then the contents of the cell is the result;
however, it is also meaningful to evaluate it in Lmode,
in which case the Lvalue of the cell is the result. An
TV expression is thus an Ltype expression and so may
and one can deduce that this command will update the
storage cell pointed to by p with the Rvalue of t.
Data structures
The considerable power and usefulness of the rv
operator can be seen by considering Figure 6. This
v
Iv
l
E
1
\
+
3
l
R!node
evaluation
Rvalue
;'\
evaluation
"
~ode
evaluation
Rvalue
Lmode
V~alue
t
,,
Identi'cal
bit patterns
, Identical
/ " bit patterns
\
I
\
I
\
\
\
\
Identical
, ,,' bit patterns
~
Lvalue
!
i:.'"
Rvalue
Figure 4-The evaluation of an LV expression
Figure 6-An intrepretation of V
+3
560
Spring Joint Computer Conference, 1969
diagram shows a possible interpretation of the expression V + 3. Some adjacent storage cells are shown and
the left most one has an Lvalue which is the same bit
pattern as the Rvalue of Vo One wil] recall that an
Lvalue is really an integer and that Lvalues of adjacent
cells differ by one, and thus the R value of V + 3 is
the same bit· pattern as the Lvalue of the rightmost
box shown in the diagram. If the operator rv is applied
tQ V + :3, then the contents of that cell will be accessed.
Thus the expression:
TV
1 E2 is equivalent to rv (El +
I
The cell referred
to by Xpart.J,V
I
Xpart
~-
Figure 7--An interpretation of X part 1 V
(V + i)
acts very like a vector application, since, as i varies
from zero to three, the expression refers to the different
elements of the set of four cells pointed to by V, V can
be thought of as the vector and i as the integer subscript.
Since this facility is so useful, the following syntactic
sugaring is provided:
El
V----~)~
36
E2)
and a simple example of its use is the following command:
vl
(i
+ 1)
: = V
l i+2
One can see how the rv operation can be used in
data. structures by considering the following:
V 1 3 == 1'v (V
== .TV (:3
+
Figure X-A stl'Ueture of int.egers and pointer:;
3) by definition
+ V) since + is commutative
==31V
Thus V 1 3 and 3 1 V ares emantically equivalent;
however, it is useful to attach different interpretations
to them. We have already seen an interpretation of
V 1 3 so let us consider the other expression. If we
rewrite 3 1 V as Xpart 1 V where Xpart has value 3,
we can now conveniently think of this expression as a
selector (Xpart) applied to a structure (V). This
interpretation is shown in Figure 7.
By letting the elements of structures themselves be
structures it is possible to construct compound data
structures of arbitrary complexity. Figure 8 shows a
structure composed of integers and pointers.
Data types
The unusual way in which BCPL treats data types
is fundamental to its design and thus some discussion
of types is in order here. It is useful to introduce two
classes:
a. Conceptual types
b. Internal types
The Conceptual type of an expression is the kind of
abstract object the programmer had in mind when he
wrote the expression. It might be, for instance, a time
in milliseconds, a weight in grams, a function to transform feet per second to miles per hour, or it might be a
data structure representing a parse tree. It is, of course~
impossible to enumerate all the possible conceptual
types and it is equally impossible to provide for all of
them individually within a programming language.
The usual practice when designing a language is to
select from the conceptual types a few basic ones and
provide a suitable internal representation together with
enough basic operations. The term Internal type refers
to anyone of these basic types and the intention is
that all the conceptual types can be modelled effectively
using the internal types. A few of the internal types
BCPL
provided in a typical language, such as CPL, are listed
below:
real
integer
561
to write nonsensical programs which the COlllpiler will translate without complaint. Thii:>
slight disadvantage is easily outweighed by the
simplicity, power and efficiency that this treatment of types makes possible.
label
Syntactic features of BCPL
integer function
One of the design criteria of BCPL was that it should
be a useful system programrning tool and it was feit
that high readability was of extreme importance.
The readability of a program largely depends on the
skill and style of the programmer; however, his task
is greatly simplified if he is using a language with a
rich set of expressive but concise constructions and if
all the little syntactic details have been well thought out.
The syntax of BCPL is based OIl the syntax of CPL
and, although the underlying semantics of the two
langua~es are very different, they look superficially
alike.
One of the most important requirements necessary
before one can obtain a reasonable degree of readability
is an adequate character set which contains both capital
and small letters. A comparison has been made between
two hardware versions of the same large BCPL program, one using nearly the full ASCII character set.
and the other using the same set without any small
letters. Although there is no accurate measure of
readability, it was agreed by all who made the comparison that the difference between the two versions was
very significant. The lengthening of identifiers to avoid
clash of names, and the fact that system words and
identifiers were no longer distinct both increased the
difficulty of reading the program. There are satisfactory implementations of BCPL using a restricted
character set, but such a set should only be used where
absolutely necessary.
BCPL follows CPL in the selection of commands.
There are the three basic commands: assignments,
routine commands and jumps, and there is the large
variety of syntactic constructions to control the flow
of control within an algorithm; some example forms are
given below:
(real, Boolean) vector
:Much of the flavour of BCPL is the result of the
conscious design decision to provide only one internal
type, namely: the binary bit pattern (or Rvalue). In
order to allow the programmer to model any conceptual
type many useful primitive operations have been provided. For instance, the ordinary arithmetic operators
+, -, * and / have been defined for Rvalues in such
a way as to model the integer operations directly. The
six standard relational operators have been defined and
a complete set of bit manipulating operations provided.
In addition, there are some stranger bit pattern operations which provide ways of representing functions,
labels and, as we have already seen, vectors and
structures. All these operations are uniformly efficient
and can usually be translated into one or two machine
instructions.
The most important effects of designing a language
in this way can be summarized as follows:
1. There is no need for type declarations in the
language, since the type of every variable is
already known. This helps to make programs
concise and also simplifies such linguistic problems as the handling of actual parameters and
separate compilation.
2. It gives the language nearly the same power as
one with dynamically varying types (e.g., P AL4)
and yet retains the efficiency of a language
(like FORTRAN5) with manifest types; for,
although the internal type of an expression is
always known by the compiler, its conceptual
type can never be. For instance it may depend
on the values of variables within the expression,
as in the vector application V t i, since the
elements of a vector are not necessarily of the
same conceptual type. One should note that in
languages (such as ALGOL6 and CPL) where
the elements of vectors must all have the same
type, one needs some other linguistic device in
order to handle dynamically varying data
structures.
3. Since there is only one intenlal type there can
be no automatic type checking and it is possible
test E then C or C
ifE do C
unless E do C
until E do C
while E do C
C repeatuntil E
C repeatwhile E
562
Spring Joint Computer Conference, 1969
C repeat
for Name = E to E do C
where E denotes any expression and C any command.
A very useful pair of additional commands are
a. break which causes a jump out of the smallest
enclosing loop command, and
b. return which causes a return from the current
routine.
One of the most noticeable ways in which this large
selection of constructions improves readability is by
the considerable reduction in the need for labels and
goto commands. For instance, the BCPL compiler
itself consists of 88 pages of BCPL program and contains only 29 labels which is about one label per three
pages of program. It is interesting to see how experienced FOR TRAX programmers fill their first few
BCPL programs with labels and how their programming style improves as they gain facility.
The BCPL syntax for declarations and definitions
is far simpler than the corresponding syntax in CPL;
this is mainly due to the elimination of types from the
language, and the lower emphasis placed on declarations in BCPL.
The purpose of a declaration in BCPL is threefold:
a. To introduce a name and specify its scope.
b. To specify its extent.
c. To specify its initial value.
The scope of a name is the textual region of program
in which it may be used to refer to the same data item;
this region is usually a block or the body of a function
or routine, and it depends on the way in which the
name was declared. The extent of a variable is the time
through which it exists and is associated with a storage
cell. Throughout the extent of a variable, its Lvalue
remains constant and its R value is only changed by
assignment. Nlost forms of declaration initialiM the
variables they define, as in:
is allocated prior to execution and cQntinues to
exist until execution is complete.
2. Dynamic variables
.t\ d~lrla/mic variable is one ,\;ilhose exterlt starts
when its declaration is executed and continues
until execution leaves the scope of the variable.
Dynamic variables are particularly useful when
using recursive functions and routines. The
kind of variable declared depends on the form
of declaration used; out of the nine methods of
declaring names in BCPL, five declare static
variables, three produce dynamic variables and
the remaining one declares manifest constants.
Function and routine calls
In BCPL as in CPL, there is a rigorous distinction
between expressions and commands which shows itself
in the syntax of the language; it also causes the semantic separation of functions from routines. In many
respects functions and routines are rather similar;
however, a function application is a kind of expression
and yields a result, whereas a routine call is a kind of
command and does not.
The syntactic form of both functioll applications
and routine calls is as follows:
El(E2, E3 ....... , En)
where El to En all denote expressions. The expressions
E2 to En are called actual parameters. The evaluation
process is as follows:
1. All the expressions E 1 to En are evaluated ill
In this example, the variable f is initialized to a value
which represents the function defined, and x is initialized to 47.
In BCPL, variables may be divided into two classes:
Rmode to yield Rvalues.
2. A set of n-l adjacent new storage cells are found
and the values of E2 and En are stored in them.
;~. The function or routine corresponding to the
value of El is found and the formal parameters
are associated with the cells .containing the
arguments. This association is performed from
left to right and there is no need for the number
of actual parameters to equal the number of
formals.
4. The body of the function or routine is then
executed in the new environment .
.5. When the body has been completely evaluated,
execution returns to the call. For a routine call
there is no result and execution is now complete;
however, for a function application there is a
result which is the Rvalue of the function body.
1. Static variables
The extent of a static variable is the entire
execution time of the progra.m; the storage cell
All functions and routines in BCPL are automatically recursive and so, for instance, one can call a
function while an activation of that function is already
let f (t) = 2*t
let x = 36
+3
+ f(4)
BCPL
in existence. In order to allow for recursion and yet.
maintain very high execution efficiency, the restriction
has been imposed that all free variables of both functions and routines must be static. Randell and RusselF
give a good description of the kind of mechanism
normally required for recursive calls in ALGOL;
however, with this restriction, a recursive call in BCPL
can be very efficient.
The mobility of the BCPL Compiler
A program is machine independent if it can be transferred from one machine to another without change.
Complete machine independence is rarely achieved;
however, it is a goal well worth striving for. For large
systems, mobility is often a more useful measure than
machine independence. :\lobility is a measure of how
easy it is to transfer a system from one machine to
another; it differs from machine independence because
the program often requires some redesign and reprogramming. For example, when moving a compiler from
one machine to another it is necessary to rewrite the
code generator and usually part of the lexical analyzer.
Writing a compiler in a machine independent language
is an important factor in obtaining mobility but it does
not ensure it; it is at least as important to design the
overall structure of the compiler with mobility in mind.
The BCPL compiler has been designed with this aim
and has been transferred successfully to seven other
machines without much difficulty.
BCPL is a simple language to compile and it has a
straightforward compiler written in BCPL. The compiler is easy to follow and it produces fairly good object
code at an acceptably fast speed. Its general structure
is shown in Figure 9. The rectangular boxes represent
the different logical parts of the compiler and the round
boxes the various intermediate forms the BCPL program takes ,vhile it is being compiled. These interme-
diate forms will be briefly sketched by considering the
transformations of the program shown in Figure 10.
The input form of the program is first transformed
into an internal tree structure called the Applicative
Expression Tree (AE Tree); this is done by the syntax
analyzer which is composed of a set of machine independent parsing functions (SYX) and a lexical analyzer
routine (PP). The AE tree structure for our example
program is shown in Figure 11.
The AE tree is then translated by Trans into an
intermediate object code called OCODE. OCODE was
specially designed for BCPL and it is a simple language
whose statements cause basic transformations on an
imaginary stack machine; it was designed to be as
machine independent as is practical to keep the changes
to Trans to a minimum when the compiler is moved to
a new machine.
The Code generator translates OCODE statements
into the machine code of the object machine. The implementor is free to choose between relocatable binary
and assembly language, and it is usually found that the
ability to generate both is very valuable,
$( let x = a
if x .!!:. 2 do
x:::I x + 2
$)
finish
Figure 10-An example BCPL program
LET
IF
8
NE
f-'
ASS
./
/
1?LUS
CG
1----..,., (*<:hlne
CodV
" - - _ _..oJ
Figure 9-The structure of the BCPL compiler
.563
Figure 11-The AE tree form of Figure 10
.564
Spring Joint Computer Conference, 1969
In order to transfer BCPL to a new machine, one
must choose a suitable strategy and this usually depends
on the locality of the machines, their basic compatibility and the facilities available on the recipient
machine. The basic process is to write both a code
generator for the new machine and a suitable machine
code interface with the new operating system; one then
modifies and corrects the few machine dependencies
in the syntax analyser and Trans, and finally compiles
the new compiler using the new code generator. The
process is complicated by the fact that the work cannot
be carried out entirely on one machine. In practice,
the more work that can be done on the donor machine
the better; however, one often has no direct access to
that machine and a different strategy must be applied.
In this situation it is usually better to implement a
temporary code generator for the recipient machine in
some standard language such as FORTRAN or SNOBOL8 and then use it to compile the OCODE files of
the syntax analyzer and translation phase of the compiler. One can then construct a temporary BCPL
compiler on the new machine and use it to compile
itself. The compiler can then be polished to fit well in
its new operating environment.
The cost of transferring BCPL depends largely on
the computing facilities available, and one can expect
it to be between one and five man months.
The use of BCPL for compiler writing
There S,re many reasons why BCPL is suitable for
compiler writing and probably one of the most important of these is the ease of programming in the language.
This together with its inherently high readability combine to make BCPL a very flexible language. The
richness and variety of useful commands are valuable
and the built in recursion is almost essential. In order
to see how well these features may be used together we
will consider a short excerpt from the BCPL compiler.
Figure 12 shows the overall structure of the main part
of translation phase. The directive get 'HEAD2' causes
the compiler to insert a file of BCPL text and compile
it with what follows. This insertion facility is very
useful when co-ordinating many separate parts of a large
program. This example shows how the switchon command may be used with manifest constants to good
effect. It is executed by evaluating the controlling
expression HI 1 x and then jumping to the case corresponding to the value found. The expression appearing
in the case labels are manifest constants and denote the
possible AE tree operators that Trans must deal with
(the constants LET, TEST and REPEAT are declared
in the inserted file HEAD2. If the value of Hl1 x
does not correspond to any case then execution con-
get 'HEAD2'
~
Trans(x) be
$(1 sn tchon
$(
HIJ,x
.!!!.!:£
default: return
-case LET:
-case TEST:
-
case REPEAT:
Figure 12-The structure of Trans
tinues at the default label. Since all the case constants
are known by the compiler it is possible to implement
the switch very efficiently, even constructing a hash
table if this method of switching is appropriate. This
combination of manifest constants and switchon commands is very effective and it has been used frequently
in the BCPL compiler.
Recursion is also very useful in many compiling
situations particularly in parts concerned with the
creation and analysis of tree structures. Figure 13 is
a detailed excerpt, again taken from Trans, and it
provides an example of a typical use of recursion. The
section of program shown is used to translate the AE
tree form of a test command into OCODE. The variable
x is the formal parameter of Trans and it points to a
~ TEST:
$(
~ L, M
:=
NextpararnO, Nextpara.'TI()
Jurnpcond(H2J,.x, false, L)
TranS(H3~x)
Comp,j1l.'1lP (M)
Complab(L)
Tra.ns(H4~x)
Complab (\{)
return
$
Figure 13-A det.ail from the body of Trans
BCPL
TEST node. The form of this node is shown in Figure
14; the pointers to E, C1 and C2 represent the branches
to nodes for the Boolean expression and two altenlative
commands of the test command. These components can
be accessed by the expressions H2 1 x, H3 1 x, and
H41 x, respectively. To execute a test command,first
the Boolean expression is evaluated and then, if the
result is true, the first alternative is executed, alternatively the second. The general form of the object code
is as follows:
1. Code to evaluate E.
2.
3.
4.
5.
6.
7.
Code to jump to label L if the result is false.
Code corresponding to the translation of Cl.
An unconditional jump around the code for C2.
A directive to set label L.
Code for C2.
A directive to set the lahel used in step 4.
As can be seen the program to generate this code is
very straightforward. First, two local variables Land
M are declared for the two labels. The call for Jumpcond then compiles the code for steps 1 and 2. Its first
argument is the Boolean expression of the test command
and the other arguments specify the kind of conditional
jump required and the label to jump to. The next
statement is a call for Trans which will compile the
first alternative Cl. This is an example of the recursive
use of Trans. The calls for Compjump and Complab
generate code corresponding to steps 4 and .5, and then
there is a second recursive call for Trans to translate
C2. Finally, a directive to set label :\1 is compiled and
then, since the lest command has now been completely
translated, a return is made to the current call of Trans.
One should note how convenient it is not to have to
declare the types of the variables such as x, Land :\1,
and one should also note how well the use of manifest
constants, switchon commands, recursion and simple
data structures combine to produce a very effective and
readable means of writing this part of the compiler.
Although there is considerable variance in the style of
programming used in the different parts of the compiler,
X --------l!I..)
the facilities and syntactic qualities of BCPL have
made it possible to achieve this high standard of simplicity and readability throughout.
The way in which BCPL treats data types allows the
programmer great freedom to organize his symbol
tables, property lists, tree structures and stacks in the
most suitable fashion for his particular application.
Admittedly BCPL only provides the basic operations
and the compiler writer must write his own system,
but this is easy to do and he does not suffer the disadvantage of having to use a system in which inappropriate design decisions have already been made. The
philosophy of BCPL is not one of a tyrant who thinks
he knows best and lays down the law on what is and
what is not allowed; rather, BCPL acts more as a
servant offering all his services to the best of his ability
without complaint even when confronted with apparent nonsense. The programmer is always assumed to
know what he is doing and he is not hemmed in by
petty restrictions. ::\1achine code programmers tend
to like the way in which BCPL combines the advantages
of a high level language with the power to do address
arithmetic and to be able to manipulate binary bit
patterns without invoking a great weight of expensive
machinery.
When planning and writing a compiler in a commercial environment one must make a compromise
between the quality of the product and its cost. The
quality of a compiler is affected by many factors such
as its size, its compile speed, the efficiency of the object
code produced, the usefulness of the error diagnostics,
the accuracy and quality of its documentation, its
maintainability and in some cases its flexibility and
mobility. Only the first two of these are directly improved by writing the compiler in a more efficient
language, while the others tend to suffer because the
compiler is harder to write. Although efficiency is
important in a compiler writing language, this consideration should not totally dominate its design. The
author believes that the compromise in the design of
BCPL between efficiency and linguistic effectiveness
is near optimal for compilers of medium to large scale
languages especially if flexibility is required.
TEST
,.... E
'-
Cl
\..
C2
-;;>
Figure 14-The AE tree form of a test command
565
REFERENCES
M RICHARDS
The BCP L reference manual
Memorandum-69/1 The University Mathematical
Laboratory Cambridge England January 1969
2 J BUXTOX J C GRAY D PARK
CPL elementary programming manual
Edition II The University :\lathematical Laboratory
Cambridge England 1966
566
Spring Joint Computer Conference, 1969
lvE I rvE I E(Elist») lEO I E(diadicop)EI
:1 C STRACHEY (editor)
CPL working papers
Cambridge University ;Mathematical Laboratory and
London Institute of Computer Science 1965
4 A EVANS JR
A language for teaching programming linguistics
Proc 23rd National ACM Conference 1968
5 IBM Reference Manual
709/7094 FORTRA~ Programming System
Form C28--6054-2
6 P NAUR (editor)
Revised report on the algorithmic language ALGOL 60
The Computer Journal Vol 5 January 1963 349
7 B RANDELL L J RUSSELL
ALGOL 60 implementation
Academic Press 1964
8 D J FARBER et al
SNOBOL, a string-manipulation language
JACM Vol 11 Xo 1 January 1964
(monadic op) E I E ~ E, E \
table (collHtant) {, (constant) } ~
(number) I true I false I (E) I valof (block)
I
I
I
I
I (empty)
(name list) :: = (name) {, (name) };
(block> :: = $( (block body) $)
(block body) :: = C {; C} ~ I
(declaration) } ~ C} ~
{
;
(declaration> :: = let D {and D} ; I static (decl body) i
manifest (decl body) I
global (decl body)
(decl body) :: = $( (C def) {; (C def)l ~$)
(C def) :: =
The canonical syntax of BCPL
I
(name) ( (FPL ») = E I (name> ( (FPL ») be C
(name list) = (E list)
(name) = vec (constant)
I
I E, E I E, E, E I ... etc
I
(E list) : = (E list) I E ( (E list») lEO I
golo E I (name) : C I if E do C \ unless E do C I
while E do C I until E do C I C repeat I
C repeatuntil E I C repeat while E I
test E then C or C break return finish
resultis E I for (name) = E to E do C \
switch on E onto (block) I case (constant) : C I
default : C I (block) I (empty)
I
The syntax given below is Bachus N aur FOrol with the
following extensions:
E .. =
~
+ I - I not
(monadic op) :: =
APPENDIX
E
J I * I / I rem I + I - I
= I ~ Ils I gr Ile I ge I
lshift I rshift I 1\ I V I ==
(name): (constant) I
(name) = (constant>
(program) :: = (block body>
EXDAMS-EXtendahle Dehugging and
Monitorilli! SYstem *
-
. . -- .
·0
--,
by R. M. BALZER
The RAND Corporation
Santa Moniea, California
locate the symbol table, find the beginning and end of
source-level statements, and determine some way to
extract the dynamic information-needed for debugging-about the program's behavior, which is now
hidden in a sequence of machine instructions rather
than being the obvious result of one machine instruction. Is it any wonder that, after all this effort merely
to create a minimal environment in which to perform
on-line higher-level language debugging, little energy
remained for creating new debugging aids that would
probably require an increased dynamic informationgathering capability.
EXDAMS (EXtendable Debugging And Monitoring System) is an attempt to break this impasse by
providing a single environment in which the users can
easily add Il:ew on-line debugging aids to the system
one-at-a-time without further modifying the sourcelevel compilers, EXDAMS, or their programs to be
debugged. It is hoped that EXDAl\1S will encourage
the creation of new methods of debugging by reducing
the cost of an attempt sufficiently to make experimentation practical. At the same time, it is similarly
hoped that EXDAl\1S will stimulate interest in the
closely related but largely neglected problem of monitoring a program by, providing new ways of processing
the program's behavioral information and presenting
it to the user. Or, as a famous philosopher once almost
said, "Give me a suitable debugging environment and
a tool-building facility powerful (and simple) enough,
and I will debug the world."
INTRODUCTION
With the advent of the higher-level algebraic languages, the computer industry expected to be relieved
of the detailed programming required at the assemblylanguage level. This expectation has largely been realized. Many systems are now being built in higherlevel languages (most notably MULTICS).l
However, our ability to debug programs has not
advanced much with our increased use of the higherlevel languages. As Evans and Darley2 point out:
We find that, broadly speaking, a close analog
of almost every principal assembly-language debugging technique exists in at least one debugging
system pertaining to some higher-level language.
However, on-line debugging facilities for higherlevel languages are in general less well-developed
and less widely used (relative to the use of the
languages) than their assembly-language counterparts.
'Ve have, in general, merely copied the on-line assembly-language debugging aids, rather than design totally
new facilities for higher-level languages. We have
neither created new graphical formats in which to
present the debugging information, nor provided a
reasonable means by which users can specify the processing required on any available debugging data.
These features have been largely ignored because of
the difficulty of their implementation. The debugging
systems for higher-level languages are much more
complex than those for assembly code. They must
Design goals
* This research is supported by the Advanced Research Projects
Agency under Contract No. DAHC15 67 C 0141. Any views or
conclusions contained in this Memorandum should not be
interpreted as representing the official opinion or policy of
ARPA.
EXDAMS was designed to satisfy three needs: first,
as a vehicle to test some proposed, but unimplemented
on-line debugging and monitoring facilities; second,
as an extendable facility to which new debugging and
567
568
Spring Joint Computer Conference, 1969
monitoring aids could be added easily, then tested;
and, third, as a system providing some measure of independence of not only the particular machine on which
it is being run and the particular implementation of
the language being debugged and/or monitored, but
also of several source languages in which users' programs
could be written and debugged and/or monitored.
The normal techniques for on-line debugging, involving dynamic manipulati~n of a running program,
were inappropriate for these three ambitious design
goals, because, first, these techniques were both implementation-dependent and difficult to control; and,
second, certain important facilities; such as the ability
to run the programs backwards, are impossible with
these techniques.
Therefore, the program· to be debugged will run
with an EXDAMS routine that will monitor it, collect
necessary information about the program's actions,
and store this information on a history tape. Subsequently, EXDAMS debugging routines can retrieve
any information from the history tape, format it, and
present it to the user. Thus, assuming the history tape
is complete (i.e., contains all relevant data), any debugging and/or monitoring tool involves only retrieving,
then formatting, data from this static file.
The parts of EXDA~IS which analyze the program
and collect its history (the program -analysis and
history gathering phases discussed in a later section)
are language dependent. However, the major portion
of EXDAMS, and the portion chosen for experimentation-the debugging and monitoring routines-interact with only the history file. They are therefore independent of both the implementation of
the source language and the source language itself-to
the extent the history file is independent of the differences between source languages, as it is for the common
algebraic languages (PL/I, ALGOL, FORTRAN, etc.).
With this approach, the three design goals have
been achieved. Any debugging and monitoring aids
can be added to EXDAMS easily by writing the appropriate file-search and formatting routines. Moreover,
these aids are independent of the implementation of
the source language and, to a certain extent, of the
source language itself.
However, efficiency has been sacrificed. This approach is based on the insulation from the running program that results from the production of a history
tape of the program's behavior. The production and
replaying of this history involves large amounts of
I/O. However, the flexibility gained far outweighs
the inefficiency introduced, especially when one is
studying alternative debugging and monitoring aids.
The EXDAMS system output device is a cathode
ray tube (CRT) display, and all the debugging and
monitoring aids utilize its two-dimensional and highdata-rate capabilities. Some aids, in addition, use
the CRT's true graphic (point and vector) and dynamic
(time-variant) capabilities. The input devices are
a keyboard and some type of graphical pointing device,
e.g., a light-pen, RAND Tablet, joy-stick, mouse, or
keyboard cursor.
Before describing how EXDAMS works and how
new debugging and monitoring aids are added to the
system, we present some of the aids currently being
added to the basic EXDAMS system to give the reader
a better understanding of the types of debugging and
monitoring aids that are possible in EXDAMS.
Debugging and monitoring aids within EXDAAfS
EXDAMS contains two types of debugging and monitoring aids-static and motion-picture. The static aids
display information that is invariant with execution
time (a time value incremented as each source statement
is executed and used to refer to particular points in
the execution of a program), such as the values of
variables at the time an error occurred, a list of all
values of a variable up to a given execution time, or
a display of a portion of the source code.
The motion-picture aids, on the other hand, are
execution-time sensitive; that is, the data they display
may vary with execution time. These motion-picture
aids include the last n values of a set of variables, the
current instruction and subroutine, and the current
values of a set of variables. The user can run motionpicture aids either forwards or backwards at variable
speeds, by controlling execution time.
EXDAMS' most attractive features, from the user's
standpoint, are (a) his ability to control his program's
execution time, moving at variable speed either forwards
or backwards, while a debugging and/or monitoring
aid constantly updates its display of information; and
(b) his ability to stop execution time at any point, switch
to another aid, and continue perusing the behavior
of his program.
Static displays
Error analysis
The user requests the value of certain variables at
the time an error occurred. The system displays the
value of these variables. and all other variables in the
error-causing source language instruction, the type of
error, and the source instruction in error.
Source code
A portion of the user's source code is displayed in
EXDAMS
optional formats that may include indications of the
number of executions per statement and the removal
of levels in the source code (such as the bodies of dogroups or the code in the THEN or ELSE clauses)
below a certain depth, to afford the user a broader
view of his program.
The user may request this display in two manners.
He may call for the code around a certain label by
requesting SOURCE AT and specifying a label, or a
569
K
label plus or !pinus some nlLll1ber of source statements.
He also may call for, at any time, the source code around
the exact statement that caused a particular value
of a variable by requesting SOURCE FOR and specifying the desired value (the source statement causing
that value will be marked by its brightness). That
is, EXDAMS can associate any value with the exact
source. statement that produced it.
This ability, and its inverse of associating any source
statement with the values it produces, is fundamental
to the EXDAMS philosophy of debugging and monitoring that the activity of a program may be viewed
in either the data or the control spaces. The data space
shows which manipulations a program performs, which
values change, and the sequence in which they change.
The control space demonstrates how a program performs
its manipulation.
In a canonic debugging situation, according to the
EXDAMS philosophy, the user first ascertains what is
happening, then decides whether this behavior is correct, and finally, if it is not correct, determines how
the program performed these operations, at the same
time seeking the error in the program and/or data.
Thus, any comprehensive debugging and monitoring
system must include powerful facilities in both the
data and the control spaces and provide a simple means
of alternating between corresponding poin~ in either
space, as the user's needs or personal preferences dictate.
Flowback analysis
By calling for FLOWBACK FOR and specifying a
particular value, the user requests EXDAMS to analyze how information flowed through his program to
produce the specified value. This analysis appears
in the form of an inverted tree, with the bottom node
corresponding to the value for which the flowback
analysis was desired. Each node consists of the sourcelanguage assignment statement that produced the
value, the value itself, and links to nodes at the next
level. These nodes correspond to the non-constant
values in the assignment statement displayed in the
node that links with these nodes. These nodes have
the same format as the original and are linked to nodes
for all non-constant values used in the particular assign-
= 107
A=8+C-l0;
= 105
Figure 1
ment statement producing their value. Thus, Figure 1
shows a flowback analysis for a particular value of A.
This display shows that the assignment statement
"A= B+C-IO;" produced the specified value of A,
and its value here was 105. The values of Band C
used in this assignment to A were 8 and 107, respectively, and were produced by the assignment statements "B=R-1;" and "C=A+E;", respectively.
Each of the other nodes is explained in the same manner.
As many levels as will conveniently fit on the screen
will be displayed. The user can request a similar flowback analysis along any particular branch. He can
also call for the source code around any assignment
statement in the flowback analysis and, as described
in the section Motion-Picture Displays below, watch
the execution either forwards or backwards from any
point.
A similar type of flow back analysis is possible for
the control space, which displays the flow of control
through the program between any two points in execution time (i.e., between two nodes in the flowback
analysis). In a non-parallel processing environment,
this is simply a linear sequence, unless one wishes to
indicate control sequences at a lower level (within a
subroutine or do-group) as a closed loop out of the
main flow of control.
Motion-picture displays
In all the following examples, the information displayed is a function of execution time, whose rate of
change the user may increase or decrease, stop, or
reverse. Such control, together with the ability to
alternate between different debugging and monitoring
aids, enables him to discover and pinpoint the bugs
in his program.
570
Spring Joint Computer Conference, 1969
Values
Source code
This facility displays the values of the variables or
labels specified by the user. Each specified variable
or label is assigned a contiguous set of columns on the
display in which their values will appear. (The label
values will be a checkmark indicating at what point
in the execution the label was reached.) These values
will be ordered according to execution time, so that
a value produced earlier than another will appear higher
on the screen (Figure 2). This display can be scrolled
up or down to show other .values that cannot fit on
the screen at the same time. This scrolling alters execution time appropriately. The user can change the
direction of scrolling (and execution time) or stop at
any point. Once stopped, he may alter the list of variables on the screen and restart, or he may request the
source code for a particular value displayed.
ABC
R1
S
FILE
LABEL2
12
0
FILEI
-10
JOE
'101'B
'O'B
3001
This facility allows the user to watch his program
statements execute either forwards or backwards. The
statement being executed will appear brightened on
the screen. If it is an assignment statement, the value
of the assignment will also be displayed. If the instruction being executed is not on the screen, the portion
of the program containing this instruction will be
displayed. The user can command the system to follow
subroutine calls and, as in the static display of source
code, to display all levels.
Map
This facility is an extension of the source-code facility and is an adaptation of Stockham's work on flow
analysis. 3 The user specifies nodes (labels) to be displayed. All code between these nodes may be considered a single macro statement, for the purposes of
execution-time advancement. Thus, as the user varies
the execution time, the node corresponding to the code
being executed brightens and, as execution moves
from one node to another, a displayed arrow indicates
this shift. The length of time a node brightens is determined by either a common execution-time rate for
each macro statement or by the execution-time rate
for all statements executed within the macro statement.
The former display is most useful for following program execution while searching for a bug, while the
latter is well-suited to monitoring applications in which
the user is trying to determine how the program operates
and where it spends most of its time. The EXDAMS
environment-allowing the user to dynamically stop
the display, expand some nodes into several separate
nodes, collapse other nodes into a single node, and
then continue or reverse direction-should greatly
improve the usefulness of this display.
Windows
1000
HAL
'liB
I
1000
Figure 2
The current values of the variables specified appear
in "windows" (i.e., areas on the display screen) as
execution advances or reverses. If the value exceeds
the size 8f the window, as much will be displayed as
possible. In the case of arrays, the system will display
in the window the value being changed and as many
array elements, and their indices, around it as can fit.
In addition, for either arrays or strings, certain variables can be specified as pointers or indices into these
data representations.
The values of these variables appear in graphic,
·rather than numeric or alphanumeric, form according
to the position of an arrow directed at the character
or element at which the pointer or index is also directed.
EXDArvIS
Thus, in a buffer application, where many buffers
are scanned and processed and new buffers created,
the user can watch the data in the buffers change dynamically, and see the pointers and indices move back
and forth through the buffers.
Windows with transitians
This facility performs the same operations as the
preceding Windows facility except that, in addition,
it indicates the interrelationships between the displayed variables. As each new value is displayed, a
flowback analysis determines whether the current
value of any displayed variable was used in the creation
of the new value. If so, an arrow indicating this dependence appears, linking the windows of these variables
to the window of the variable being changed. To obtain
more detail for a particular transition indicated by
the arrows, the user may define a new display relevant
to that transition only, then either re-advance or reverse execution time. After completing the study of
this particular transition, he may return to his original
display.
The
EXDA.~:S
571
bugging statements iuto the program to provide the information necessary for history-gathering. In general,
the history contains all the dynamic information needed
to update execution time either forwards or backwards,
while the model contains all necessary static information.
Each model entry consists of an indicator of the type
of model entry, a pointer to the associated source statement, and an index to an entry in either the model or
the symbol table, depending on the type of entry. *
The model contains both the static control-information and the variable alteration-information of the
user's program. The control-information consists of the
CALL, GOTO, IF-THEN-ELSE, and DO-END structure of the program, while the variable alteration-information consists of the names of the variables on the
left-hand side of assignment statements and those
altered by input statements.
The debugging statements added to the program
pass the relevant run-time information to the run-time
history-gathering routines. **
The updated program is passed to the compilation
phase, while the symbol table and model are saved for
the debug-time history-playback.
environment
EXDA.;.\fS is a four-phase system predicated on the
assumption that neither an incremental compiler
nor a special debugging compiler designed for
EXDAMS requirements would be available for
the source language being debugged and/or monitored. If either is available, considerable restructuring of these phases would be prerequisite to the
full utilization of these capabilities. The four phases
are program analysis, compilation, run-time historygathering, and debug-time history-playback.
Program analysis
The first phase analyzes the user's source program as
it performs four functions, the most important of which
is the creation of a model of that program. This model,
the heart of the debug-time history-playback, is the
means by which values gathered on the history tape are
interpreted and by which portions of the source code are
retrieved, and is the repository of all structural information known about the program. The use of the model
for these functions will be explained in the section
Debug-Time History Playback but the contents of the
model will be discussed here.
The program analysis produces both a symbol table
and a random-access file of the user's source program
for the history-playback. As it analyzes the program,
it also builds a model of the program, and inserts de-
Compilation
The standard source-language processor compiles the
source program, as updated during program analysis.
Run-time history-gathering
The compiled version of the updated program is run
with a set of run-time routines that it calls. These routines gather dynamic information about the program's
behavior. This information is collected in a buffer that
is written out when full. It is the history tape of the programs's behavior and, together with the symbol table
and model, is sufficient to recreate the program's behavior in either the forwards or backwards direction of
execution time. This history contains, basically, the
values of the variables on the left-hand side of assignment statements, the direction (THEN or ELSE)
taken in IF statements, the direction (remain in or
flow out) taken at the end of DO-LOOPS, and the
point from which a GOTO or CALL was issued (to
facilitate execution-time backup). t
* Appendix A explains the use of the index field for each type
of model en try.
** Appendix B details these statements.
t Appendix
history.
C presents the precise information placed in the
572
Spring Joint Computer Conference, 1969
Debug-time history-playback
This phase contains the debugging and monitoring
aids which present the history information to the user
in a usable form on his display screen. It also interprets
the user's commands for alternative displays and/or
execution-time variations, and provides an editing
capability for modifying discovered bugs and for returning this modified program to the four phases for
another debugging iteration.
The main function of this phase is to assemble information from the history and display it on the screen.
Appropriately, the main routine in the phase is the information retriever used by all the debugging and
monitoring aids to retrieve desired information from the
history. It accepts (a) requests from the processing routines for information on a certain variable or set of
variables and (b) a direction for execution-time. Using
this direction, it searches the history for the next occurrence of a value change for any variable in the requested
set. It returns the name of this variable, its new· (or
old, if executing backwards) value, and its attribute.
Special calls facilitate the next subroutine call,
goto, return, assignment, iteration, or conditional
statement to be retrieved, so that all information in the
history is retrievable through this routine. The calling
routine describes what information to retrieve, and combines, processes, and formats it for the display routines
that interact with the display equipment.
The information retriever moves a marker through
the model as values are read in from the history. This
movement serves three purposes:
1. To permit interpretation of the bits in the history. Since the values in the history are not of a
fixed length, knowledge of the type of the next
value allows the routine to correctly interpret
the value and position itself at the next value.
2. To associate the values in the history with statements in the source program (through the
pointer to the source statement in the model),
enabling users to alternate between values in
the data space and the associated source statements in the control (program) space.
3. To reduce the amount of I/O necessary. By
using the model to interpret values from the
history, we need store only the value of source
variables and not also the identification of the
variables of which it is the value. This reduces
the amount of I/O by roughly one-half; since
the system is I/O-bound, this obviously improves the system's response.
The addition of new debugging and/or monitol'ing
facilities
To add a new debugging and/or monitoring facility
to the EXDAM:S system, first, extend the command
language of EXDAlvIS to include the new commands
needed to control the new facility and to route control
to the new routine for these commands. As long as these
commands do not conflict with existing ones, this is an
easy task.
Second, obtain the information required to respond
to the new commands by requesting it from the information retrieval routine as described in the previous
section. This is the essential issue in the EXDAMS
philsophy: All the information required by a routine
can be obtained easily, by request, without interacting
with the source program, the object code, or the history,
but only with the information retrieval routine.
Third, process and combine the obtained information.
The ease or difficulty depends entirely on the facility
being added and is independent of the information
collection mechanism.
Finally, format and display the processed inform.ation.
Again, the effort required depends entirely on the
facility being added and is independent of the monitoring mechanisms.
Thus, the EXDAMS environment reduces the problems of collecting information for a debugging and/or
monitoring facility, but provides only minimal capabilities in the processing and presentation of this information. If the collection of information is a major
problem in the creation of a debugging and/or monitoring facility, then EXDAMS has met its design goals.
In addition, 1:).S we gain more experience in the types of
processing and formatting required, we may also be able
to provide capabilities that facilitate these areas.
Example
To illustrate the EXDAMS system, we present an
example source program written in PL/I,4 followed by
the major transformations performed on it by
EXDAMS.
Original source program *
1. example program: PROCEDURE OPTIONS
2.
3.
(MAIN);
DECLARE
a (10, 3) CHARACTER (8) EXTERNAL,
* The reserved keywords 4 of the source language are in all
capital letters.
EXDAMS
4.
i BIXARY FIXED,
5.
switch BIT (1),
6.
search_string CHARACTER (8) VARYIXG;
7.
8.
9.
GET FILE (input) LIST (switch, search_string);
10.
IF switch THEX
11. loop: DO i = 1 TO 10;
12.
DO j = 1 TO 3;
.13.
IF a(i, j) = search_string THEK DO;
14.
PUT LIST (i, 1 < j);
15.
CALL abc (i, i + j * 3);
16.
GO TO end_program;
17.
END;
18.
END loop;
19.
ELSE
20.
PUT LIST ('switch turned off') ;
21. end_program:
22.
i = j * i - 5;
23.
RETURX;
24.
EKD example-'program;
Symbol table
The data are formatted here to facilitate reading,
but this format does not reflect actual internal representation. The dummy entries (12 through 17) at end
of the Symbol Table represent the types of expressions
being passed to a subroutine or output.
Symbol
Name
Attributes
10
11
A
ABC
END PROGRAM
EXAl\1PLE PROGRAM
I
INPUT
J
LOOP
SEARCH STRING
SWITCH
SYSPRINT
ARRAY (*, *), CHARACTER (8)
PROCEDURE"(*, *)
LABEL
PROCEDURE
BINARY, FIXED
FILE, STREAM
BINARY, FIXED
LABEL
CHARACTER (8), VARYING
BIT (1)
FILE, STREAM
12
13
14
15
16
17
DUMMY
DUl\fMY
DUMMY
DU1VIMY
DUMMY
DUMMY
BINARY, FIXED
DECIMAL, FIXED
BINARY, FLOAT
DECIl\1AL, FLOAT
CHARACTER (*), VARYING
BIT (*), VARYING
Number
1
2
3
4
5
6
7
8
9
573"
Model
Entry
:Number
26
1
6
574
Spring Joint Computer Conference, 1969
Model
To facilitate the reader's interpretation, the pointer
to the source code is represented here as a line number
Model
Entry
Number
Entry Type
in the original program, and an explanation of the index
field of the model entry has been added.
Source
Code
Pointer
Index to
Model or
Symbol
Table
1
9
29
6
1
2
PROCEDURE
GET
3
GET ASSIGNMENT
GET ASSIG N1VIEKT
IF
9
9
10
10
9
22
LABEL
ITERATIVE DO
11
7
11
8
21
8
9
ITERATIVE ASSIGK:MENT
ITERATIVE DO
11
12
5
20
10
ITERATIVE_ASSIGN~1ENT I
11
IF
12
13
7
19
4
5
6
I
Explanation of Index
Index of associated END model entry.
Index of Symbol Table of file associated
with GET.
IIndex of symbol receiving new value.
Index of symbol receiving new value.
Index of model entry for end of THEX
clause.
Index of label in Symbol Table.
Index of model entry for associated END
statement.
Index in Symbol Table of iteration variable.
Index of model entry for associated END
statement.
Index in Symbol Table of iteration variable.
IIndex of model entry for end of THEX
clause.
(Notice there is no entry for the non-iterative DO statement in line 13 of the source code.)
12
PUT
14
13
PUT ASSIGNMENT
PUT ASSIGN:NIENT
14
5
14
14
1""
11
15
16
CALL
CALL PARAMETER
15
15
5
17
CALL_PARA1VIETER
15
12
18
GOTO
16
19
SHORT IF END
17
3
11
20
ITERATIVE END
18
9
21
ITERATIVE END
18
7
22
ELSE
19
?'"'
_0)
I
11
2
Index of Symbol Table entry of file receiving new value.
Index in Symbol Table of first output value.
Index in Symbol Table of second output
value. (This is a dummy entry for the
attributes (bit) of the output expression.)
Index of label in Symbol Table.
Index in Symbol Table of value being
passed as first parameter.
Index in Symbol Table of value being
passed as second parameter. (This is a
dummy entry III Symbol Table that
represents the attributes of the expression
being passed.)
Index of label in Svmbol Table.
IIndex of model ~ntry of associated IF
: statement.
IIndex of model entry of 3&lociated iterative do.
Index of model entry of associated iterative do.
Index of model entry of end of ELSE clause.
EXDAlVIS
Model
Entry
Number
I
I
Entry Type
Source
Code
Pointer
Index to
Model or
Symbol
Table
23
PUT
20
11
24
PUT ASSIG Nl\1:ENT
20
16
25
FULL IF END
20
5
26
27
LABEL
ASSIGNMENT
21
22
3
5
28
RETURN
23
4
29
PROCEDURE-END
24
1
575
Explanation of Index
Index in Symbol Table of file receiving ne"
value.
Index in Symbol Table of first output value
(This is a dummy entry for the attribut es
(character) of the output expression.)
Index of model entry of associated IF
statement.
Index of label in symbol table.
Index in Symbol Table of variable left 0 f
assignment statement.
Index of associated procedure label III
symbol table.
Index of model entry of associated procedure statement.
576
Spring Joint Computer Conference, 1969
Augmented source program
The altered or inserted source statements are italicized to facilitate their recognition.
example program: PROCEDURE OPTIONS (MAIN);
DECLARE
a (10,5) CHARACTER (8) EXTERNAL,
i BINARY FIXED,
switch BIT (1),
search_string CHARACTER ca) VARYING;
DECLARE condition tester RETURNS (bit 1));
GET FILE (input) LIST (switch, search string);
CALL bit_value (switch); /*record new-value*/
CALL character value (search string); /*record
new value*/ IF condition tester (switch) THEN DO; /*record
valu e of if condition*/
CALL goto_issued_from (5); /*record index
of model entry from which control passed
to label*/
loop:
CALL outside do loop; /*record control outside
of do-loop*/ DO i=I to 10;
CALL inside do loop; /*record control
inside of-do~loop*/
CALL binary fixed value (i); /*record
new value*/
CALL outside do loop; /*record control
outside of-do~loop*/
DO j=I TO 3;
CALL inside do loop; /*record control
inside of-do~loop*/
CALL binary fixed value (j); /*record
new value*/
IF condition tester (a(i,j)=search string)
THEN DO; /*record value of if condition*/
PUT LIST (i,i'o+a +ha
ohili+'tT t." l'PQ"hTP "11t. fpprlh!'l.fl1'-'Lv.LJ...&.Vl. ....
\J.J...J..V
.&......, ......
~lJ.1..il.AIlJV
lAII"-'.L.L.L"J
V'OJ
.L"-'IV"-' .... "
'-'
............ "
~rv'_'V .... :It..
dependencies, and multiple path interactions will be
considered later, it would appear that attention could
now turn to the case of a unidirectional pipeline. In
the interest of brevity and intuitive understanding,
a physical analog of an elementary queue offers some
utility.
Consider the conventional pipeline, Figure 1, case 1.
Distance X is defined to be interstation separation,
and does not include the finite station width. The propagation velocity V between stations is assumed to be
positive in the direction shown and non varying. S is
defined to be service time at each station, and includes
the time needed to traverse the station width. Service
time S is analogous to data sampling and temporary
storage in logic pipelines, and X/V corresponds to
propagation delay through logic circuits and intercor..nections bet'v,reen temporaIJT storage latches, as
seen in Figure 2. Under these conditions throughput
rate is:
Rl = 1/ (S
+ X/V)
~
t2;
V-+
2. IDEALIZED MAX-RATE PIPELINE
;&:
•
Q
fl
3. REALIZABLE
MAX- RATE
•
~~X 1+
I
;& ;&
fl
-
(']
,
-,
Figure I-Pipeline queue examples
LOGIC LEVELS ----+
I
2
3
D D D•
•
D• D
D
• •
•
•
•
•
SENDING CLOCK
•
N
•
• •
• •
D-{
D-{
•
•
•
•
•
•
D
D
D
n..
units/second
(2)
Ideal rate R2 is impossible to realize in practice, because of symbol interference caused by path eccentricities. In theory, the rate approaches l/S as eccentricity
is made to approach zero.
In practical circumstances the eccentricity is usually
predictable within acceptable bounds, and can be compensated for in Figure 1, case 3, by the addition of a
separation ~x. Under assumptions that the receiving
station can undergo minor repositioning or phasing
relative to the sending station, the rate becomes:
PIPELINE
~ ~',\;;5;
~::~:~,
(1)
The rate Rl surrunarizes the present level of sophistication in pipeline machine design. Borrowing heavily
from the notion of a communications channel containing many information symbols or bits in transit, onE: is
enabled to visualize the idealized maximum-rate pipeline, Figure 1, case 2. If S includes time consumed in
tra'lersing the finite station \vidth, then ideal rate R2 is:
R2 = l/S
I. CONVENTIONAL PIPELINE
units/second
• •
•
•
•
D-{
Rs
=
1/ (S
+ 6.X/V)
units/second
(3)
If V is a univelsal constant, the velocity of light for
example, its effect could be minimized by reducing the
quantity 6.X/V, where 6.X is intersymbol separation as
distinguished from X, interstation separation. The time
Sin (3) is equivalent to the width of one Nyquist interval, *13,14 and l/S corresponds to the rate of completeness property which represents the maximum input
sequence rate for which any finite state machine can be
built.15 ,16
A maximum-rate pipeline section
The main result of this paper is to apply the ffiaXrate queue concept to a generalized max-rate pipeline
section which may be joined with other max-rate or
compatible-rate sections to construct max-rate systems.
The design of the generalized max-rate section is related
to two characteristics of the continuous data stream,
SL
RECEIVING CLOCK
Figure 2-Generalized pipeline section
* The ~ yquist interval is the minimum useful pulse width
resolvable by logic gates.
M:aximum-rate Pipeline Systems
r
SAMPLE
INTERVAL
t
DATA
R = 1/ (Sample
I
~
~~
SAMPLING
CLOCK
I ~ T + Li ~ D.
~"0l
S T REA M
Combining the results of (4) and (5), the maximum
clock rate R is:
VARIABILITy......
INTERVAL
N
~T + T
R
T~ 1:-'~~.Ji~' --R_-1-J-----J
1
J
--
Figure a-Continuous data stream
Figure 3. The sample interval is a function of the fixed
clock-pulse width, defined to be T, and clock skew
(LlT). Skew LlT is the total range of variability in arrival time of the clock pulse, as observed at the clocked
latch. The clock could be present as late as time T + LlT,
therefore the sample interval width is:
Sample = T
+ LlT
(4)
The variability interval is defined as the time interval
over which one di.screte data arrival occurs, but whose
exact arrival time cannot be predicted, and haH the
time not observable because it is indistinguishable from
the preceding state. The variability interval, observed
at the receiving latch input, is a function of a composite
combinatorial path leading from the sending latch
clock. The variability additively builds up over path
delay (P) through a pipeline section composed of N
logic circuit levels, each with level delay Di, such that
Variability
=
(Ll T
+ P max) +L
LlT
+L
D i)
N
i-I
+ 2 Ll T + L: LlDi)
1/ (T
cycles/second (6)
-
In practice, T can be made to approach One circuit
delay for a one-circuit delay type of latch, Figure 4, and
subnanosecond circuit delays are possible. 17 The latch
is the basic storage cell used in the sample and store
operation. Based on past work5 reasonable values of LlT
are 10 percent/R.
The most significant conclusion is that a summation
of the circuit delay difference at each logic level constitutes the principle term to be minimized for higher
rates. The effects of finite signal propagation times are
thus reducible to arbitrarily small consequences, since
in theory delay could be added to fast paths to minimize
delay differences. Stating the conclusion more abstractly, the max-rate philosophy of design advocates
minimizing differences in naturally occurring absolute
quantities, whereas the classical approach to logic
design has always been concerned with minimizing the
absolute quantities themselves. Each philosophy will
BIPOLAR
CLOCK
N
max
=
SL
P min
N
(LlT
cycles/second
i=I
1--:.
.
+ Variability)
N
~""""""""""""""""""'\j
I
L
min
Di
L Di
i=I
N
LlT
+L
OUTPUT
DATA
l.I
N
])i -
583
(Oi - Di)
i=l
Figure 4-0ne-delay sampling latch
Spring Joint Computer Conference, 1969
584
offer special advantages depending upon technology,
systems goals, and acceptable design constraints.
Data rates and logic-path band'uridth
Clock pulse width depends primarily on circuit delay;
however, variability is dependent on path bandwidths,
which suffer from losses, mismatches, and loading.
Theoretical data rates could approach the Nyquist rate,
2f, where f is the abrupt cutoff frequency of an ideal
low pass filter, approximated by the logic. 14 The minimum width pulse or bit equals one Nyquist interval,
or 1/2f. In the environment a more practical definition
of the Nyquist rate is the maximum signaling rate at
which intersymbol interference vanishes. This implies
full swings, without compromise of noise margins. In
practice the Nyquist rate for a string of gates must be
lower than that for a single gate. This results from
pulse width variation that is not Gaussian in steep-cutoff bandwidth limited systems. These and circuit relaxation effects tend to hasten bit interference, especially for the isolated 1 or 0 bit cases, and could lead to
smearing and pulse pinch-off for marginal rates.
In synchronous systems, where variability is accounted for by retiming, the ideal rate would probably never
exceed half the Nyquist rate of logic gates. If repetitive
clock pulses are funished by a logic gate, the pulse width
could equal one Nyquist interval, but pulses would have
to be separated by one Nyquist interval. Under these
assumptions the maximum realizable rate is:
R =
1/ [2 (T
+ LlT)]
±
= Random jitter for the limiting
cycles/second
(7)
where:
j. T /2
clock case.
IT
+ 2 Ll TI = Sample interval magnitude
ITI
= Variability
interval magnitude
The variability interval is taken to be one Nyquist
interval for this special case, and would prove too
severe for ordinary design purposes. Instead, as provided for in (6), an arbitrarily large variability interval
may be accommodated by a corresponding rate reduction. It follows also that (7) establishes an upper bound
for (6), assuming the pulse portion of the clock system
is implemented with logic gates.
In practice designers empirically arrive at path-bandwidth and analytic approximations, as no present mode
is available at this level of complexity. In the past, design relationships have been derived for each new tech-
nology and associated effects of loading, transmission
line phenomena, and minimum useful pulse width. In
addition to past measures of circuit delay, it is important that future max-rate technology be given additional definitions of performance, Of considerable interest
are the Nyquist rates for worst-case bit patterns, taken
for a continuum of input transition times. This characterization could null out package delay influences that
otherwise appear as additive delay in present measurements. The lead and package delay should be treated
as wire delay which delays computation, but need not
cause a reduction in rate. By similar reasoning a clock
pulse width; on the order of a Nyquist interval, should
not be widened to account for finite lead-package delay
encountered while entering a latch of Lilliputian dimensions compared to the package. A second type of
performance characterization should be statistical
measures of delay variability to account for production
spreads, variable input transition times, and asymmetry
in circuit switching characteristics.
Jfinimizing logic level variability
The throughput data rate approaches the maximum
realizable clocked rate (7) when in (6) :
N
L ADi ---> IT\
(8)
i=l
It is significant that the expression (8) to be minimized
is a summation of artificial differences, as contrasted
with natural barriers such as signal propagation velocity
and combinatorial gate delay through N -1 levels of
10gic between clocks.
A straightforward variability minimization algorithm
is needed if several complex considerations are to be
avoided. Statistical averaging through several levels of
gating must not be used, as this places complex dependencies on all gates in a section. This is hazardous
because in a regular m by n gate array there are m n
paths possible, and these paths could merge mIni
(m-2) 1(2) 1 ways. Any of these mergers, because of delay differences, could have relative bit offsets that
might cause symbol interference at an output. One
algorithm that avoids this complexity is to make each
logic level independent from the others. This can be
implemented by permitting designers to reduce ADi =
fj i - Di on a level by level basis by any means available, but requiring that ultimately a max Di and min
D i be specified for every level. Designers could tailor
each level to achieve maximum speed, or design could
be standardized about a few restricted cases to cover
all situations.
lV~ximum-rate
Wire and loading delay is included at each level.
Only the uncontrolled differences in the circuit-lineloading delay triplet need contribute to 1.lD i. Even here,
longer path routing or more loading may be used to
slow down fast lightly loaded gates. Increases in transition times due to loading are accounted for .either in
increased transmission line delay or increased delay of
driven gates. Parallel line delays such as the six nanosecond delays shown in Figure 5 would not affect the
maximum rate as calculated in (6). In fact (6), along
with the Figure 5 example data shown in Table I.
predicts a 125 MHz clock rate. By contrast, 42 MHZ
results if a summation of maximum delays along with
clock skew is permitted to determine the period of the
clock.
Clock phasing
In order to insure sampling from the nonchanging
portions of bit intervals each receiving station clock
iTH
LOGIC
LEVEL-+-
4
3
2
Pipeiine Systems
585
must be offset from the sending station clock an
amount:
N
Clock offset = (1.lT
+ L: Di)
Modulo I/R
(9)
i=1
This resembles a spatially rippled clock which has been
mentioned. Is This requirement could be met by distributing a global time reference, treated as an independent machine,19 about a 50,000 gate system to within phase differences of say ± 0.2 ns. Next a delay element similar to Figure 6 could be used at each place
where a phase is needed, typically for each 150-300
gate section. A stored or wired address would establish
the phase to be supplied.
Since all phases were assumed to exist in (6) and
actually only p discrete phases are available some reduction in rate becomes necessary. The worst-case
rate reduction need never exceed a decrease of 100 percent/po In reality one would use the a priori knowledge
concerning phasing, and constrain the variability interval, thus the reduction in rate is more a theoretical
entity. Lastly, the most attractive approach toward
realizing some systems is to constrain design such that
(9) meets the zero offset case for all sections. This results in a single phase clock, and the requirement for
multiple phases no longer exists.
Troubleshooting a max-rate system
Troubleshooting and stepping a maximum-rate system has some new aspects. At any time a dynamic path
may contain more bits than storage latches such that
storage is not available for the excess bits, or:
N
Excess bits = R (1.lT
+ L Di)
- 1
i-l
Figure 5-Representative pipeline section
Table I-Example delay data
T I ME _ _-+-I~
REFERENCE
4
2
3
4.1
5.9
4.2
3.0
+ 6.0
OJ NS.
3.7
4.8
3.6
2.7
+ 6.0
~Di
0.4
1.1
0.6
0.3
+
1\
OJ NS.
v
NS.
CLOCK
WIDTH
CLOCK SKEW
T
= 4.0
NS.
~T
= 0.8
NS.
0
Figure 6-Delay with gated phases
(10)
586
Spring Joint Computer Conference, 1969
This bears similarity to a delay line. The point to be
remembered is that max-rate machines possess the complet.e personality of a single phase machine, with no
excess bits, operating at a !mver rate determined by the
max-delay section in the system. Also, to be race free in
this mode a requirement must be met such that:
N
L Di ~ ITI
(11)
i=l
Condition (11) merely acknowledges that one could
perhaps be using a conservative sampling pulse width,
much greater than delay through fast paths between
some latches.
CONCLUSIOKS
It is possible for max-rate pipeline machines to operate
at high rates determined by path differences, rather
than the conventional maximum delay. The results
apply to any technology, but would prove most useful
when signal propagation delays approach or exceed
circuit delay. In this case velocity of propagating signaJs
need not limit rates if paths are equalized. The approach
described would permit increased performance in present systems environments, and would pave the way
for entry into the subnanosecond regime where relatively long transmission lines might exist between
gate arrays.
REFERENCES
M J FLYNN
Very high-speed computing systems
IEEE Proc Vol 54 No 12 December 1966
2 R A ASCHENBREN~ER M J FLYNN
G A ROBINSON
Intrinsic multiprocessing
Proc S J C C 1967
3 R A ASCHENBRENNER
Time-phased parallelism
Proc National Electronics Conferenee 1967
4 G M AMDAHL
"Validity of the single processor apprvach [v achieving
large scale computing capabilities
Computer Design December 1967 and
Proc S J C C 1967
5 L \tV COTTEN
Circllit implementation of high-speed pipeline systems
Prof' F J C C 1965
6 S F ANDERSON J G EARLE
R E GOLDSCHMIDT D M POWERS
The lBi'v} System/SoO Mudd 91.' jluut'iny poinl execution un'il
IBM journal of R&D January 1967
7 D N SE~ZIG
Observations on high-performance machines
Proc F J C C 1967
~ D L SLOTNICK
Unconventional systems
Computer Design December 1967 and
Proc S J C C 1967
H W D LEWIS
111 icrowave logic
Proc of International Symposium on the
Theory of Switching 1957
10 M 0 PALEY
LSI and the large computer systems designer
International Solid State Circuits Conference I96H
11 A R STRUBE
LSI for high-performance logic applicatiQul:l
International Electron Devices Meeting 1967
12 H H LOOMIS JR
The maximum-rate accumulatvr
IEEE Transactions on Electronif' Computers Vol EC-I5
No 4 August 1966
13 J M \VIER
Digital data communications techniques
Proe of IRE Vol 49 January-March 1961
14 W R BE~~ETT J R DAVEY
Data traranllis~,.ion
McGraw-Hill Inc N Y 1965
15 D ~ ARDEN
Delayed logic and finite state machines
Proc of AlEE Symposium on Switching Theory and
Logical Design September 1961
16 H H LOOMIS JR
Completeness of sets of delayed-logic devices
IEEE Transactions on Electronic Computer~ Vol EC-14
~o 2 April 1965
17 D H CHUNG
The design considerations of picosecond integrated
switcMng circuits
SWIEECO 1966
18 B ELSPAS J GOLDBERG R C MIN~ICK
R A SHORT H S STONE
Investigation of propagation-limited computer networks
Final Report Air Force Contract AFI9(628)-2902
Stanford Research Institute Project 4523 1964
19 J HARTMANIS
111aximal autonomous clocks of sequential machines
IEEE Transactions on Electronics Computers Vol EC-l1
No 1, February 1962
Systematic design for modular
realization of control functions
by STANLEY lVI. ALTYIAN and ARTHUR W. LO
Princeton University
Princeton, New Jersey
INTRODUCTION
The feasibility and the problems associated with the
design of asynchronous digital systems have been variously studied and reported;2-6 J. B. Dennis has characterized modular design of asynchronous digital systems in the following manner:l
The structure of an asynchronous digital system
may be divided into the data flow structure and the
control structure. The storage of data, the flow of data
and the operations performed on them take place in
the. data flow structure. The different operations
takmg place concurrently in the data flow structure
are co-ordinated by the control structure.
Each operational unit of the data-flow structure
has, in addition to data links (data input lines) a
control link connecting it to some part of the cont~ol
structure. A control link consists of two wires called
the ready line and the acknowledge line. To cause an
operator to operate on an input, the input is made
available to it (the operator) on the input data link
and a ready signal is sent to it (the operator) on the
ready line of the controJ link. After the operation has
been ~rformed on the output placed on the output
data lInk the operator returns an acknowledge signal
on the acknowledge line. The time difference between
the arrival of the ready signal and the return of the
acknowledge signal is arbitrary and may depend on
the operator, the input, and can even be random so
long as. the acknowledge signal correctly implies
completIOn of the operation.
The control structure consists of control modules
interconnected among themselves and to the dataflow structure through control links. Signals propagate in the forward direction on the ready line.
The direction of a control link is the direction
in which the signals propagate on its ready line.
In addition to control links a control module can
have conditional inputs and outputs. The conditional
inputs convey information about the condition of
some operation or control modules to this module
(and thereby affect the operation of the module),
and the conditional outputs convey the condition of
this module to other circuits.
Dennis has proposed a set of nine control modules
which he has found sufficient to realize all required
control functions (these modules are described in detail
in Reference 9). While he has found it straightforward
to implement control modules without conditional
inputs, Dennis has found the design of control modules
with conditional inputs quite complex.
In terms of hardware design, the operation modules
(building blocks of the data-flow structure) have been
extensively investigated. The design of registers, adders,
transfer devices, and other operational blocks is well
established. On the other hand, the basic properties
and the logical organizatIon of asynchronous control
modules (building blocks of the control structure) has
not been thoroughly investigated.
This paper introduces properties of a class of asynchronous control modules, whose operation satisfy
certain general constraints, and presents a systematic
procedure for designing their logical structure. Included in this class are the modules defined by Dennis.
Although the design procedure is derivable from
fundamental properties of these modules, it is presented
without proof. 9 One result of previous studies is: all
but the UNIO~ module are realizable by simple combinational logic (the UNION module requires a single
feedback loop).
Asynchronous control modules
The purpose of this paper is to present a design tech-
587--------------------------------
588
Spring Joint Computer Conference, 1969
nique for asynchronous control modules. Therefore, it
is necessary that we:
1. Define formally what is meant by asynchronous
control module.
2. Define the class of modules studied; i.e., the
constraints placed on the control module's operation.
3. Define the model used to represent the control
module's operation.
Terminology and notation
The operation of control modules is described in
terms of (i) control links and conditional inputs and
outputs, and (ii) input and output terminals. Every
signal appearing on input and output terminals is
binary; i.e., takes on the value of 0 or 1.
A control link consists of a pair of wires (s ,f); s being
the start line and f being the finish line. Control links
are classified as either input or output control links.
Input control links have their start lines as input terminals of the module and their finish lines as output
terminals of the module. For output control links, the
start lines are outputs and the finish lines are inputs
(Figure 1 is a block diagram of a control module). A
control link is said to be idle if its sand f lines carry the
S9rne bina.ry signal, and it is said to be active if its sand
Control-
Nl
Links
N2
Conditionsl
"1
Inputs
~
".!
1
gl
(a)
,
COtmlOL
I«I)UIE
..
s
N..
Control Links
NS
fS
"3
h1
Conditional
Output
Control lIIOdule showing -cont;['ol links
and conditional inputs and outputs.
~--~-~H~l :::~
Control
Inputs
:
Conditional
Inputs
(b)
conditional
Output
Control module showing input and
output terminal states
Figure I---Generalized block diagrams of control modules
(a) Control module showing control links and
conditional inputs and outputs
(b) Generalized block diagrams of control modules
f lines carry different binary signals. The control link
state (C.L.S.) for a control module with n control links
is an ordered n-tuple
where the state of the k input control links appear to
the left of the slash and the state of the (n-k) output
control links appear to the right of the slash. Li = I if
Si and fi carry the same binary signal and Li = A if
s i and f i carry different binary signals. If every control
link is idle, the control link state is defined to be the
quiesceni siaie.
In terms of the input and output terminals, the
control input state and the control output state are the
ordered n-tuples X = [Xl . .. Xn] and Y = [YI . . . Y n]
respectively. If N i is an input control link, then Xi
represents the state (X i = 0 or 1) of its start line Si and
Y i represents the state (Y i = 0 or 1) of its finish
line f i. On the other hand, if N i is an output control
link, then Xi represents the state of f i and Y i represents
the state of Si.
In addition to control links, a control module can
have conditional inputs and outputs. The conditional
input state, G, and the conddional output state, H, are
the ordered r-tuple G = [G1 ... Or] and the ordered
k-tuple H = [HI . .. H k] respectively. Finally we define
the total input state and the total output state as the
vectors, [X,G] and [Y,H].
Two major differences exist between control links and
conditional inputs and outputs. First, control links
are ordered pairs of wires; one is an input terminal of
the module and the other an output terminal of the
module. No such relationship exists between conditional
inputs and outputs. Second, the state of a link is either
a~tive or idle, whereas the state of a conditional line is
the actual signal it carries.
The control module shown in Figure 1 is used to
illustrate the state notation of asynchronous control
modules. Table 1 summarizes this notation.
General constraints
There are three general constraints which apply to
the operation of each control module unless stated
otherwise. These are:
1. Only one input terminal can change at a time.
2. A control link in its idle state permits a change
in the state of its s line but not its f line. Similarly, a control link in its active state permits a
change in its f line but not its s line.
3. Any change in the conditional input state must
Syste!natic Design for Modular
R~~lization
of Control Functions
!::on
vo..,
Table I-Terminal state notation of control modules
Control Links, L,
Conditional
Inputs
Outputs
Outputs
Nl N2 Ns
N4 N5
Ma
Input lines, Xi
SI
Ss Ss
h f5
Output lines, Y i
ft
fs fs
84
Control Link State:
Control Input State:
Control Output State:
Control Input/Output State:
Conditional Input/Output State:
Total Input State:
Total Output State:
S5
L = (LtLsLs/L4L,l
X = [XtXSXsX4Xsl
Y = [Yt Y s Y s Y 4Y sl
X/Y = [XtXSXSX4X5/YtYsYsY4Y5]
G/H = [G t GS /H 1 ]
where Li
where Xi
where Y i
= I or A
=
=
0 or 1
0 or 1
where Gi = 0 or 1
Hi = 0 or 1
[XIXSXSX4XS, GtGs]
[Yt Y s Y s Y 4Y s, HI]
be completed before the C.L.S. is allowed to
change.
Since the control modules are asynchronous circuits
the design of logic circuits which perform the desired
modes of operation can be carried out by the classical
primitive flow table approach. This approach, however,
proves to be highly inefficient. For example the SELECT module (to be discussed below) is described by
a primitive flow table with 32 columns and at least 16
rows. A more efficient procedure is to construct an
action graph of the control module.
Action graph
The design of a specific control module is derived
from the action graph, which is strongly connected,
representing the step-by-step operation of the module
as described by its word statement. Each node of the
graph represents a control link state, and each directed
edge of the graph represents a specific operation which
transforms one control link state into another.
N odes representing control link states in which the
conditional input state changes are called transfer nodes.
These are the nodes at which decisions are made among
alternative modes of operation.
Every directed edge of the graph has associated with
it a pair of functions (~,(J) where ~ transforms one
C.L.S. into another C.L.S. and (J specifies the affect of
changes in the conditional input state on the operation
of the modules. This ordered pair is called the edge
operator.
The arguments of ~ specify which control input
terminal and which control output terminals undergo
a state change during the transition specified by the
edge. ~(x/Y) operates on both the control input state
and the control output state and therefore can be
decomposed into the input control operator, ox, and
the output control operator, oY; i.e., ~(x/y) =
ox/oy. For example, the control operator ~(Xa/YbYc)
= OXa/OYbYc transforms the control input/output state
[XaXbXc/YaYbYc] into the control input/output state
[xaXbXc/Yal\V c] where Xi and Vi are respectively
complements of X i and Y i.
If an edge originates at a tranfser node, then (J = Gi
where G, is the conditional input state before the C.L.S.
is permitted to change. For an edge originating from a
node where the conditional inputs cannot change, (J
is replaced by a dash (-). If the control module does
not have conditional inputs, then the edge operators
(A,B) reduce to ~.
Whenever a control module has conditional outputs,
every node of the action graph has a unique value of
the conditional output state, H, associated with it.
The method of design is best described by an exam pIe.
Design of the SELECT nwdule
The block diagram of the SELECT module, which
has four control links, one conditional input, and no
conditional outputs, is shown in Figure 2. The function
of this module is to initiate one of two alternative modes
of operation (represented by activating either N a or
590
Spring Joint Computer Conference, 1969
N2
f,IT "
S1
S3
"I
1
v
~)N3
Nl~1
-1
f3
SELECT
MODULE
gl
s4
N4
f4
X3
X
4
SELECT
MODULE
Y2
Y3
Y4
e
(a)
(b)
G1
Ml
(a)
(b)
Figure 2-Block diagram of the SELECT module
N4 ). The operation of the SELECT module follows the
following word statement
,\Vord statement of the SELECT module
1. On receiving a start signal on control link N 1
P start signal is immediately sent on control link
N2•
2. When a finish signal is eventually received on
N2 a start signal is sent on N 3 or N4 according
as the value of the conditional input state, G,
is [1] or [0] respectively. N 3 and ~4 cannot both
be active at the Sallle time.
3. When a finish signal is received from N 3 or
N4, a finish signal is transmitted on link N 1·
The module has now returned to its quiescent
state, and a fresh start signal may now be
received on N 1.
Figure 3-Determination of SELECT module's action graph
Design procedure
The design of the SELECT module begins with the
construction of an action graph. The control module
is said to be in its Q'u.iescent State when all it.R cont.rol
links are idle. The "module remains in its Q.S. until
the input line 81 changes its state (Word Statement 1).
Thus the first step in constructing the action graph is
to draw the quiescent-state node [I/III] as shown in
Figure 3a. A change in 81 causes a change on 82 (Word
Statement 1). This is represented by the directed edge
labeled (1:l.(8J/82),-) as shown in Figure 3b, where the
operation of the module is independent of the conditional input state. The edge operator (1:l.(8d82) ,-) transfers the control link state of the module from the node
[I/IU] to the node [A/ All1 in the action graph. A
change on /2 causes a change on 8s if the conditional
input state is [11' or a change on 84 if the conditional
input state is [0] (Word Statement 2). This is represented
by the edge operator (1:l.(f2/8S) , 1) which transfers the
node [A/All] to the node [A/IAI] and the edge operator
(1:l.(f2/84) , 0) which transfers the node [A/All] to the
node [A/IIA] as shown in Figure 3c. The node (A/All]
is therefore a transfer node. If the conditional input
state [11, then a change onh causes a change on/1 (Word
Statement 3). This is represented by the edge operator [I:l.(js//J) , -) which transfers the node [A/IAI] to
the node [I/III]. If the conditional input state were [0],
then a change on f4 causes a change on /J (Word Statement 3). This is represented by the edge operator
(I:l. (fIJfl), -) which transfers the node [A/IIA] to the
node [I/Ill]. Both cases are summarized in Figure 3d.
The action graph is now complete. A self-loop with the
edge operator (I:l.l(-/-)' -) is drawn on the quiescentstate node. This artifice is introduced for the convenience of later discussion. The operator (I:l.l(-/-)' -),
representing no change of input or output, is defined as
the identity operator.
Simplified action graph
Because of the relationship that exists between the
control input state, control output state, and the controllink state, any two of the variables uniquely deter-
Systematic Design for Modular Realization of Control Functions
.591
mines the third variable. From the definition of the
Control Link State,
As a result, the action graph contains redundant
information. This graph can be simplified by replacing
every control operator tJ.(x/y) by its input component
ox without any loss of information. Figure 4 is the
simplified action graph of the SELECT module.
The action graph indicates that the operation of the
module can be described by a sequence of input operators. We define the directed path operator to be the product of the edge operators that correspond to the directed edges traversed in going from one node of the
graph to another node of the graph. A path which
begins and ends on the same node is called a cycle and
a path operator corresponding to a cycle is called a
cycle operator. Figure 5 illustrates the different cases
that can arise.
The conditional operator (} = Gi . . . Gj~ can be
simplified and replaced by 0 = ~. This simplification,
called the reduced form of 0, is possible because (} transforms any conditional input state into the conditional
input state ~ determined by the last transfer node
encountered, independent of Gi, ... , Gj •
The control portion of the input path operator
(OaObOcOd, 0) can be represented by Oabcd, where the string
of symbols abcd is said to be the argument of O. The
argument of every path operator can be expressed in
terms of a minimal product of the input variables. The
minimal product has the form X~lX~2X43 . . . , where
ni i = 1,2,3, ... is the number of times ni appears in
the argument of ox. If ni is even, then xii produces the
same change as ( -), i.e., no change at all. If ni is odd,
then X~i produces the same change as Xi.
Figure 4-8implified action graph of the SELECT module
-
~
~
(e)
Figure 5-Generalized properties of the input edge operator
An input path. operator is said to be in its reduced
form if every control input variable in the argument of
oappears once or not at all. ·The canonical reduced form
.I: nl n2 113
' . 1 : 81 82 {33
R 1 1'f Xi
of UXl
X2 X3 '" IS uX'l X2 Xs '"
wh ere pi
is present and {3i = 0 if Xi is not present. For convenience the reduced form of ox'11 x~s . . . ~m is identified
as Ok where k is chosen to be the octal equivalent of the
binary number {31{32 ... 13m. 00 is the identity operator 01.
If a control module has n control links, then there exists
2 n .distinct reduced-form operators. The set of 2n
reduced-form control operators is denoted by CR. Since
the SELECT module has four control links, CR contains
000 = 01
= OX4
010
=
OXl
oos
=
oXs
=
012 =
oos
=
OXSX4
01S
=
OX1 XSX4
004
=
=
OXs
014
=
OX1XS
=
OX1 X2 X4
001
005
000 =
007 =
011
OXSX4
015
OXsXs
016
OXSXsX4
017 =
OX1X4
OX1XS
= OX1XSXS
OX1 XSXSX4
At this point several properties of asynchronous
control modules can be introduced. These results are
stated without proof. Unless specifically stated to the
contrary, all operators are assumed to be in reduced
form.
The action graph must be strongly connected because
the module returns to a starting state when its required
operation is completed. In general, this state is the
quiescent state. Every node in the action graph has
associated with it a maximal set of distinct input cycle
operators. For any node ak, denote its corresponding
set of cycle operators by ~k. Also associated with ak is
the set gk, where gk is the set of states that the conditional inputs can assume when the control module is
Spring Joint Computer Conference, 1969
592
in the C.L.S. rerresented byak; e.g., 91 for the SELECT
module is {0,1}.
The action graph of the SELECT module is shown
in Figure 4. Beginning at node al (quiescent node)
there exists a cycle which passes through nodes a2 and
as exactly once. Associated with this cycle is the operator (016,1). Call this cycle Pl. The cycle which begins
at a1 and passes through nodes a2 and a4 exactly once,
has associated with it the cycle operator (016, 0). Call this
cycle p:e. (016,1) and (015,0) belong to 1>1 by definition.
Consider the paths that are fonned by the juxtaposition
of Pl and P2; in particular Pl P2P2 and P2Pl Pl. Associated
with these paths are the operators (016,0) and (015,1)
respectively. These operators also belong to 1>1. It can
be shown that 1>1 contains
{(00.0), (00,1), (os,O) , (os,1), (015,0), (015,1),
(016,0), (016,1)}
This example illustrates the following Theorem.
Theorem 1. If the operator (ai, G j ) e1>k, then the operators (Oi, Grn) e1>k, for all like Grn e9k.
From Theorem 1 set1>k can be partitioned into blocks,
such that each block is identified by a distinct control
cycle operator. Let 1> be the set of distinct control
cycie operators that appear ill 1>k. A second partition
of 1>k can be fonned by grouping together all of the
cycle operators whose conditional input state are the
same; i.e., partition 1>k into blocks 1>k(m) = {1>,G m } for
all G m e9k. 1> is the same for all nodes of the action
graph. In tenns of 1> and 9k, 1>k is represented by 1>k
= {1>,9kl. If the control module does not have any
conditional inputs, then the maximal set of distinct
cycle opera.tors for every node of the graph is ~.
Consider a control module with n control links and r
conditional input states, G1 , . . . , Gr. ffic denote the
set of r(2n) distinct reduced form input path operators ffi(l), ffi(2),. , ., ffi(r) where CR(i) = {R,Gd for
i = 1, ... , r,
Theorem 2. The simplified action graph partitions eRG
into the kr blocks of input path operators {Dj(i)}
for i = 1, ... , r.
The sets Dj(i), CR(i) and CRG satisfy the following relationship
1
= 1, ... ,
and
CRG
=
{CR(I), CR(2), .. "CR(r)}
If each block, Dj(i), contains m distinct input path
operators, then k, and m satisfy the relationship
km = 2n , k = 2nl, m = 2n2, and nl and n2 are positive
integers such that nl
n2 = n, for i = 1, ... , r.
The set 5) can be determined usirlg signal fio,\v' graph
theory7,8 (see Appendix). Since 1> is independent
of G only the control input operator portion ai, of the
input. pat.h operat.or need be Rhown on the simplified
action graph. Figure 6 shows the determination of 1> for
the SELECT module, From Figure () 1) ,vas found
to contain
+
1> =
{ooo,
003, 015, 016} .
Corollary 1: The input edge operator (op,O), trn,nsf()rm~
the bloek of input. pa.th npernt.ors 1)1 (k) = {D f,Gk }
into the block of input path operator ))j(r) = {Dj,Gr },
Case 1: Thl: node a is not a tra.nsfer node, () = (-)
[Di(k)] (op,-):: lJ)i'~} (op,-)
- Dio p , G k }
{Dj, Gk }
Dj(k)
where D j is the reduced form of D,op.
°00
i = 1, ... , r
j
=
1, ... , k
where
Dl (i) = 1>(i)
Ds(i)
=
(Oa,G j ) 1>(i)
(e)
(Oc,Gi ) $ {1>1 (i)
+. -.+ Dk""l(i)}
l'
(i'igUl'e 6-Determination of :D for the
SI;~LI'~CT
module
Systenlatic Design for !vlodular Realization of Control Functions
Case 2: The node a is a transfer node, () = Gr
[Di(k)] (op,Gr ) = {Di'~} (op,Gr )
:: I
Diop,GkGr }
Dj,Gr }
= Dj(r)
Theorem 2 states that the action graph partitions
the set of all possible control operators into k blocks,
each block containing the same number of elements.
One of these blocks is ~. If ~k is known for any node
ak, then the maximal set of distinct path operators
associated with the directed paths from node ak to
every other node in the graph can be computed as shown
in Corollary 1. The assignment of blocks from the partition of ilia to the edges of the graph provide the basis
for (i) deciding if the module is realizable by combinationallogic, and (ii) constructing the Karnaugh Maps
used to design the module's logical structure.
Theorem 3: A control module is realizable by a combinational circuit if and only if every block, Di(k), appears
at most once in the action graph, with multiple appearance occurring only on edges incident on the same node.
An action graph which satisfies these conditions is said
to be a Type I action graph.
The design of the SELECT module can now be completed. Using ~ to compute the partition on ill, we find
Dl = ooo~ =
D8
=
004~
{ooo, oos, 015, 016}
=
{004. 007, 011, 012} where
004EE{DI+Ds }
D4 = 005~ = {005, 006, 010, 018} where
005
where the operator
EE
{D1
+ D2 + Ds}
"+" is the union or sum operator.
The action graph of the SELECT module partitions
ffic into the eight blocks
DI (O)
=
Ds(O)
= {Ds, O}
Ds(1)
=
{Ds, I}
{D", O}
D,,(I)
=
{Ds, I}
Ds(O) =
{D1 , O}
D 4(0) = {D4' O}
the following blocks of input path operators being assigned to the edges of the action graph
Edge Connecting
Xode to Xode
-
D I (I) = {DI, I}
593
Block of Input Path Operator
Assigned to Connecting Edge
aI -7a2
(010,-) {D1 (O),Dl (1)}
=
{D4(0),D4(1)}
-7 as
(004, 1) {D4(0),D4(1)}
=
{D2 (1)}
a2
as -7.a4
(004, 0) {D4(0),D4(l)} = {D2 (0)}
as -7 al
(002,-) {D2 (1)}
a4 -7 aI
(001,-) {D2 (0)}
{DI (1)}
=
=
{D1 (0)}
This assignment is summarized in Figure 7.
From Figure 7 the SELECT module is found to
satisfy Theorem 3 and is therefore realizable by a
combinational circuit. It should be noted that up to
this point the description of the operation of the control
module and the determination that it is realizable by
a combinational circuit has been accomplished independent of the binary (0 or 1) values that appear at the
control module's inputs and outputs. However, the
logical design of the control module in terms of a complete set of logical primitives connectives must refer
to the total input/output states. For our design we
shall assume that one of the quiescent input state is
[00,0].
Using the total input state [00,0] the block of total
input states and the corresponding block of control
output states associated with each node in the action
graph are computed and summarized in Table II.
Table II -The control link states and the total
input/ output states of the SELECT module
TOTAL INPUT
STATES
J1 (0):{ (00,03,15,16) ;o}
JI (l):{ (00,03,15,16) ;1}
Js(O):{ (01,02,14,17) ;o}
J,( 1): {(01,02,14,17) ;1}
J 4(0): {(05,06,10,13) ;O}
J 4(1):{ (05,06,10,13) ;1}
PRESENT
TOTAL
COXTROL
OUTPUT
LIXK STATES STATES
al :[I/IIIl
at :[I/III]
a4:[A/IIA]
a,,:[A/IAI]
as:[A/ AIl]
as:[A/AIl]
Zl :{00,03,15,16}
Zs:{OO,03,15,16}
Z,,:{ 10,13,05,06}
Z4:{ 13,10,06,05}
Z5:{11,12,04,07}
Z6:{ 1l,12,04,07}
D 4(1) = {D4' I}
Assigning the set of input path operators, {D1 (0),
D I (1)}, to the self-loop of the quiescent node, results in
Since Ds(O) and D,,(l) do not appear in the action
graph the cells in the Karnaugh }Iaps identified by
594
Spring Joint Computer Conference, 1969
(expressed by the Karnaugh 2\1aps in Figure 8) satisfy
the word statement that describes the SELECT
module's modes of operation. These Karnaugh Maps
can now be used to construct a hazard-free combinational circuit realization of the SELECT module which
satisfies given cost, fan-in, and fan-out constraints.
CONCLUDING REMARKS
Figure 7-Assignment of input path operator blocks for the
SELECT module
0
5 1 f2
00
0
1
1
d
1
d
1
01
0
1
0
1
11
0
d
0
d
10
0
(a)
10
1
0
1
d
1
0
1
0
1
0
1
d
0
1
0
f1
0
0
0
0
5 1 f2
00
0
0
0
0
d
0
d
0
01
d
0
d
0
1
1
1
1
11
1
1
1
1
1
d
1
d
10
1
d
1
d
(b)
52
As indicated in Theorem 3 the action graph of a control
module realizable by a combinational circuit is classified
as Type I and it has the property that every node has
a unique set of operators associated with it (block of
operators assigned to the edges which terminate on the
node). In terms of the action graph there are two cases
in which a control module requires internal memory to
periorm its specified function.
Case 1 : Every edge that has the same block of distinct
operators assigned to them are incident upon distinct
nodes. Such an action graph is classified as Type II.
Case 2: More than one edge originating from node
(Xi has the same block of operators assigned to it, and
the nodes they terminate on are distinct. Such an action
graph is classified as Type IlL
Although both Type II and Type III action graphs
require internal memory, they can be designed directly
from the action graph by (i) converting Type III graphs
into Type II graphs, and (ii) converting Type II graphs
into Type I graphs. The algorithm for performing the
conversions are straightforward, but are too lengthy
to be presented here. The algorithms are described in
detail in Reference 9.
01
11
10
11
10
0
1
1
5 1 f2
00
01
0
0
1
1
0
01
d
0
d
1
01
d
0
d
1
ACKNOWLEDGlVIENT
11
0
0
1
1
11
1
0
0
1
10
0
d
1
d
10
0
d
1
d
The authors would like to express their appreciation to
Dr. John Bruno for many helpful comments. This work
was partially supported by the National Science Foundation.
(e)
53
10
10
0
0
1
1
5 1 f2
00
0
1
1
0
d
1
d
0
01
d
1
d
0
1
1
0
0
11
0
1
1
0
0
d
1
d
10
0
d
1
d
(d)
51j.
Figure H-Karnaugh maps of SELECT module
Js(O) and Js(l) have "don't care" (d) entries (see
Figure 8). It should be noted that the octal equivalent
of the control input states belonging to J i(j) are the
octal subscripts, k, of all the Ok E Di(j).
The Boolean functions relating the output variables
11, S2, Ss, and S4 to the input variables 81, f2, fs, 14, and g1
REFERENCES
1 J B DENNIS
Computation stru..cture (lecture notes)
COSINE Committee Lecture Series July 1968
2 D E MULLER W S BARTKY
A theory of asynchronous circuits
The Annals of the Computation Laboratory of Harvard
University 1959
3 G ESTRIN
Organization of computer systerns-fixed plus variable
stru..cture computer
Proc W J C C 1960
4 G ESTRIN B RUSSELL
R TURN
J BIBB
Parallel processing in a restru..cturable computer system
IEEE Transactions of Electronic Computers 1963
Systematic Design for Modular Realization of Control Functions
5 W A CLARK
M acromodular computer systems
Proc S J C C 1977
6 S M ORNSTEIN
a,
(-J~
ab
M STUKI W A CLARK
A function description of macromodules
Proc S J C C 1967
7 S J MASON
Feedback theory-some properties of signal flow graphs
(b)
J9 -
~
-
595
~
C1
1
C1
j
~
1
j
Proc IRE 1953
8 J A BRZOZOWSKI E J McCLUSKEY
Signal flo'w graph t.e.chniq1l-BS for serp..!-Bnt'l"al circuit state
diagrams
IEEE Trans on Electronic Computers 1963
9 S M ALTMAN A W LO
The properties and design of asynchronous control modules
Princeton University's Computer Science Laboratory
TR No 711968
APPENDIX
Determination of ~ from the simplified action graph
~
can be determined directly from the action graph
through the use of signal flow graph theory.7,s If all the
nodes but one are removed from the action graph, then
the path operators appearing on the self-loop of the
remaining node, when starred, yields ~. The essential
operations performed on the graph are summarized in
Figure 9.
The "*,, operator shown in Figure 9 has the following
properties :
Figure 9-8ignal flow graph reduction rules
2. (aa
+ ab)* = aa + (aa + ab) + (aa + ab)'
= a + aa + ab + aaab + (aaab)' + ...
= a + aa + ab + aaab
o
o
Optimizing floating point arithmetic
via post addition shift probabilities
A
~
by JANIES A. FIELD
University of Waterloo
Waterloo, Ontario, Canada
INTRODUCTION
In many computers floating point arithmetic operations
are performed by subprograms: software packages in
the case of most small computers, and micro-programmed read -only memories in some larger systems.
In such a subprogram there are normally several free
choices as to which set of conditions gets a speed
advantage. If this advantage is given to the most
probable case then there \~ill be an increase in system
performance with no increase in cost.
One area in which this type of optimization is possible
is in the processing of binary floating point addition and
subtraction. Here there exist two possible shift operations, first to align the binary points before addition or
subtraction, and second, to normalize the result. In
processing these shifts there are several options as to
method, and sequencing of operations within a given
method. To choose the variation that optimizes the
program it is necessary to know the probability of
occurrence of the various length shifts possible.
Sweeneyl has reported experimentally determined
distributions for shift lengths in alignment and normalization. Unfortunately the data for normalization was
presented as total values. Subprogram optimization
requires normalization shift length probabilities given
that a specific alignment shift occurred.
This paper presents a method for estimating the
required probabilities, and an example of their application in subprogram optimization.
It will be assumed that in all other bits there is equal
probability of a one or zero. Appendix A gives the
reasons for this assumption.
For purpose of analysis the addition operation can be
divided into five cases. These are considered in the
following sections. While only the addition operation
will be specifically considered, the results are also
applicable to subtraction as it is just addition with the
sign bit complemented.
The following representations for shift length probabilities will be used:
P _l-the probability that a one bit right shift is required
for normalization.
Po-the probability that no nonnalization shift is
required.
Pi-the probability that an i bit left shift is required
for normalization (i > 0).
Like signs" equal exponents
When the numbers have equal exponents they may
be added immediately since no alignment shift is
required. With the leading bit of both words being a one,
the sum will always contain (n + 1) bits. Thus a one bit
right shift will always be required to normalize the result
of the addition. Therefore
(1)
Like signs, unequal exponents
Shift length probabilities
A common representation of the fractional part of a
floating point number is a sign bit plus a normalized n
bit true magnitude. This form will be used in the
analysis. The form of the exponent is not of concern.
In normalized numbers the leading bit is always a one.
When the exponents differ the smaller number must
be shifted right until the binary points are aligned.
Figure 1 shows the situation after the alignment shift
of s = (n - m) bits has taken place. The x's indicate
bits that may with equal probability be either one or
zero. A (n + 1) bit result will occur, requiring a one bit
-----------------------------------------597 ----------------------------------------
598
Spring Joint Computer Conference, 1969
Now, with
I;-~-li-~"""II-----+I-~-+I-~-+I-:+I--+I +-1:--tl::~: :
Pr(C l = 1) = R/2
x-x
b=~~======~4=~~----~~2~1~
n n-I
m
where
R = 1 for systems where word B is rounded
after alignment, and
Figure I-Numbers following binary point alignment
right shift for normalization, if and only if there is a
carry into bit n.
Defining
R = 0 for systems where word B is
truncated after alignment it
follows that
Aj = jth bit of word A
B; = j th bit of word B (after binary point alignment)
1
~ .
P -1 = Pr(Sn+l = 1) = Pr(C" = 1) =
C; = carry into jth position
S; = jth bit of unnormalized swn
+
Then
Pr(Cj+l = 1) =
=
!
+ ~ Pr(C
[1 - Pr(C j = 1)]
! + ~ Pr(C; =
1
_1_
= 2 - 2 i+l
+
j
= 1)
R - 1
~
; n > s 2::
1 (3a)
If there is rounding, overflow can occur for an
alignment shift of n bits if word A is all ones, hence
P -1
R
= Pr(Sn+! = 1) = 2,,-1
;s = n
(3b)
1)
If the exponents differ by n (n + 1 when rounding)
or more then no shifting is required since the larger
number is the result. Hence
Pr(C1 = 1) ;
---=-2'-:-'---'-m -
1
2:: j 2::
1
(2)
P-1
=0
;s
>
n
(3c)
and, since Bm = 1,
Pr(C",+!
=
1) = ~ [1 - Pr(Cm
= 1)]
+ Pr(C
m
= 1)
In all cases the only alternative to a one bit right
shift is no shift, therefore
;s
~
1
(3d)
= ~ + ~ Pr(C", = 1)
Unlike signs, equal exponents
If the alignment shift was one bit then Cm+! is Cn.
However, for alignment shifts greater than one bit, only
if all bits An- 1 through Am+! are ones will a carry
1) th to the nth bit.
propagate from the (m
+
Hence:
;m=n-l
Pr(C" = 1) = Pr(Cm+l = 1)
1.-1
=
Pr(Cm+l = 1)
r
Pr(A j = 1)
;m
< n-
;m:::;n-1
In Figure 2 is shown a tabulation of all possible
combinations of two n bit words with unlike signs. If all
bits but the most significant may be one or zero with
equal probability it follows that all the combinations
listed in Figure 2 are equally probable. Thus to obtain
the probability of having exactly i leading zeros after
forming the sum requires only that the number of such
sums be counted.
When the sum is zero no shift is required, while a sum
with i leading zeros requires an i bit left shift tor
normalization. Hence
Po = Pr(zero result)
=
1
2-1
(4a)
Optimizing Floating Point Arithmetic
1111
-1111
0000
1111
-1110
0001
1111
-1101
0010
1110
-1111
-0001
1110
-1110
0000
1110
-1101
0001
1111
-1000
0111
1111
-1001
0110
n m
1110
-1000
0110
1110
-1001
0101
I:
I: I~ I: 1
599
1X 1xX 1Word
A
WordS
X
2
I
Figure 3-Numbers follo",;ng binary point alignment and one's
complementing of word B (exponents differ by one)
and, since Bm = 0)
Pr(Cm+l = 1) = ~ Pr(Cm = 1)
1001
-1111
-0110
1001
-1110
-0101
1001
-1101
-0100
1001
-1001
0000
1001
-1000
0001
1000
-1111
-0111
1000
-1110
-0110
1000
-1101
-0101
1000
-1001
-0001
1000
-1000
0000
Figure 2-Array of all possible eombinations of two n-bit
normalized numbers with unlike signs and equal exponents
(n = 4)
(5)
Pr(8 n = 1) = Pr(Cm+l = 1)
Hence
Pr(Sn = 0) =~_l-R
4
and for non-zero results
Pi
=
For the first i bits of the sum to be zero requires that
Cn - i +1 and Am be zero, and for i greater than two, that
Am-I, Bm- 1, • . • , An-i+l, B,..-i+l also be zero. Thus
2
Pr(exactly i leading zeros) = 22 (n-U
2n-
i_
L:
Pr(Sn = 8 n - 1 = ... = Sn-i+l = 0)
1
(2 n- 1
-
j)
= Pr(C n -i+l = 0) Pr(Am = 0)
i_2 4 - i - 1
; i = 2
131
= 2'-1
2ft
(1 - 2i+l
+ 2ft )
;
1
=s; i <
n
(4b)
m-l
= Pr(C n -i+l = 0) Pr(Am = 0)
Unlike signs, exponents differ by one
i=n-i+l
This case requires that the smaller nlunber, after the
alignment shift, be subtra(}ted from the larger number.
This subtraction may be considered as the addition of
the one's complement plus one in the least significant
position. The bit alignments are shown in Figure 3. It
can be seen that there will be at least one leading zero
if Cn = O.
Considering the extra one added into the least
significant position as a carry yields
Pr(CI = 1)
=
1 - Rj2
where R is defined as before, and since Equation 2
applies,
Pr(C';+1
~
=
1)
1- R
= 2-1 + - .m
21+1'
II
..
- 1> ]> 1
Pr(A j = 0) Pr(B j = 0)
;2 n
(7c)
As the only alternative to a one bit left shift is no
shift
(7d)
(6c)
Application
Unlike signs, exponents differ by more than one
This case is very similar to the previous one, and can
be analyzed by the same method. The bit layout after
binary point alignment is shown in ~igure 4. It can be
seen that Equation 5 is applicable.
Only one leading zero can be produced, since to obtain
a leading zero AIt- 1 = 0 and Gn- 1 = 0, and thus 8 11 - 1 =
B,,-l = 1. Hence no more than a one bit left shift will be
required for normalization.
If Cm +1 , or any of An-I, ... , Am +1, is a one then Cn = 1
and 8 = 1.
ft
In Table I is a tabulation of the probabilities given by
Equations 1, 3, 4, 6 and 7 (assuming that 2-n is
negligible). As an example of how these probabilities can
be used to optimize subprogram operation the addition
of numbers with unlike signs will be considered.
Table I-Probability Pi of an i-bit normalization shift
after an s-bit alignment shift
alignment shift
s
Therefore
like signs ......
ft
A.n+l
= 0) Pr(Cm +1 = 0)
0
1
~+l
2
3
; 2
S sS n
(7a)
A shift of n bits ran produce a leading zero when word
I:::I=~:I=====:I=~:I=~:I=: ====:1 ::I::~: :
n n-I
m
:1
1
0
1
4
1 (34 - l-R)
= 2n- m - 1
unlike signs
__,~I~~~L~I~I~I~_6
PI = Pr(Sn = 0) = Pr(C = 0) = Pr(A,,_l
= ... =
I
4
5
3
1
1
1
4
4
4
2
3
8
3
16
3
32
3
64
5
8
13
16
29
23
61
5
8
13
16
29
32
61
3
8
3
16
3
32
64
64 64
5
16
3
16
13
64
3
64
29
256
3
256
61
1024
3
1024
3
I I
:==1
2
I
Figure 4-Numbers following binary point alignment and one'R
complementing of word B
For computers with ~ "shift-and-count" instruction
for normalizing a number and counting the leading zeros
a relat.ively st9!nda.rd subprogr9,ffi is shown in Figure .5a.
Optimizing Floating Point Arithmetic
All normalization is done using the "shift-and-count"
instruction.
From Table I it is obvious that in many cases a one
bit left shift would be enough to normalize the result,
with a correspondingly simpler and faster exponent
adjustment routine. In most machines, however, there
is not a direct test for a single leading zero, and a
programmed test loses any speed advantage that use
of the one bit shift would gain for this special case.
For machines with a fast one bit shift Figure 5b
presents an alternative philosophy: try a one bit shift
and if unsuccessful proceed with the "shlft-and-count."
It is anticipated that enough time ~ill be saved on
single leading zero cases to compensate for the loss of
time on the multi-leading zero cases.
t!n1
vv~
To analyze the relative merits of the normalization
schemes of Figure 5a and 5b define
r-time to process result with no leading zeros
a
+
bi-time to normalize a number with i leading
zeros and process the result
c-time to shift left one bit and check if
result is normalized
d-time to process result after successfully
normalizing via a one bit left shift
For Figure 5a the average normalization time is
7i
Tel = rPo
+ L: (a + bi)P ..
i-I
no
yes
A:ro........ ,only required
yes
" I ? . . . . . . when rounding done
~~-....,.-..;..--< resu t.
,> in add operation
""
no
yes
(c)
(a)
(b)
Figure 5-Possible subprograms for adding numbers with unlike signs
602
Spring Joint Computer Conference, 1969
while for Figure 5b it is
Tb = rP o + (c
+ d)
11
PI
+ I: [c + a + b(i
- 1)]P i
i=2
= Ta
+
(c - b) (1 - Po)
+
a) PI
(d -
It is evident that T b may be greater or less than T a
depending on the machine characteristics controlling
a, b, c and d.
For a floating point addition subroutine (with n = 18)
for a PDP-9 computer it was found that a = 15.6,
b = 0.4, c = 4 and d = 7. These produce the values for
Tb shown in Table II. The second method is best for
non-equal exponents but the first method is best for
equal exponents. Since the information on whether the
exponents were equal is available, the subprogram can
be modified to the form shown in Figure 5c. This gives
the advantages of Figure 5b to non-equal exponents, but
retains the advantages, and improves on, Figure 5a for
equal exponents. While an exact measure of the
improvement in the normalization is impossible without
the knowledge of the alignment shift distribution it
would appear as if Figure 5c is about 3% better than
Figure 5a.
Execution time of subprogram in Figure 5b.
be exploited to reduce subprogram time. The table of
probabilities allows him to check if the technique
devised does yield the expected benefit of a faster
program.
REFERENCES
1 D W SWEENEY
An analysis of floating-point addition
IBM Systems Journal Vol 4 No 1 1965 :n-42
2 R WHAMMING
Numerical methods for scientists and engineers
McGraw-Hill New York 196237
APPENDIX A·
Assuming equal probability of one or zero in all bits
but the first implies a uniform distribution of numbers.
However, Hamming2 indicates that during floating point
calculations numbers tend to move towards the lower
end of the normalization range.
Using the Hamming distribution
1
P(x) = - x In 2
then the probability that bit A 1I - i equals one can be
calculated by integrating the probability distribution
over the range of numbers for which A lI - i is one.
Table II-Execution time of subprogram in Figure 5b.
alignment shift
o
1
2 or more
T]
Pr(A_ i = 1) =
-1
I:
i>=O
+
Ta
1.45
Ta - 1.60
Ta - 5.00 PI
1
--
I-i/2' - 1/21+1 X
(2II-1
dx
In 2
rl
=
I
-In
In2
1
i>=O
2,+1 - 2i )
21+1 - 2i - 1
2(2i ) (2 i 03
= -In---In2
(2 i+1 !) (2,-10 2
SUMMARY
In the example above it is unlikely that the second
method would have been considered if the table of
probabilities indicating the high incidence of only one
leading zero had not been available. Since the final
subprogram is an improvement on the second method
to eliminate a flaw detected during timing calculations,
it is reasonable to assume that the best subprogram
would not have been evolved without the use of
normalization shift probabilities.
It must be remembered, however, that Figure 5c is
the best for a particular machine. The only data that is
directly applicable to another machine is the table of
probabilities. It is still necessary for the designer to
deduce a method where specific machine features may
II-ilt
i
1-1
2
Using Stirling's formula
In x! = In
V2r + (x + ~)
In x - x
where 0
fJ
+ I2x
< fJ <
1 ;x > 0
the above expression reduces to
=
~
+ Z-i 4> ; -
.541
< 4> <
.361
Optimizing Floating Point Arithnletic
Thus the probability converges to ~ as j increases.
Table III shows the actual Pr(A i = 1).
In view of the rapid convergence to a value of ~,
and that the maximum deviation from ~ is not large,
it seems reasonable to assume that ones and zeros are
l1 -
603
equally probahle in all hit positions. Using the actual
values from Table III for the first fmv bits would
greatly complicate the model without significantly
altering the result.
Table III-Pr(An - i = 1) assuming Hamming
distribution
Pr(A1. -i = 1)
-------------------------1
0.415
0.456
2
0.478
3
4
0.489
0.494
5
0.497
6
A panel session-Software transferability
Program transferability
by JAMES A. WARD, Cha'irman uf Session
Department of Defense
Washington, D. C.
During the early development of higher order languages in 19.59, we were told that programs written in
such languages could be run on almost any computer.
Now, ten years later, we find that programs so written
not only are non-transferable from one manufacturer's
computer to that of another, but, in some instances,
caIUlot be run on two computers of the same make and
model wIth memories of different sizes. In the intervening years, computers have become much faster and
the cost per operation has become much cheaper, while
the cost of programming has become relatively far more
expensive. Still, we do not have program transferability
and millions of dollars are spent each year on the uninspiring task of reprogramming routines on additional
computers.
The objection to transferability of software is that it
is impractical: programs transferred would operate
very inefficiently because of different internal machine
organizations. Data is particularly difficult to transfer
onto machines of different.word length. If such transfers
are made there is loss of efficiency. A system that would
provide for such transfer would unduly restrict the
freedom of the programmer and introduce inefficiencies.
This is why in many military systems all the computers are required to be identical, or in the same
family, so that programs written for one computer can
be used on all and that programs and data can be transferred. The current procurement for World-Wide
Command and Control is just such a system. The lack
of transferability also makes the upgrading of a computer a traumatic ordeal for almost any computer
installation in government or industry. A number of
people who have recently gone through this to obtain
third generation equipment seem to think that the
government (or DoD) should freeze present hardware
designs to prevent reprogramming for the fourth gen-
eration of computers. They seem to forget that this is a
perennial request. I was asked to join such a movement
over six years ago and this request has been repeated
every year thereafter. Had this movement been successful, the current third generation would not have come
about.
The design of digital computer hardware has made
tremendous strides during the past ten years. Further
advancements are forthcoming throughout the field,
particularly in military computers and scientific computers designed for large government problems. I feel
it is criminal to stifle advancement; therefore, I do what
I can to encourage new designs and internal organizations.
But we still need the compatibility among different
machines that will permit the efficient transfer of programs, data and programmers from computer to computer without reprogramming. Since the hardware
design should not be unduly restricted, the compatibility necessary for transfer must in large part be provided
by software. I feel certain that this will eventually
evolve. In fact, I am happy to report that progress
toward solution is already on the way:
a. The Air Force at Rome Air Development Center
has initiated an Rand D program to determine
requirements for software transferability.
b. Dr. Hopper, in the Xav'Y, has developed a standard COBOL by which programs in that language
have been compiled and executed on many
different machines.
c. ~Iitre Corporation, under DOD contract, is
studying the problem of transferability of data.
d. There are also several laboratories with different
manufacturer's machines in which any program
written can be compiled and executed on any
machine.
605-----------------------------------
606
Spring Joint Computer Conference, 1969
I am convinced that such transferability of programs,
data, and programmers is within the present state-ofthe-art. This panel from government and industry has
peen assembled to tell what has been done and 'what is
planned.
Let us all cooperate to hasten the day when most programs written in any higher order language can be compiled and executed on most existing computers. The
time, money and manpower saved by eliminating reprogramming can then be used to solve other more
interesting and useful problems.
ferabOlo
..
11"Y
1>
... rogram ..."rans
by ROBERT W. BEMER
General Electric Company
Phoenix, Arizona
General
The problem of program transfer is such that most
people think they understand the process better than
they do. Optimism is rampant; success is elusive. I
have some tenets which I believe to be sine qua non:
• Program transfer is complicated by each element
which is different-user, CPU, configuration,
operating system, etc.
• Programs must be planned for transfer. "Afterthe-fact" is virtually useless, like post-classification
for information retrieval. The information loss is
too high in the transfer from programmer to code.
If everyone wrote and documented his program as
a connectable black box, only the connecting
process would need to be under the control of the
user.
• In twelve years of hearing proponents discuss it,
I have not yet seen successful mechanical translation of machine language programs. There are the
processes which a translator:
a. Thinks it can do and can.
b. Thi.."'1ks it can't do and says so, for human
rework.
c. Thinks it can do and can't, and therefore
doesn't say so!
• Transfer should always be made on a source
program basis. Recompilation is a trivial expense.
• To the highest possible degree, the documentation
of the program should be self-contained in the
source program itself (rather than in the auxiliary
documentation), and in a standard format and
placement so that mechanized program tools know
where to find the machine-readable infonnatioll
for extraction and use.
• Production of identical answers is (particularly for
scientific problems) an additional requirement
which must be specified and paid for. Differences
may be due in part to differing internal arithmetic
modes, but more often they are due to the overlooking of imprecision in method. On balance,
obtaining different answers must be considered a
healthy phenomenon.
• The criterion which a software module/component
must meet in order to be Relf -documented adequatelyis:
'.'Can it be dropped into a program/data
base for problem brokerage, whereupon a
completely anonymous user may make a
mechanical search to his requirements, find
and use the module in his problem, and pay
automatically a brokerage fee upon successful usage?"
This would be one standard that nobody would argue
about-if he got found money at the end of the month,
for conforming. Perhaps this might be a better solution
than patenting software. Only thus can the non-specialist take advantage of computer utilities.
Some information required to transfer (run) a programl
• Program name (number)
Program function
Descriptors, classification (computing reviews)
• Original computer system
Original configuration, subset of required configuration, options used/available
Other systems/configurations verified to rUll OIl
• Operating system, requirement, linkages, interfaces
Running instructions
Store requirements (resident program, nonresident
program, data, tables, segmentation, overlay
sequences)
• Source language (standard, dialect)
• Input/output data
Data structures
Data types
Data elements, collating sequence
(1) To complete while producing the program.
Software Transferabiiity
• Interfaces (other units called, libraries)
Connections (via jumps, switches, natural flow)
Languages/processors equipped to call this program
• :~VIethod, average runtime (for interactive simulators)
Restrictions, constraints, degenerate cases, idiosyncrasies
Range, accuracy, precision
Changes occurring in conditions, status, original
input
Optional
Infonnation specific to program transfer
Default options-referring to international/national standards
Responsible organization
Grade of program (thoroughness of testing)
Test cases and answers (possible autoverification
and answer match)
Bibliography, references
Copyright, price, etc.
Source/object program listing, number of instructions/statements
Mechanical tools for converswn2
• Combinatorial path exercisers through a program
• Programs which page the source code for the programmer and mechanically force him to be up-todate
• Programs which mechanically check the linkage of
units of a software system to provide a directed
graph for flow verification, ensuring that any software unit will not interface with other software
units to which it should not be connected .
• l\1"echanical detennination of valid paths in the
reverse direction of flow, as a diagnostic tool for
finding "How did we get here from there?"
• :Mechanical verification of successful meeting of
interface requirements when passing from one
software unit to another in a forward direction.
.l\1"echanical re-verification of linkage and interface requirements for any revisions.
• Code acceptance filters .
• A patch defense (correct/change ill source code
only)
• (De-) fiowcharters
Mechanical capture of facilitating information 3
The source-to-object program translation process
(2) Used during the completion stage of the program, to prepare
against transfer problems and to ensure a well-conditioned state.
(3)To obtain in each use of the program.
607
yields illfonnation. }luch of this is lost, but needn't be .
Some of this infonnation concerns elements which are
not themselves standardized, but can be part of a standdard list of measurements useful to program transfer.
Therefore a language processor should be constructed:
• To be self-descriptive of its characteristics (i.e.,
features contained, added or missing; dialects or
differences) .
• To afHx to the original source program, as a certification of a kind, either an identification of, or its
actual characteristics. It may also strike characteristics or features which were unnecessary for that
source program.
• To inspect transferred programs for a match to its
own characteristics.
If the transferred program is processed successfully:
• The identification of the new processor is also
affixed to the source program.
• In any area where the new processor has lesser
requirements (i.e., a smaller table worked successfully; a missing feature was not required), the affixed infonnation is modified to show the lesser requirement.
Thus a source program, once processed, contains
infonnation on:
• The minimum known characteristics required for
successful processing.
• All processors (with operating systems) which treat
the source program successfully.
Software compatibility
by JOHN A. GOSDEN
The Mitre Corporation
McLean, Virginia
Data Exchange
There is a growing need for data exchange, particularly the passing of files of data between programs that
were produced independently. This will be needed in the
development of computer networks and data bases; for
example, a head office installation collecting files from
various divisions of a corporation to build a data base.
Both the development of formal and informal computer
networks as well as the economic feasibility of large
608
Spring Joint Computer Conference, 1969
data bases are favoring the development of arrangements for a considerable volume of data exchange,
whether directly over communication systems or by
the dispatch of reels of tape and boxes of cards. These
are very significant areas of growth that are just beginning to emerge in commercial EDP and are already
creating problems within the Federal government.
The development of data interchange is straightforward when the correspondents have agreed on the
format, but where there has been no prior agreement,
conversion usually involves considerable manual jntervention. Some typical problems are that:
a. The sender's format may not be specified
rigorously and an informal description may have
to be debugged.
b. The sender's format may not be expressible in
the receiver's system.
c. The sender's format descriptions may be embedded in the program.
d. The format in the sender's system may vary
from record to record and be embedded in the
data.
Any of these problems may arise when either an existing application is converted to a new system, or a
new member of a cooperating network has a system
different from that of any existing member.
There are two basic problems:
a. Few existjng systems have any ability to deal
with a new format automatically, and those that
do are limited to data described in the same
system.
b. The number of different, and often incompatible,
ways of describing data is increasing; e.g.,
Format statements in FORTRAN, Data Description in COBOL, COl\1POOL in JOVIAL,
FFT's in FFS.
Any solution to this problem should not restrict
participants in the use, within their own local system,
of any internal data structure they like or any programming or query language they like. Therefore
we need a standard data description language for data
exchange. It is expected that systems should interface
with a single way of describjng data for interchange and
provide conversion processes in their interfaces. If a
suitable interface is to be developed, we will not want
to standardize formats, which would be absurd, but
we would want to standardize ways to describe formats.
We also ",'ill want to attach the data descriptions to the
data, so that the transmission of both data and its
description can be performed without manual intervention.
A data description language for data interchange
does not have to be read and understood principally by
humans. It can be thought of as a complicated coding to
be generated and interpreted b:l the interface 1110dules of
systems in a network. In a well-designed system a user
would describe data in the form provided for local use,
and the system would translate to data interchange
conventions. Therefore, the data description language
should be generally compatible with data descriptions
in current programming languages. Later, developments in programming languages may be influenced by
a desire to remain compatible with data interchange
conventions.
Standardization of high-level languages
by GHACE MURRAY HOPPER
Director, Navy Programming Language,'; Group
WaRhingt.on, I). C.
The terms "compatibility", commonality," and
"transferabilit.y" are used in discussing the mobility of
programs and programmers. The common element
essential to such mobility is the establishment of standards for programs, programmers, and documentation.
The adoption of high-level programming languages
such as COBOL, FORTRAN', ALGOL, and .JOVIAL
is a required element of such standards. The highlevel languages are innately self -documenting-an
essential for transferability. Thus, their use provides
assistance in the transfer of programs among activities;
the conversion from one computer generation to another; the conversion from one computer manufacturer
to another; and the transfer of programs for back-up
and readiness.
Further, the programmers, themselves, need be
trained but once and retraining upon transfer to a new
system is virtually eliminated. Programmers become
capable of greater productivity per unit of time resulting
in less cost per unit of program. However, such application of the programming languages implies that they
themselves be standardized. A standardized language
must he commonly acceptable, competitive, developable, maintainable, and useful. The standard language
must he deye]oped, defined, approved, adopted, and
installed.
The installation of a standard programming language,
in varying environmentR wit.h varied requirements,
Software T-ransferability
requires of management the normal functions of promulgation, installation, control, evaluation, monitoring,
and provision for maintenance and changes. The execution of these functions can be assisted by the use of programmed tools such as validation routines, translators,
preprocessors, flow charters, debugging aids, and by
standard manuals and instruction courses.
The discussion includes a survey of the growth of the
standard languages with implications and suggestions
for future developments. Information supporting the
need for the application of the languages and the resultant time and cost savings is introduced. The necessary components of an installation package are defined
and their implementation discussed. The need for
management inter~st, concern, support, and action is
stressed.
The transferability of computer programs
and the data on which they operate
by EDWARD MOREXOFF
Rome Air Development Center
Griffiss AFB. N ew York
INTRODUCTION
Software transferability involves the transfer of programs and the data on which they operate from one
arbitrary operating environment to another, with the
expenditure of only a small fraction of the initial programming development time and cost. The programs
can range from small routines for evaluating trigonometric functions, to large and complex systems such as compilers, data management systems, or command and
control systems. The environments in which these programs are to be executed may be either slightly or
highly dissimilar with respect to machines, machine
configurations, or operating systems and languages
used.
The interest of the Rome Air Development Center in
this area extends over a period of several years. During
this time, both hardware and software research and
development programs have been initiated which either
directly or indirectly contribute to the solution of the
problem. The utility of adopting standards, and the
form these standards might assume, were defined in
1967. 1
Typical of the efforts in the hardware area was a
study leading to the definition of a microprogrammed
609
computer main frame capable of efficiently executing a
number of different machine language instruction
sets. 2 Typical of the efforts in the software area was the
work leading to the design of a generalized data
management system,3,4 the development of modular
proramming design tools, 5 ,6 and· the Informa tion
Processing Code. 7
In January 1968, the Program Transferability Study
Group* was established. Its principal objective was to
examine the whole area of software transferability
formally, and see what, if anything, could be done to
eliminate the problems associated with transferring
programs and data between arbitrary environments.
The preliminary findings of the study group were
released in June 1968.8 The Group found the main
obstacles to software transferability to be loose specification of data structures, lack of programming standardization, and lack of freedom when higher level
languages were used. Possible solutions to these problems are: (1) Administrative control of programming
and documentation (2) Extensions to current languages
(3) Use of a new programming environment which
would eliminate the constraints of the older system.
The problem
The study group concluded that the problem of transferring a program between arbitrary operating environments was not solved by the current technology, even
when the initial program development made use of a
standard version of a single higher level language.
Current practice is such as to require changes to the
initial form of the program itself rather than simply a
recompilation, in order to adapt the program to a
change in environment.
One of the principal factors necessitating such
changes is the lack of adequate facilities for the explicit
specification of data, programs, actions, messages,
linkage, and the like. The programmer is instead encouraged, if not actually forced, to make implicit in the
form of his program many of details of its initial e!lvironment and the data to be operated on. In order to
transfer a program from one environment to another,
reprogramming is required to the extent that differences
in the two envir<;mments must be reflected in changes to
the program.
Closely related to the lack of adequate explicit specification facilities is the lack of constraints which would
serve to regularize the behavior of the programmer. As
a consequence of the excessive generality and complexity
*The Program Transferability Study Group was chaired by
George H. Mealy. Other members included T. E. Cheatam. Jr.,
David J. Farber. Edward Morenoff and Kirk Sattley.
610
Spring Joint Computer Conference, 1969
in present operating systems and languages, a programmer setting out to prepare a complete program
has entirely too much freedom. In the absence of explicit facilities or when such facilities are too general,
different programmers produce entirely different programmatic solutions to the same problem. A strong
relationship is believed to exist between this difference
and the difficulty in transferring programs.
An example of a language which has enjoyed a measure of success in the development of transferrable
'programs is COBOL. COBOL encourages the explicit
description of data rather than the implicit description
inherent in most other languages. It is about the only
language system which permits any kind of environment specification. It is limited in scope, however, to
problems which trace their origin to unit record equipment. This narrowness of scope appears to be one of the
principal reasons for its success in allowing programs
written in it to be transferred between environments.
In addition to the use of higher level languages, the
study group found two other basic approaches to
solving the transferability problem, both largely unsuccessful. The first approach involves "decompiling"
a binary, decimal or symbolic program written for one
operating environment, and then generating new code
for some other operating environment. The second
approach is by the application of a set of management
solutions. These solutions range from the insistence on
replicating functionally identical hardware configurations to setting standard specifications on programs so
they are completely modular with very precise functional specifications and clear interfaces.
Attacks on the problem
The second major conclusion of the study group was
that the current state of the computer technology had
reached a level of development at which something
could be done about the problem of transferability
today. Indeed, three compelmentary levels of attack
were proposed.
The first level of attack, designated as level A, deals
with the definition and application of suitable administrative controls, both to the programming and documentation processes, using languages and operating
systems as they exist today. The resulting standards
would form a common subset or intersection of the
capabilities of the operating systems and languages to
be involved in the family of transferrable environments.
To work at all, these standards must be enforced by a
czar with final approval over all programming work.
The second level of attack, designated as level B,
deals with the development of extensions to the current
language and system base. This involves identifying the
deficiencies with respect to particular existing systems,
defining how these deficiencies may be eliminated, and
then implementing the resulting changes to equalize
the capability of all the operating systems and languages
in the family of transferrable environments.
Part of the design problem at level B is to identify
which extensions can be incorporated into the existing
systems with a high probability of success within a two
year period from the time they have been defined.
Extensions not falling within this category would be
deferred for consideration as part of attack level C.
The third level of attack, designated as level C,
relaxes the requirement of using the existing base of
operating systems and languages to allow consideration
of a wholly new programming and operating environment which would substantially eliminate, for most
practical cases of interest, the problem of program
transferability. Within this environment the higher
risk and/or longer term concepts would be tested and
evaluated.
The life of the study group has been extended. It is
currently continuing its investigations of selected
aspects of the software transferability problem.
BIBLIOGRAPHY
1 E
MORE~OFF
J B
McLEA~
A.n approach to standardizing cornpuwr system."
Proc 22nd ~ ational ACM Conference
August 1967 527-536
2 DECISIOX SYSTEMS I~C
Thomp~on
Book Co
I nwrirn Status Report No 1
Contract ~o F30602-68-0223 August 11 1968
3 P J DIXO~ J D SABLE
D_~-l
a generalized data management sysle'rn
Proc S J C C Thompson Book Co April 1967 185-198
4 E MORENOFF J B McLEA~
On the design oj a general purpose data rnanagenwnl .'I!Jswm
.~
Proc Fourth Annual Colloquium on Information Retrieval
Int Information Inc May 1967 1\)-30
E MORE~OFF J B McLBA~
Inter-program conunllnicati.ons progra/ll sir-in!! .~truct ures and
bU.ffer files
Proc S J C C Thompson Book Co Aprii 1967 17.j-18-i
6 E MORENOFF J B McLEAN
Program string structures and modular programminy
Proc National Symposium OIl Modular Programming
Information and Systems Press June 1968 176-186
7 E MOREN OFF J B McLEAN
A. code for non-numeric processing applications in on-line
systems
Communications of the ACM Vol 10 No 1 January 1967
19-22
8 G H MEALY et al
Transferability study group
Rome Air Development Center Technical Report. No
TR-68-341. December 1968.
Software Transferability
Transferability of data and programs
between computer systems
by JEROME D. SABLE
Auerbach Corporation
Philadelphia, Pennsylvamia
INTRODUOTION
The cost of problem analysis and programming dominates by far the cost of computer utilization. This
dominance will increase in the future as hardware
elements become more powerful and economical and
problems become more complex and demanding of
highly skilled analysis. As this trend continues, the
sophisticated user will become increasingly intolerant
of a situation which prevents economic transfer of
programs and data from one installation or hardware
type to another. A standard machine independent
environment which provides data management services
at several levels to programmers and task programs
should be defined. Programs would then interface with
a set of virtual machines, or standard program environments' which are independent of the particular
hardware configuration of the installation.
The traditional approaches to data and program
transferability have been through (a) the use of compatible hardware types which have presented "equivalent" hardware interpreters for data and program, and
(b) the use of standard higher level procedure-oriented
languages and compilers to trans1ate programs to a
particular machine type. The first approch guarantees
complete interchangeability only as long as the program's support software is duplicated but removes the
possibility of matching special hardware types to problem areas for which they may be particularly appropriate. This restriction is unnecessarily severe in many
cases. The second approach avoids this restriction but
there are many problem areas for which standard
procedure-oriented languages have not been adopted.
Indeed, many systems will continue to be implemented
in assembler and macro level languages.
I would like to suggest that the problem of data and
program transferability can be approached most
generally by extending approach "(a)" to include software as well as hardware interpreters. Software interpreters, or simulators, have been used in the past to
transfer a machine language program from machine A
to machine B. However, these have not been entirely
successful or widely used. The success of this approach
hinges on the ability to write programs for one of several
611
standard environments and to describe in a standard,
yet general, way the data structures which are to be
transmitted and interpreted. To permit general applicability from machine level programs and data, through
to higher level language programs and other character
stream messages, requires that a wide range of data
structures and languages be describable in a standard
way. The language description standards must include
the lexicographic, syntactic, and semantic levels.
In the following paragraphs a hierarchy of data
structure types will be described which range from
machine and storage-oriented structures to "logical"
data structures transmittable as character strings
independent of physical representation. They are
offered as one possible approach to a comprehensive
set of data structures.
Data structures
The cell
The most primitive concept to be considered is that
of an address space. This is viewed as a region of atomic
elements or cells which are addressable with some address word. There may be a hierarchy of cells such that
higher level cells form an address space for a lower level
cell. The cell is viewed as a region is which data can be
stored and accessed rather than the data themselves.
Several address spaces, or stores, may be involved in a
system or network.
A given computer will have a system of primary,
secondary, tertiary, etc., stores associated with it. A cell
in any store is addressable with an address or a simple
transformation of an address.
The truck and train
The most primitive relocatable data structure is the
truck. This is a module of data which can be stored in a
cell. A sequence of trucks, called a train, may be defined
and transmitted from one store to another. Any relocatable data structure (the term as used here in~ludes
programs) is ultimately handled as a train whose trucks
are bytes, words, or pages.
The bead, strip, and plex
An element (e.g., train) of fixed length and defined
field structure will be called a bead. A sequence of beads
of the same type will be called a strip. If the beads
contain fields which address other beads then a network of beads, called a plex, is formed. *
*The terms plex and bead have been used by D. T. Ross in his
work on the AED systems.
612
Spring Joint Computer Conference, 1969
The stream
A list or list structure of byte trains of various
lengths will be called a stream. Consider the data
structures necessary for representing a process, or
active job. These include a stream containing procedures and subroutines, a stream for the dynamic
working data (or activation records) of each procedure,
and a stream for the control stack which provides
subroutine control. Collectively, then the process can
be considered to be a stream list.
The item
Finally, a data structure may be defined in terms of
named entities, called items, which bear a defined
relationship to each other. These items are fields,
records, files, and statements and are independent of
any storage structure or address space. Items may be
independent messages or form a highly structured
hierarchy of nested elements, files, etc.
Specification languages
The success of the approach to data and program
transferability being proposed here depends on the
adoption of a comprehensive data description language
(DDL). The DDL must. meet a number of requirements:
1. It must be able to handle at least the range of
data types listed above.
2. The requirement to handle item structures and
source language messages means that it should
be capable of expressing the symbols and syntax
of context-free languages.
3. It should be capable of expressing the semantics
of translation or interpretation of the source
language strings, including procedure calls to
other processors.
4. It should be representable in a graphical format
that exhibits the structure of the language or
data being described so that it represents an
effective tool for human communication.
5. It should also be representable by linear strings
amenable to transmission and computer input,
and it should be easy to translate from the graphical to the linear version, and vice versa.
CONCLUSION
The problem of transferring data from one computer
to another, and interpreting the data correctly: can be
approached as a problem of constructing an adequate
range of data structure types and devising a standard
way of describing these types. Noone level of data
description is adequate. Rather, there must be a range
of structures which go from the highly machine oriented
cell structure to the user-information oriented structure. It is felt that a hierarchy of data structure types
which is adequate for this task can be devised. The data
types to be included have been listed above.
The problem of data description, however, is but a
special case of language specification and special attention must be paid to the lexicographic, syntactic, and
semantic aspects of specification. Some recently developed language specification languages and generalized language processors can be brought to bear on this
problem. These processors can be employed as a standard interface in a network of different computer types.
When furnished with the description of the structure
(languages) to be accepted, they can carry out the
appropriate translation and interpretation.
The stratification of data management servicesi nto a
number of standard levels would make it appear to the
programmer, that at anyone moment, he is interfacing
with one of a number of virtual machines which form
an upward compatable hierarchy. These services may
be, in fact, provided by a mix of hardware and software
modules which depends on the particular system implementation, and the hardware types being used in a
given instance. Thus, each program has, as its interpreter, a virtual machine whose interface with the program is know but whose composition may vary and is
irrelevant except for timing considerations. A given
installation, because of hardware and software modules
used, may provide interpretive virtual machines only
up to a given level, requiring programs written for a
higher level virtual machine to undergo a translation
process down to the appropriate level before interpretation can take piace.
That the goals outlined above will be difficult to
achieve in today's technology and market place is well
recognized. However, I feel it is the responsibility of the
industry to its users to embark on a comprehensive
project to ensure software transferability across a Wide
range of problem areas and hardware types Without
limiting the development of new languages and machines.
A panel session-Computer-assisted instruction:
C.ll
-----......
- p.nt
----
.~t~tll~-Flltll-rP.
. . . . . . . . . . --........ . -. . . . . .., ......... "'" n-roh1PnlQ
r.a. '""...., . .
"-'~....,
PATRICK SUPPES, Chairm,an o.f Session
Stanford University
Stanford, California
CAl problems and prospects
by WALLACE FEURZEIG
Bolt, Beranek and Newman Inc.
Cambridge, Massachusetts
and
SEYMOUR PAPERT
M a8sachusetts Institute of Technology
Cambridge, Massachusetts
The expression "computer-assisted instruction"
(CAl) is generally used to describe situations in which
the computer is used as a teaching surrogate in some
sense--whether as drill instructor, tester, or specialized
tutor. ~Tost applications of this kind have had specific,
limited, and modest educational goals. When used to
administer drills or branching tests, a computer is not
called upon to be intelligent-only useful. Yet it is
interesting and important to ask whether the computer
can become an intelligent artificial teacher, and more
generally, whether there are valuable ways of using
computers for teaching and learning.
In artificial teaching, the computer controls the
interaction with the student. There are applications of
the opposite kind, where the student controls the
machine. The most common one is the teaching of computer programming itself. Another is the use of a
computer to simulate a "real" laboratory. And, there is
a potentially rich spectrum of intermediate arrangements-strong instructional interactions-in which the
student and the computer share control and direct each
other. As an example, student programming and
artificial teaching might be coupled by having the
computer monitor a student's work as he uses a
programming language to perform a simulated experiment or to solve a problem. No significant experiments
in this direction can be done without a great deal of
work; but we do know, in principle, how to make a
program follow the steps of a student who is not
constrained by a stereotyped pattern and how to
diagnose his difficulties on the way.
We shall argue that computers will make deep
contributions to education in all three areas:
1. first, and with capabilities already well established, through the teaching of programming
languages;
2. ultimately, and to an extent largely dependent
on progress in artificial intelligence research, as
an artificial teacher;
3. intermediately, as an instructional monitor or
assistant, in a number of different subjects as
diverse as music, language, and physics.
Along the way, we shall elaborate on specific educational contributions including the following.
----------------------------------------613--------------------------------------
614
Spring Joint Computer Conference, 1969
1. The teaching of programming can provide a
conceptual and operational framework for the
teaching of mathematics.
2. USL.Ylg an appropriate langul;tge, prograrrL11ling
can be introduced routinely to third-graders for
its special value in teaching the skills of clear and
precise thinking and expression.
3. The computer can enhance the teaching of
"practical" subjects (such as navigation or
speaking a foreign language) whose mastery
requires the integration of mechanical and
intellectual skills.
Finally, we shall contrast the present lack of depth
and perspective characterizing much of the work in this
field with its rich prospects. In particular, we shall
discuss our view that a serious investigation of the
problems involved in developing an intelligent teaching
system will yield rich results in the fields of computers,
education, and psychology.
CAl: Research requirements for
instructional strategies
full corpus of an accredited course; the physics course at
Florida State University and the library science course
at the University of Illinois best represent the autonomous type. Lastly, the enriched CAl type provides
instruction on content considered as extensions of the
conventional classroom curriculum; the simulation
games at BOCES are excellent examples of the enrichment type. An analysis and comparison of the instructional strategies of these three naturalistic CAl
applicational types will be discussed.
The systematic approach to CAl research on instructional strategies resolve into six areas. First, what is the
appropriate media for the presentation of a given
concept? Second, what are the desirable time parameters
for the CAl system to respond to the learner's answer?
Third, what are the characteristics of the ~mswer
analysis routines that promote the specified learning
objectives? Fourth, what is the decision logic of the
presentation plan that specifies the sequence, amount
of practice, and termination of the instruction? Fifth,
what are the payoffs to the instructional process within
CAl? And lastly, what kinds and types of reports should
be part of CAl application? Current research findings
and implications for future investigations are discussed
within the framework of the six aspects of instructional
strategies for CAl.
by DUNCAN N. HANSEN
Florida State University
Tallahassee, Florida
The current developments of computer-assisted
instruction (CAl) can be characterized as a phased
transition from the creation of hardware and language
systems for implementation into the more fundamental
examination of the features of optimal instructional
strategies for CAl applications. Instructional strategies
are the plans by which informational presentations are
matched with the current requirements of a learner in
order to optimize on a set of criterion objectives. The
research approaches into the nature and process of
instructional strategies has been twofold, namely,
naturalistic and systematic.
The naturalistic approach consists of three applicational types that developed concurrently with the
hardware and language CAl systems. First, the
complementary CAl type provides instruction that is
adjusted to the stage of progress that a student has
acquired in the conventional educational classroom;
this approach is best exemplified by the Stanford Drill
and Practice Mathematics Project. Secondly, the
autonomous CAl t.ype provides instruct.ion that is the
Instructional uses of computers to grow
gracefully and effectively
by ELDO C. KOENIG
University of Wisconsin
Madison; Wisconsin
INTRODUCTION
In this brief disc"ijssion, it is suggest.ed that three
principal functions be recognized and be performed in
parallel in order to achieve a graceful and effective
growth in the instructional uses of computers. These
functions are described as:
1. the practice of teaching using computers as aids;
2. research and development directed toward the
practical uses of computers in teaching and
learning;
3. basic research in intelligent systems.
Function (1) is dependent on function (2) and (2) is
dependent on (3). Computer hardware and software and
Computer=Assisted Instruction
people are included in the discussion of each of the
functions.
615
leased terminals of systems of limited capabilities. They
will gain valuable experience which will prepare them
for future systems of greater capabilities.
The practice of teaching using computers as aids
Computers in education today can be used most
effectively to assist in the teaching of subjects that are
mathematically disciplined, such as, programming,
mathematics, engineering, physics, statistics, and bookkeeping. For courses of this type, much of the knowledge
is contained in mathematical expressions and communication between student and computer can be more
easily accomplished than in verbally oriented courses.
Computers used in courses of this type can (1) assist
individual students in a direct learning experience, (2)
perform the calculations in solving assigned problems,
and (3) aid the instructor in demonstrating the functional characteristics of the various types of mathematical equations, the effects of changes in the variables of
computational models, and various physical phenomena
through simulations.
Hardware and Software. The function should employ
existing computer systems. The one selected must be a
practical operating system with integrated hardware
and software and with well-defined capabilities. Because
rapid advances will continue to be made in systems, the
policy should be that of leasing. Currently, the choice
can be made between the leasing of terminals of a large
utility type system and the leasing of a relatively small
complete system. Small computer systems are available
with complex man-machine interfaces which make them
very capable in special types of applications, such as,
graphics. The leased terminals of large utility systems
are relatively simple man-machine interfaces, and the
systems have limited capabilities in a conversational
mode of operation. Since the fixed cost of leasing is low
and the usage cost is variable, the number of students
and the amount of time each uses a system can be small
to accommodate a minimal budget. Because a leased
complete system has a fixed total cost, it may be difficult
to find enough student users to make the cost per
student a reasonable value.
People. If current systems can be used effectively as
aids in teaching mathematically disciplined subjects
ranging from arithmetic in elementary schools to
advanced college subjects, and if they can be cost
justified for small numbers of students, then the only
additional requirement is the training of teachers in the
rules for communicating with the computers and in
methods for using them. Usually, courses are offered for
training in the rules of communication. Until similar
courses exist for training in the new methods, teachers
should be encouraged to experiment in developing
simpler methods and techniques through the use of
Research and development directed toward the practical
uses of computers in teaching and learning
This function establishes teaching methods using
computers as aids; determines the psychological factors
related to these methods, and provides for the training
of teachers' in practical application of these methods,
particularly those teachers in the lower levels of
education.
Hardware and Software. An integrated hardwaresoftware system for this function should be supplied as
a practical result of research in intelligent systems, the
third function, and should be replaced every three to
five years with one of greater capabilities. The packaged
system should provide for the maximum of flexibility
and should be able to:
a. gather and analyze physiological information on
a human subject
b. receive and analyze the various requested responses of the subject
c. provide flexibility in selection of the content and
organization of learning materials and the interface devices
d. provide a variety of learning strategies through a
choice of (b), (c), and an alternating sequence or
an integration of the two
e. gather information on the environment of the
subject
f. permit a higher level of control which coordinates
the controlling actions for (a), (b), and (c)
g. permit a high level supervisory control with.
flexibility for ~oordinating and directing two or
more subjects at different terminals in competitive learning experiments.
People. There should be a number of groups in
different fields in a university performing this function,
for example, the School of Education, Engineering, and
Computer Sciences. The School of Education should
place emphasis on the lower levels of education. Special
training may be required in computational modeling,
computers, and in the capabilities and the use of the
man-machine interactive system to be used.
Basic research in intelligent systems
This research, in the broadest sense, should strive to
use the human intelligence of a society better by
improved ways of synthesizing intelligent systems and
616
Spring Joint Computer Conference, 1969
by more effective ways· of transferring knowledge from
one generation to the next. It should also strive to
increase the intelligent capabilities of a society by
imparting intelligence to machines.
Hardware and Software. Current hardware should be
selected and developed into a hardware system, and
initial software design should be based on the principles
determined from the previous research system. Basic
research should then be applied to the current machine
system to improve its performance as a component of an
intelligent system. The improved system, in turn,
should further basic research which is again applied to
produce additional improvements in performance.
A machine system with significant improvements should
evolve every three to five years and then should replace
the system in research and development directed toward
the practical uses of computers in teaching and learning.
People. Since complete interactive systems contain
both man and machine as components, the research
must draw on select basic knowledges from a number
of fields. Unifying disciplines must evolve relating the
various knowledges, and a graduate program should be
associated with the research effort. The students must
be able to acquire the variety of existing knowledges,
and through their active participation in research, they
should have an opportunity to apply and associate these
knowledges. The build-up of both the research effort and
the graduate program must be gradual.
A picture is worth a thousand
words-and it costs . . . *
by j. C. R. LICKLIDER
Massachusetts Institute of Technology
Cambridge, Massachusetts
INTRODUCTION
The present is a critical, frustrating, and exciting time
in the history of computer graphics. A dozen significant
trends are developing in the same field of view. Several
much-needed trends are not developing. The technology
is changing so rapidly that four generations of graphical
systems are in operation at once. "Computer graphics"
means different things to different people. This is therefore a difficult session to" introduce."
Perhaps the mos't important introductory remark to
make about the session is that the papers that follow
this one do not attempt to cover the topic of computer
graphics. They are in computer graphics, not on it. In
this paper, I shall not t.ry to cover the topic, either, but
I shall take a brief look at the over-all field and try to
sketch out enough of a map to provide an orientation
and context for the papers that follow. In the process, I
shall unburden myself of a few deep convictions.
There are three main efforts in computer graphics.
The first is to improve the capability of graphical displays to represent things and processes. This capability extends into dimensionality, verisimilitude,
complexity, and motion.
The second main effort is to improve the interaction
between men and computers through graphics, to improve graphics as a medium of communication. It is
important to distinguish between communication and
representation. Both involve languages, but not in the
same way.
The third main effort is to develop applications of
computer graphics. Applications run the gamut from
* The ideas described herein were derived mainly from research supported by Project MAC, an M.LT. research program
sponsored by the Advanced Research Projects Agency, Department of Defense, under Office of Naval Research Contract
Nonr-4102 (01).
computer-aided composition of printed pages to computer-aided design and dynamic modeling.
All the foregoing pose problems of computer-system
design and are energized and/or inhibited by economics.
This paper will deal, then, in an introductory-and
necessarily sketchy-way with representational capability, communication and interaction, applications,
computer-system design, and economics-all in the
context of computer graphics. Because the art is long
and the time fleeting, the paper will consist essentially
of observations and assertions within those areas rather
than reviews or analyses of them.
Representational capability
Although most computer graphics is limited to arrangements of points and line segments, together with
perhaps a hundred elementary figures (characters),
computers are of course capable of processing and displaying areal pictures replete with graded lightness
(brightness) and varied hue (color). The work of
Stockham! at the lVLI.T. Lincoln Laboratory and the
University of Utah illustrates the versatility of the
computer in handling still pictures with gray scale.
Stockham scans a low-contrast photograph into the
computer memory, takes the logarithm of every lightness coefficient, applies a la Ernst Mach a secondspatial-derivative operator to each neighborhood of coefficients to yield a new coefficient for the central
element of the neighborhood, then takes the antilogarithm and displays the resulting picture. Detail not
visible in the original stands out clearly in the processed picture. But the processing requires many
seconds for a picture with a millon elements, and
Stockham's kind of picture processing is not kinematic
or" on-line interactive" in the present state of the technology. Nor does the computer "understand" the
---------------------------------617---------------------------------
618
Spring Joint Computer Conference, 1969
picture in the ~ense of forming a structured model of the
pictured scene in which the various objects and their
parts are represented separately in a hierarchy. Thus in
Stockham's application we see an emphasis of high
precision in representation and processing at a sacrifice
of speed and structured ness.
The work of Evans, Warnock, 2 and their colleagues at
Utah starts with a structured model in the memory of
the computer, rather than a high-information-content
photograph at the input scanner. They have developed
method's of processing that yield a halftone-like picture,
in color, with "hidden lines" suppressed-in a small
fraction of the computer time that would have been
required two years ago. At the present time, however,
even with the Utah methods, one cannot process and
display areal (e.g., halftone) pictures fast enough to produce moving pictures in real time. He can go to slowtime frame-by-frame generation of film, or he call
schematize, or both.
The technology for handling ~chematized pictures and
diagrams-made up of points, line segments, and characters-has advanced markedly during the last two
years. Roberts 3 described some of the basic ideas, involving homogeneous-matrix representation and perspective transformation. In the work that won them the
prize at the Fall Joint Computer Conference, Robert
Sproull and I van Sutherland 4 developed hardware that
very rapidly transforms selected parts of a model in the
computer's memory to a line drawing on the cathoderay screen. The hardware rej ects all the parts of the
model-a large two-dimensional drawing or a threedimensional scene-that would not be seen through a
given window, and it produces the magnifications or
perspective transformations and the clippings or trimmings at the window frame necessary to display just
what would be seen through the window. It does all that
fast enough to display 3000 lines flicker-free. The" 3000
lines" refers to what is actually displayed; there can be
many more lines that that in the model. The hardware
handles curved lines and surfaces. It works hand-inglove with the Warnock hidden-line algorithm, which
works on schematized (linear) as well as areal displays,
and the hardware is applicable to, and will decrease the
processing time required for, areal displays.
The foregoing dealt with actually two-dimensional
displays of two- and three-dimensional obj ects and
scenes. There are interesting ways to make the displays
perceptually, or even actually, three-dimensional. The
method of calculating and presenting two slightly
different" stereo" views is well known. So are methods
based on the "kinetic depth effect," which present a
single, changing view. When successive two-dimensional
cross sectional images are projected in rapid sequence
upon a moving I:!creen, the eye, becaul:!e of its persistence, sees the composite three-dimensional image.
See Traub. s The computer can control the settings of a
matrix of push rods to make a three-dimensional surface, a histogram rising from a plane. And, of course, it
can synthesize a hologram.
Of those and other approaches to 3-D, the most exotic appears to be one demonstrated by I van Sutherland
and associates at Harvard last year. The computer has
a model of a situation in its memory, and it receives
signals from sensors that tell it where the observer is
and in what direction his head is oriented. \Vith the aid
of hardware described earlier, the computer then diHplays the part of the modeled situation that the observer would see. The display is projected fl'OlH a small
cathode-ray tube ou the observer's head through a semisilvered mirror into one of the observer's eyes, and the
observer sees the displayed part of the situation out in
front of him. He can look around and walk arouudand always see what he would see if he were in the
modeled situation. When I saw the demonstration,
the hardware was not finished, and the situation was
just an outline room with windows, a door, and a geometrical piece of statuary. Even at that, it was quite au
adventure. fiiven situations defined by thousands of
line segments, one could surely create ::lome exciting
experiences-and probably some very significant ones.
As Sutherland has pointed out, the" physical" laws of
the modeled world can be determined by the programmer. They can change with time. They can even depend upon the observer's behavior. Elsewhere, the
possibility of creating a direct four-dimensional expl'rience has been discussed. See Licklider. 6 I shall not ~o
through it again here, but let me say that it will be intellectually at least as exciting to perceive and explol'(\ a
synthetic 4-D world as to perceive and explore a merely
actual, merely 3-D moon.
Most of the capabilities of representation descrihed
in the foregoing are characteristic at present solely of
expensive equipment and are regarded by many aH
esoteric. I shall say something about that under the
heading, Economics, but for the moment let it direct OlIr
attention to the other end of the spectrum. Among
the most significant developments as judged from a
practical point of view, certainly, are computer setting
of type, computer-aided preparation of diagrams and
graphs for the printed page, computer-aided composition of advertisements, computer-aided generation
of films, off-line production of graphics (as with curve
plotters and as with the Stromberg-Carlson 4020), and
fast on-line display of alphanumeric data and text.
A Picture is Worth a Thousand Words-And it C.osts . . .
Communication and interaction
It is of course very important in computer graphics
to be able to represent things and processes accurately
and in detai1. I think it is more important to be able to
represent them in proper structural organization. I
think it is still more important for computer graphics to
be an effective medium of communication. Good oneway communication is good, but good two-way communication':':""good graphical man-computer interaction-is better.
Now, as the history of art shows, and as Huggins and
Entwisle7 will emphasize, and as I· hoped Don Hatfield
would develop in depth in this session, the representation with the greAtest verisimilitude is not often the best
means or medium of communication. Good graphical
communication is more a matter of linguistic expression
than it is' of pictorial reproduction. Unfortunately, we
in the computer world do not know much about the
language, and unfortunately not many of us are trying
hard to find out about it. Obviously, it does. not have
much to to with programming languages. It probably
does have something to do with data structures: But
mainly it is the art of expressing ideas through configurations and manipulations of signs and symbols. Let
me call that art an essential extension of computer
graphics and then leave the topic to Huggins and
Entwisle. I like their approach to it, insofar as the oneway language-computer to man-is concerned.
In my assessment, however, communication is essentially a two-way process, and in my scale of values,
interaction predominates over detail, gray scale, color,
and even motion. In my iudgment, the most important
problem in computer graphics is that of establishing
exc~llent interaction-excellent two-way man-computer
. communication-in a language that recognizes, not
only points, Hnes, triangles, squares, circles, rings,
plexes, and three-way associa~tibns, but also such ideas
as force, flow, field, cause, effect, hierarchy, probability,
transformation, and randomness. Nowhere, to the best
of my knowledge, is such i~teraction approached in a
broad problem area at the present time. The nearest
things to exceptions are the graphical computer-programming interactions of Ellis and Sibley 8 at RAND,
the partly graphical, partly alphanumeric on-line
augmentation of Engelbart's9 intellect at Stanford
Research Institute, and the graphical explorations in
architecture of Negroponte10 at M.LT. It is very frustrating to me that five and a half years have elapsed
since Sketchpad passed its milepost without bringing
more progress in man-computer interaction at the level
of ideas and concepts.
It seems unlikely that work in computer-aided design
of devices and structures will lead to the advances I am
619
hoping for. Computer-aided design of complex systeIns
or processes might do it. I like the name, "interactive
dynamic modeling," for the art. I want to see develop a kind of combination of computer-aided design a
la Sketchpad and computer-program siinulation a la
on-line GPSS or OPS-in which the modeler and the
computer engage in a high-level graphical interaction
to formulate and test hypotheses for the solution of
difficult problems that are not amenable to straightforward logico-mathematical formulation, that involve
more synthesis than analysis, more discovery than
proof. Well, it is not much to have the name. I wish I
had the method, the language, the software, and the
hardware.
Man-computer interaction of course presupposes
computer-input devices (as well as languages) to mediate the communication from man to computer. The man
should be able to signal the computer in a natural and
synergic way, as by pointing and marking with a stylUS
while enunciating control words or phrases. He should
be able to write or draw on the same surface as the computer. I shall not develop this part of the discussion
beyond saying that one can appreciate the problem
after he has read the transcript of a good blaekboard
lecture and then later (and separately) seen photographs of the blackboard. "Chalk plus talk" is an
excellent medium. N ei~her chalk nor talk alone carries
much information. The communication must therefore
lie in the coordination.
Applications
At present, it appears that three very different
classes of application of computer graphics are successful: (1) routine applications in the field of publishing
(e.g., Chemical Abstracts) that yield printed pages as
primary output and at the same time retain the information in computer-processible form for updating
or secondary exploitation; (2) routine applications
throughout business and industry (e.g., airline ticketing, display of stock quotations) that involve fast online display of alphanumeric data or text from computers; and (3) "cream" (and often highly nonroutine)
applications in government and industry (e.g., military
command and control, space-mission control, seismic
prospecting for oil) in which the premium on being
first or best is very high or in which the required results
cannot be achieved any other way. The first two do
not require sophisticated graphic capability. The third
requires and can afford very sophisticated capability.
If and when there exists and is available the kind of
computer graphics I referred to as" interactive dynamic
modeling," computer graphics will become a part of
thinking and problem solving and decision making
620
Spring Joint Computer Conference, 1969
wherever those functions are carried out. Design will of
course be a major application area: design of all kinds of
systems and processes-space, urban, transportation,
manufacturing, military-as well as devices and structures. Management of government and business will
use graphics in its" command and control." Applications will abound in research and development and in
medicine. But the application area par excellence will
be education. Almost anything not involving muscular
skill that needs to be explained and demonstrated can
be explained and demonstrated best with the aid of
'interactive computer graphics. For the sake of brevity, I
shall leave that as a simple assertion in need of proof by
demonstration.
The trouble is, all those applications that depend
upon a significant augmentation of the human intellect
(to use Engelbart's phrase) demand a level of computer
graphics as sophisticated as that required for the
"cream" applications mentioned earlier-or even more
sophisticated .
The field is ready for and cultivating simpleminded
applications in which computer graphics will do faster
or less expensively things that can already be done
without it, but the field is not yet ready to accept the
challel~ge of" mind expansion." That carries us to the
0(~onomics again-which we shall examine very shortly.
remote. If all are near, why should each satellite computer have a separate memory? That leads to a wasteful
transferring of data from one memory to another. \Vhy
shouldn't the satellite processor be precisely a display
processor and address a block of the main memory'?
If the satellite is remote, of course it cannot address
the main memory directly; it must have a memory of
its own. If one satellite is remote, all the satellites
should have memories of their own, for it is most important to preserve homogeneity for the sake of simplicity.
Now we come to Bert Sutherland's Dictum: "Think
Network!" Even if you plan to have all the graphics
consoles in the same room as the main computer, treat
them as if remote-because one day soon it will be desirable to admit a remote satellite into the systemor you will want to share software with a system that
has remote satellites.
The key problem then becomes the division of tasks
and the specification of the interface between the central
and the satellite computers. That problem must be
solved in such a way that the satellite does not pester
the central computer continually, yet the user should
feel that he is interacting directly w~'th the central
machine. I doubt that there is a good solution.
System design
Economics
The prevailing idea in computer-system design for
graphies is that graphical display places too heavy a
demand for processing to be handled by the (or a)
main, central processor and that there should, therefore,
be a satellite graphical processor for each graphics console or cluster of graphics consoles. At present, the
satellite processor is usually a small general-purpose
computer augmented by a display processor.
The design of the satellite processor is itself an interesting problem. Is it to be programmed once and for
all and viewed thereafter as just part of the hardware, or
is it to be thought of as remaining a programmable
computer? Is its display processor to do nothing but
diRplay, or should it be able to call display subroutines
and perhaps handle the integer arithmetic of indexing?
Sutherland and ~Iyerll have observed the tendency for
the display processor to evolve into a general purpose
computer and then to need a subordinate display processor, and they have determi~ied how and where to
stop the potentially infinite regress.
The aspect of system design that I think has not been
thought through clearly concerns the division of tasks
between the central computer and the satellite computers. There is a watershed: either all the satellites will
be near the central eomputer, or at least one will be
There are of course two main kinds of cost: (1) the
cost of the equipment; (2) the cost of developing the
methods and preparing the programs. The bad thing is
that for sophisticated computer graphics both are very
great. The good things are that the hardware eosts tend
to drop rapidly, once they start dropping, and that, as
soon as there is replication of hardware,' the software
costs increase much less rapidly than the number of
hardware systems in which the software is used. That is
elementary, but it is ve~y important and evidently not
well enough recognized.
During the 25-year history of digital computing, the
costs of arithmetic units, control units, and processible
memories have halved approximately every two years.
On-line terminals have not had such a "long" historyat least not in significant quantity-but it appears that
some of the simple keyboard-and-cathode-ray-tube
consoles that are coming into use in time-sharing systems dropped from about $13,000 to about $6,500 in the
ye.ar between the last two Fall Joint Computer Conferences. If some are priced at $5,000 in the exhibit
area of this conference, it will suggest that, for a time,
one class of equipment will be halving in cost each year.
I do not want to make too much of such gross trend
analysis, even though it does point to the source of
621
much of the magic of our field, and I certainly shall not
base anything on a halving of cost each year. However,
the question of optimal research lead time is a very important question, and it needs an answer. When should
we develop the kind of computer graphics that will
most strongly augment the intellect? When should we
start if we want to have it ready when it will be affordable? In their paper, Huggins and Entwisle7 will call
educational application of interactive computer graphics, based on time sharing, an H economic absurdity 11
and suggest that the facilities be used to generate educational films. Insofar as operations are concerned,
I agree with them. But what about research?
As basis for a rough calculation, let me take a system
that I think would make an excellent base for a computer graphics laboratory. A few months ago I determined...~he cost ofa graphics-oriented PDP-I0 computer
with 256K words of 2.5-microsecond memory, 15 million
words of disk storage, 16 consoles with storage-tube displays, and quite an assortment of supporting equipment. It was about $700,000. If it were used 8 years,
with an average of 10 consoles active over the 24-hour
day, the cost per console hour would be $1. Double that
to cover maintenance, operation, supplies, and overhead, and you have $2 per console hour to use as an
argument that you could be within hailing distance of
economic operation now if you had the programs.
As I see it, the advances in methodology and software required to achieve the kind of computer graphics
and the kind of interactive dynamic modeling I hope
for will require about as much research effort and time
as several laboratories have devoted to interactive
computing since 1961. If we look ahead to 1977, and
assume hard work in the interim, I think we can count
on a fairly g()od methodological and programming
capability. If the halving-every-two-years rule held,
the over-all equipment cost would be about 12 cents per
console hour in 1977. It need not be that low to support
all the educational and personal applications that it
should support. Other applications-in management,
research, medicine, etc.-would have become economic
earlier, of course.
My conclusion-which is of course as tentative and
open to bias as the foregoing estimates, and perhaps as
simpleminded-is that now is the time to push forward
with research in the areas of computer graphics that
people call expensive, sophisticated, esoteric, and exotic.
I think that they are the areas in which lie the real
promises of significant improvement in our intellectual
processes. If we do not push forward with research in
those areas now, we shall find ourselves with a magic
lantern that we don't know how to rub.
REFERENCES
T STOCKHAM A V OPENHEIM R W SCHAFER
Nonlinear filtering of multiplied and convolved signals
Proceedings of the IEEE 56 August 1968 126-1291
2 J E WAR~OCK
A hidden line algorithm for halftone picture representation
Technical Report 4-5 May 1968 University of Utah
:~ L G ROBERTS
Homogeneous matrix representation and manipulation of
N-dimensional constructs
Lincoln Laboratory Massachusetts Institute of Technology
July 1966
4 R F SPROULL I E SUTHERLA~D
A clipp.ing divider
AFIPS Fall Joint Computer Conference Proceedings 33-1
December 1968 765-775 (Published separately by the
Evans-Sutherland Computer Corporation Research Park
Salt Lake City Utah 1968)
5 A C TRAUB
Stereoscopic display using rapid varifocal mirror oscillations
Applied Optics 6 1967 1085-1087
6 J C R LICKLIDER
Computer graphics as a medium of artistic expression
273-304 in Computers and Their Potential Applications
In Museums X ew York Arno Press 1969
7 W H HUGGINS D R ENTWISLE
Computer animation for the academic community
AFIPS Spring Joint Computer Conference 1969
8 T 0 ELLIS \V L SIBLEY
On the developrnent of equitable graphics 110
IEEE Transactions on Human Factors in Electronics
HFE-8 March 1967 15-17
9 D ENGELBART W K ENGLISH
A research center for augmenting human intellect
AFIPS Fall Joint Computer Conference ProceedingR
33-1 December 1968 :~95--41O
10 N NEGROPONTE
The architecture machine
Forthcoming The MIT Press 1969
11 I E SUTHERLAND T H MYER
On the design of display processors
Comm of the ACM 11 June 1968410--414
Computer animation for the
academic community
II
by W.H. HUGGINS and DORIS R. ENTWISLE
The Johns Hopkins University
Baltimore, Maryland
INTRODUCTION
The use of computer-graphic technology to produce
low-cost films for education promises enormous educational benefit at modest cost. For educators, these
technical developments are but a means to an end
which has thus far recei~ed too little attention-the
production of visual images that in their ability to
communicate ideas are superior to traditional graphical images on paper or blackboard.
The printed word is symbolic, whereas the TV image
is primarily iconic. New modes of iconic display may
be needed to communicate with young people of the
TV generation. Here, computer. animation offers remarkable possibilities-instead of static images, words,
and mathematical symbols, we may create dynamic
signs that move about and develop in self-explanatory
ways to express abstract relations and concepts.
Recent research emphasizes the importance of these
possibilities. According to Bruner, intellectual development moves from enactive through iconic to symbolic representations of the world, with each level
serving to define and give meaning to the next higher
level. Education today primarily proceeds at the symbolic level; iconic modes of communication and instruction remain virtually untapped and warrant
much more attention. In effecting this, computer
animation is certain to play a major role.
The cost of 8howing
Major efforts to develop films for the classroom
have been made during the past decade by various
groups interested in improving education in fields
such as mathematics, physics, and engineering. Most
of these films have attempted to recreate in the classroom experiments and views of real phenomena that
the student would otherwise miss. These films are of
high quality and made by professionals at places such
as the film studios of the Education Development
Center, Newton, Mass., in cooperation with one or
more principals from the academic community. They
have been costly to produce (around $2,000 per minute
of finished film). Because of the growing use of these
visual materials in schools, however, they can be justified as a worthwhile investment that will reap educational benefits for years to come.
Recent advances in computer-graphic technology
are obviously of great interest to educators. Of these
graphical techniques, computer-generated film offers
many attractive potentialities for the same reasons
that studio-made films do. The production of elaborate
visual sequences under interactive control of a human
makes excellent economic sense for educational purposes provided the final product is recorded on film
(or video-tape) for low-cost duplication and distribution to many other viewers. We consider the notion
that these sequences should be produced individually
under the interactive control of a single student for
his sole benefit to be an economic absurdity at present.
The realities of the high cost of computing are all too
evident to those of us at schools struggling to support
even batch-processing utilization of computers for
education. Hence, to those wealthy few, who are fortunate to have such graphical displays available we
direct a plea that they should consider arrangen:ents
by which other interested members of the academic
community can use their facilities for the very beneficial production of computer-animated :films for the
entire community.
In the remaining portion of this paper, we would
like to discuss some aspects of computer animation
that have received sparse attention and yet which are
vital, we feel, to the ultimate success of films as an
educational device. We have heard many papers and
623 - - - - - - - - - - - - - - - -
624
Spring Joint Computer Conference, 1969
much discussion of hardware and software for computer graphics at recent meetings, but virtually nothing
concerning the design of appropriate symbols and conventions for portraying ideas and concepts, Enormously
elaborate and costly equipment is used to produce
images which are primitive and poorly designed to
communicate the desired information. The technical
apparatus of light-pens and data structures has so
monopolized our attention that we have forgotten that
all of this is but a means to an end-the production of
visual images that are superior and more lucid than
the traditional graphical images on paper or blackboard.
Perhaps it is unreasonable to expect those responsible for the development of the hardware and software to also be deeply concerned with the quality and
properties of the graphical images that may be produced, but for those of us in education, this latter
aspect is of ultimate importance. Some of us are making
educational films without benefit of light-pens, online oscilloscopes or immediate access to microfilm
plotters. 1 ,2,3 Typically, these programs have been
worked out on paper; the desired sequences translated
into some appropriate assembly or compiler language;4,6.8 the program run on a machine such as an
IBM-7094 which creates a magnetic tape that is then
sent to an SC-4020 microfilm plotter located in another
city where the actual film is produced and returned
to the originator after a delay of 3 to 20 days or more!
For those accustomed to using interactive graphical
displays, such a tortuous process must appear intolerable. Yet, you may be surprised to learn that the long
delay has not been as serious as one might expect
because the conceptual design of the storyboard and
the invention of appropriate conventions and schemes
for showing the intended ideas and concepts in an
accurate and perceptually clear way is even more
time-consuming and difficult than the straightforward
task of writing and processing the computer program
to make the film.
It is in the art of showing ideas and concepts that
educators can make their greatest contribution. Although computer-graphic terminals would be nice to
have at every school, these elaborate and costly facilities are by no means essential. For instance, a highschool student, Garrett Jernigan in Raleigh, North
Carolina, has written a short animated film to show
the earth-moon system in true proportion, and to
emphasize that the moon and the earth each revolves
around the center of mass of the earth-moon systema nice lesson in mechanics. The movie starts with a
far-out view of our galaxy, then zooms into our solar
system. After the earth-moon system is identified as
one of the planets moving around the sun, the moon
is shown revolving around the earth, with relative sizes
and distances accurately portrayed. A further zoom
toward the earth reveals on close view that it too is
also nutating around the common center of mass.
Jernigan didn't have even a computer, but he had the
imaginative idea which enabled him to program these
sequences in FORTRAN IV punched onto teletype
tape. These tapes were mailed to Johns Hopkins where
we ran the program on our IBM-7094 and then sent
the magnetic tape containing the graphical instructions
to Polytechnic Institute of Brooklyn for processing on
their SC-4020.
The art of showing
We shall always be grateful to J, C. R. Licklider
tor bringing to our attention nearly 5 years ago a remarkable book by Gombrich. 7 Until then, we had not
been fully aware of how important is cultural conditioning in altering the perception of visual images.
Gombrich examines in depth the notion that all art
(and visual communication, generally) involves illusion
and he shows that a "realistic" representation always
incorporates unrealistic conventions that must first
be learned and then ignored. In our own culture, where
photographic-like representations have been so highly
developed, most people would regard a photographic
portrait of a human head in profile as a more realistic
representation than a Picasso drawing showing both
eyes in a profile view . Yet, if you were to show the two
representations to a visually illiterate aborigine, he
might select the Picasso as the more realistic because
the photograph shows only one eye, whereas most people
have two eyes (as realistically represented by Picasso).
The conventions of perspective, which seem so natural
and absolute to us, are quite unnatural to the savage
who may, in fact, not even recognize a photograph
as a picture but ·see it simply as a blotchy, discolored
piece of paper (which it is!). (Incidentally, although
visually illiterate people may not perceive the content
of a still photograph, they always perceive the moving
images in a motion picture. 8 This observation emphasizes the likely advantage of computer-animated presentations, particularly for elementary and secondaryschool education.)
Unlike the aborigine, nearly all school children in
this country today are extremely literate visua.lly.
It is estimated that on the average they will have
spent between 10,000 to 15,000 hours watching TV
by the time they finish school. The impact of TV on
our culture today is hard to evaluate, but there is little
doubt that it is enormous. For instance, one of us has
found 9 that disadvantaged first-graders of the Baltimore inner-city schools have better developed abili-
Computer Animation for the Academic Community
ties to associate and use common words than the more
privileged children of corresponding age in suburban
schools. Furthermore, by the time children finish elementary school their verbal associative structures
appear to be much further developed than students
of the same age who lived 50 years ago or than students
who today are members of cultural groups in which
TV is little used. to That these effects are a direct consequence of television seems very likely; slum children
spend much more time watching TV than children
in mIddle-class homes where a larger part of their
time is directed by parents and teachers toward other
activities.
These young people of the TV generation seem to
have developed a different kind of visual literacy
than those of us who grew up prior to TV, and new
modes ot visual display may be needed to communicate
effectively with them. The printed word is symbolic,
whereas the TV image is primarily iconic. Yet our traditional modes of communication in science and engineering are still dominated by symbols rather than
by the icons to which the TV generation is habituated.
Here, computer animation offers remarkable possibilities that have never before existed- instead of static images and mathematical equations on the printed
page, we may now create dynamic signs that move
about and develop in self-explanatory ways to express
abstract relations and concepts. These potentialities
for iconic communication of the quantitative ideas
central to science and engineering are only now beginning to be exploited; most of the imagery that we
have seen produced by computer graphics in CAL and
other applications has merely transferred the traditional static signs and symbols from the printed page
to the cathode-ray tube. A dynamic dimension is now
available that requires the invention and development
of new conventions and a visual syntax appropriate
to this new medium if it is to be fully used for communication and education. (These possibilities are
suggested by the computer pantomimes1 ,2 which communicate quantitative concepts without using words
or equations.)
The technical advantages of computer-animated
films have been discussed elsewhere.H Not only is animation produced in this way likely to be much less
costly than traditional animation, but one person can
do the whole thing, from conception of the idea through
programming and production of the final film. It thus
becomes feasible to study alternate schemes for displaying certain ideas by developing at low cost a wide
range of visual materials useful for empirical tests
with student subjects for evaluating the effectiveness
of these different schemes.
625
In making a computer-animated film, if one de~
liberately avoids the use of traditional words and
mathematical symbols and attempts instead to portray all abstract ideas iconically, he quickly learns
that "one word is worth a thousand pictures!" He
also soon discovers that many of the signs traditionally
used in science and engineering are inadequate for
conveying many familiar concepts without first introducing irrelevant .details freighted with erroneous
artifacts and implications. For instance, in some recent
research on the design of symbols for representing
electric circuits,' we found it very difficult to indicate
cause-effect relations. (We finally used an inelegant
anthropomorphic symbol shaped like a human hand
to change the value of the source signal.)
Another unsolved problem is how to portray a continuum field, such as the electric potential around a
set of charges. The portrayal of a vector field using
the familiar stream lines (or lines of force) leaves much
to be desired because the direction of the lines is not
easily shown, (e.g., arrowheads introduce broken-line
segments which violate the portrayal of smooth continuity of the field). Furthermore, when one attempts
to superimpose two such fields, as in demonstrating the
superposition of forward- and backward-traveling waves
on a transmission line, a whole host of spurious effects
result as field lines cross each other or vanish and reappear from nowhere, and perform other atrocities.
These difficulties arise even in showing simple, twodimensional fields; traditional conventions are completely inadequate for portraying general vector fields
in three dimensions. New ideas are badly needed for
representational schemes that will be free of these
bothersome artifacts.
The theory oj showing
In his recent important book, Bruner (who is the
country's leading cognitive theorist) has suggested12
that the acquisition and understanding of information
generally proceeds through three stages:
1. Manipulative
2. Iconic
3. Symbolic
-personal action
-perceptual organization and
imagery.
-use of public language and
other private representations.
These stages occur in the development of every
child. In the beginning, the child manipulates and
experiences things surrounding him in a most intimate
and direct way. Later, he recognizes things by their
appearance, and the images in his environment acquire
an autonomous status as he explores the similarities
626
Spring Joint Computer Conference, 1969
and differences among the concrete objects around
him. The child begins to observe that things are related
to other things in more or less predictable ways. As
he becomes aware of geometrical and other invariants
in his environment, he is abie to make predictions and
extrapolations from what he perceives on any single
occasion and to further refine his internalized model
of the world. A major advance occurs when he gives
symbolic names to these perceptions and reiatiollilhips
and gradually begins to use words to stand for objects
not present. Finally, through absorbing a generalized
syntax and semantics, he learns to use words and other
symbols to deal with ideas and thoughts for which
there are no direct referents in immediate experience.
As intellectual development moves from enactive
through iconic to syrr,};olic representations of the world,
each level serves to define the elements of the next
higher level. Like nested macro instructions in a compiler' the abstract symbols expand into more primitive
instructions that are often iconic so that the abstract
symbols will have concrete meaning. If the learner has
a well-defined symbolic system, it may be possible to
bypass the first two stages and communicate with
him purely at the symbolic level. But too often, the
learner may not possess the imagery to fall back on
when his symbolic transformations fail to solve the
problem, and for many persons it may be impossible
to rely entirely on a completely symbolic mode.
We wish to draw an analogy between the process
of programming a computer and the process of instructing a student that may (like most analogies) be of
questionable value, but it will serve to emphasize a
worthy point. A source program in a high-level language, like FORTRA...~, is purely symbolic and, by
itself, has no meaning to the computer until expanded
into a more primitive set of assembly instructions
which are recognizable by the machine. Insofar as
the computer is concerned, these assembly instructions
are iconic. But they, in turn, must be defined in terms
of actual manipulative actions performed by the builtin operations of the machine.
In terms of this analogy, the major task of instruction
is to provide the computer with a useful compiler,
rather than with a multitude of FORTRAN source
decks. Certainly no one would attempt to read a FORTRAN program into the computer before a working
FORTRAN compiler had been entered into its memory.
Yet, the analog of this is attempted every day in the
instruction of students. No, that is not quite correct:
a FORTRAN compiler is, in fact, first entered-but
it, too, is written in FORTRAN!
In his closing paragraph of Chapter 3, (page 72),
Bruner states12
"Finally, a theory of instruction seeks to take account
of the fact that a curriculum reflects not only the nature of knowledge itself but also the nature of the
knower and of the knowledge-getting process. It is
the enterprise par excellence where the line between
subject matter and method grows necessarily indistinct.
A body of knowledge, enshrined in a university faculty
and embodied in a series of authoritative volumes, is
the result of much prior intellectual activity. To instruct
someone in these disciplines is not a matter of getting
him to commit results to mind. Rather, it is to teach
him to participate in the process that makes possible
the establishment of knowledge. We teach a subject
not to produce little living libraries on that subject,
but rather to get a student to think mathematically
for himself, to consider matters as an historian does,
to take part in. the process of knowledge-getting. Knowing is a process, not a product."
CONCLUSION
What, then, may be concluded from all of this? We
believe that there is tremendous untapped potential
in the use of iconic modes of communication to give
fuller definition to the symbols that so dominate the
classroom today. There is a paucity of experimental
evidence on this issue. Nevertheless, we have prepared
a self-instructing text for use at the early college level
to teach the major concepts of modern system theory
by using the highly iconic notation of signal-flow
graphs. 13 Judging from student response this approach
has been very effective. In another vein, the studies
of Rohwer 4 show that pictorial presentation of pairs
of objects to elementary-school children leads to better association between the objects than verbal presentation of pairs of words representing the objects.
At the college level, this difference vanishes, reflecting
probably the greater symbolic competence of the older
person.
What may be true is that the iconic stage, largely
ignored, has had an aborted development. Who knows
what the potentialities may be? Young children, adults,
people who have never been "hooked" on rea4ing,
are those most addicted to TV-it is as if there is a
vast starvation for meaningful communication that
has never been met by the standard media using printing. Instead of bemoaning this, one could exploit it.
What would happen, for instance, if even modest sums
from Headstart were diverted to producing TV programs of educational use to four-year-olds?
We agree with Bruner when he states (page 34) "that
principal emphasis in education should be placed upon
skills-skills in handling, in seeing and imaging, and
in symbolic operations, particularly as these relate
C-omputer ..A...nimation for the . L\.cadelrjc
.
to the technologies that have made them so powerful
in their human expression." He mentions the increased
visual power and subtlety of students exposed to
courses in visual design, and the experiments by Holton
and Purcell at Harvard with instruction in visual
patterns as a mode of increasing the ability of physics
students to represent events visually and non-metrically. He believes "that we have not begun to scratch
the surface of training in visualization-whether related to the arts, to science, or simply to the pleasures
of viewing our environment more richly."
We believe these theoretical considerations justify
much more effort toward the development of iconic
modes of communication, and that computer animation
can play a major role in these developments, both at
the research level and in the classroom. In particular,
the subject matter of system theory offers many interesting opportunities for visualizing the topological
and dynamic relationships that occur in models of
many fields. It is a stimulating and challenging area
for study. We commend it to you.
REFERENCES
1 W H HUGGINS D WEINER
Harmonic phasors
7-minute, 16 mm black and white silent (computer
pantomime) film
2 D WEINER W H HUGGINS
Response of a resonant system to a frequency step
12-minute, 16 mm black and white, silent (computer
pantomime) film
3 J R MELCHER
Complex waves I: Propagation, evanescence, and instability
26-minute, 16 rom black and white, sound film
COlr~unity
627
the X ational Committee on Electrical Engineering Films
and are obtainable on loan from Education Development
Center, a9 Chapel Street, Ne,,-ton, Massachusetts 02160.
4 K C KNOWLTON
A. computer technique for the production of animated movies
Proc AFIPS Conference 1964
5 F J SARNO
Polygraphics users manual for the SC-4020
Polytechnic Institute of Brooklyn 333 Jay Street Brooklyn
New York 11201
6 W H HUGGINS D ENTWISLE
Computer animated films for engineering education
Final report under Grant OEG2-7-OO2816-3097 U S Office
of Education September 301968
7 E H J GOMBRICH
Art and illusion
Bollingen Series XXXV 5 Pantheon Books 1961
8 M H SEGAL D T CAMPBELL
M J HERSKOVITS
The influence of culture on visual perception
Bobbs-Merill Co Inc Indianapolis 1966
{) DR' ENTWISLE
Developmental sociolinguistics: Inner city children
American Jour of Sociology Vol 74 196837-49
10 D R ENTWISLE
Developmental Sociolinguistics: A comparative study in
four sttbcultural settings
Sociometry Vol 29 196667-84
11 K C KNOWLTON
Carnputer-produced movies
Science Vol 150 November 26 1965 1116-1120
12 J S BRUNER
Toward a theory of instruction
Harvary University Press Cambridge Mass 1967.
See especially Chapters 1 and 2
13 W H HUGGINS D R ENTWISLE
Introductory systems and design
Ginn/Blaisdell Pub Co Waltham Mass 1968
14 W D ROHWER
Complex waves II: Instability, convection and amplification
Social class differences in the role of linguistic structures
in paired-associate learning
23-minute, 16 rom black and white, sound film
Note: All of these films were made under the auspices of
Final Report-Project No 5-0005 Office of Education
November 1967
Graphics in time-sharing: A summary of
the TX-2 experience*
by WILLIAM R. SUTHERLAND and ,JA.:.\1ES W. FORGIE
Massachusetts Institute of Technology
Lexington, Massachusetts
and
MARIE V. l\fORELLO
Keydata Associates
Watertown, Massachusetts
I~TRODUCTIOl\
The TX-2 computer, an experimental machine at
the M.LT. Lincoln Laboratory, has been in operation for
almost 10 years as an on-line, graphically oriented
facility.1 In 1964, a time-sharing system for the TX-2
was started. This system, APEX,2 was to service a
small number of consoles with graphic display capability. To achieve hardware economy, displays were
to be refreshed from main core memory through a
time-shared vector generator providing analog signals
distributed to the individual console scopes. The
displays w.ere to be refreshed directly from a structured
display file as experience with the Sketchpad developments 3 ,4 of the early 1960's had indicated was
highly desirable for interactive graphic applications.
Although the APEX graphic system has evolved
through several generations of display hardware and
corresponding software changes, the initial design
principles of displays refreshed from structured information in main core by a time-shared generator
have remained. This paper is an attempt to collect
and evaluate some lessons learned from our experience
in developing and using this system.
TX-2 is a 36-bit~ fixed-point machine currently with
164,864 words of storage; 139,264 words of 2 J,&BeC or
faster core and 25,600 of 1 }Lsec thin film.fi As part of
the APEX system development, rather elaborate
memory address mapping hardware was added to the
* This work was supported in part by the U.S. Air Force and
under a subcontract of M.LT. Lincoln Laboratory, with support
from the U.S. Advanced Research Projects Agency.
computer.2 A Fastrand II drum provides both bulk
and swapping storage for the system. The TX-2
operation under APEX differs from many contemporary
time-sharing systems in that most (6 of 9) of the user
consoles are physically located in the computer room
and are equipped with display hardware. Limited
remote access is possible via teletype, and a single
remote display console can be used on the system.
In the now customary fashion, the APEX executive
system provides a virtual computer for each console.
For reasons of resource allocation, scheduling, and
protection, input and output operations are not performed directly by user programs but are handled as
executive services. The APEX system provides for
CRT output of graphical information at each console,
and gathers and buffers interactive inputs. These
features are invoked from user programs by supervisor
calls on the APEX system.
Display output
All local display scopes are driven from a single
analog signal generator which handles points, vectors,
curves, and characters. 6 ,7,8 The output of this generator
is time multiplexed on a frame-to-frame basis with
individual intensification signals determining which
scope (or scopes) will display a particular frame.
Both refreshed and storage displays are available as
well as a drysilver printer which can be' switched
manually to obtain a hard copy of any console's display. The speed of the display generator output is
controlled by the display monitor routines to compensate for the differences in useful writing rates between
629---------------------------------------------------
630
Spring Joint Computer Conference, 1969
refreshed and storage scopes. The system currently
handles five refreshed displays which appear to be
about the maximum that can be handled with acceptable flicker under our normal use conditions. There is
no such limitation on the number of storage displays
which could be handled, but in a mixoo system the
painting of a complex picture on a storage scope has a
serious effect on the refreshed scopes because of the
slow writing rate in the storage unit. Some consoles
have bSls/+reatm.u..! d;!tOl
_ [)n,q
I.
usaqe d.a~CI
_ F~rll'he5 usage d.ata
Rtg,onal lc.vd
laiqU
Stor.oqt
Vd.rid 1(5
to,"
of da.fa
listed abovt!
STATES,
iEG~
" rLlMt
usus
Figure I-A schematic of a health informatio n system
C!.ll!"l
Ul1'
that such multiphasic test screening centres could have
on health care, the reader is referred to published papers
on the Kaiser Study.23.24 At this moment, there is no
other lVledical Centre in North America that possesses
the test screening facilities and the requisite data processing facilities employed by the Kaiser group, although the proceedings of the 1968 Conference/Workshop on Regional ~1edical Programs suggests that
Tennessee, IVIissouri, Indiana and Connecticut will
soon achieve working systems in various areas of those
states. [The matter of whether the optimum mix of
tests is in use at Kaiser or whether all the tests given
are required will only be answered by a research effort
lasting several years, and will not be discussed further
here.] As the 1966 Senate hearings23 and the above
mentioned conference/workshop25 reveal, several other
entities in the U.S.A. are moving in the same direction
as Kaiser, a situation that, at some time in the future,
will require a linking of information flowing from test
screening of large populations in different areas of the
U.S.A. Despite the reservations of some physicians who
see test screening with automated follow-ups as an encroachment on their professional sanctum sanctorum,
there is sufficient reason to expect that only inadequate
f1mding of such efforts, and perhaps a lack of improvement in computer speed and core storage, at reduced
cost could halt any impetus arising from Kaiser's development at Oakland.
The Medical Systems Development Laboratory
input in a manner similar to that depicted in Figure 1,
to large epidemiological studies of health communities.
The projects referred to are:
(i) the Kaiser Permanente Multiphasic Test
Screening System at Oakland, California.
(ii) the Medical System Development Laboratory
of the National Centre for Chronic Disease
Control of the U.S. Public Health Service system for EKG recording and analysis.
(iii) the on-going record linkage studies in England,
Maryland and New York in various health
populations.
(iv) the Medical Audit Program and Professional
Activity Study (PASjlVIAP) of the CPHA.
The Kaiser Permanente multiphasic test
screening system
At Kaiser Permanente .l\ledical Centre in Oakland,
California, a major research effort in the use of multiphasic test screening for preventative health care has
been in progress since 1964. (For a detailed treatment
of the form of testing and an assessment of the impact
The Medical Systems Development Laboratory has
developed a computer system to measure values of
heart rate, amplitudes and durations for wave-forms
of the standard 12-lead ECG and to make an Englishlanguage translation of these measurements. During the
past four years, over 75,000 ECG's have been processed,
and it has been shown that, with limited direction from
medical personnel, the system is useful in the detection,
management and rehabilitation of persons with cardiovascular and associated diseases. Furthermore, the
system decreases observer error and variation, reduces
ECG costs and conserves scarce physician time for
direction patient care. 4
.l\fore significantly, a plan for a nationwide data pool
of computer processed ECG's has been put into effect,
with 35 investigative groups participating during the
first year, with a combined annual output of 70,000
ECG's and an anticipated 200,000 in the second year.
Also, it has been shown that it is feasible to process
ECG's and spirograms from remote sites using conventional telephone circuits in an on-line, real-time
mode, and also that outpatient care and emergency
room services are possible.
698
Spring Joint Computer Conference, 1969
As research into heart disease is a major concern
at this moment, it is not difficult to imagine the effect of
a nationwide data pool of information in a research
effort: nor is it difficult. t.o t.ie t.he jmpact. of such rese9"rch
into the type of multiphasic screening approach in
operation at Kaiser and other centres. The whole concept of preventative health care assumes new proportions, particularly if each health region, chosen by
criteria as yet not universally agreed on, was financially
capable of supporting the screening and data processing
facilities required. The Tennessee Mid-South proposals
for such a system are indicative of trends in this direction. 26
Medical record linkage study
In various areas of the world, particularly in the
U.S.A. and England, research into various aspects of
comprehensive patient care as revealed by record linkage is proceeding, with the Oxford (England) studies27
and the Maryland Psychiatric Case Register studies,28
probably the best documented. Compared to the two
previous research endeavours, this research is typically
centered on a region, even though the New York studies28
are centered on a smaller population. The fundamental
problem experienced in the Italian studies,27 the lack
of data in a suitable format or the lack of data at all,
has been met in all studies to date, and it is not difficult
to postulate that the existence of data at municipal,
regional and state level must precede any substantial
research findings at a national level. The recent proposal
of a research effort by the MRC in England 30 is fundamentally the first step in the right direction.
The PAS/MAP system
At a national level, a research effort enabling a
medical audit of over 1240 hospitals annually discharging nearly 10 million patients across the U.S.A.
(and other parts of the world) has been in progress for
some years through the facilities of the Commission on
Professional and Hospital Activities, which is an educational and scientific organization sponsored by the
American College of Physicians, the American College
of Surgeons, the American Hospital Association and the
Southwestern Michigan Hospital Association.
Inherent in this system of medical audit (called the
PAS/MAP system) are two basic criteria:
• the establishment of a standard relevant to the
different treatments being given in hospitals
• accurate reporting of the actual treatment given
to the patient during his stay.
Since the participating hospitals, in reporting their
monthly statistics to the central computer facility in
l\fichigan, are forced to code their treatments into a
fixed format reporting sheet, some measure of standardization is present, but it would be unrealistic to think
that all relevant information on a patient treatment
can be included on any fixed format coding sheet. For
this reason, while the PAS /l\1AP is a first step towards
a nationwide pool of information (since 1240 hospitals
is not the full complement of hospitals in U.S.A.), there
appears to be a real need to incorporate systems such
as PAS/IVIAP (or the Pittsburgh HUP system) within
a national plan of health care funded by the national
govem..-rnent, and Vvith all health care units, down to the
smallest nursing home or hospital, participating. The
possibilities for the rational disposition of the nation's
funds for new or improved health facilities in the smallest region, as distinct from the ad hoc methods in vogue
in most nations of the world, are apparent here, as are
the possibilities of comparison of cost and effectiveness
of patient care in different regions. The development
of realistic simulation models of health care for the
nation looms as a possible output (given sufficient research into the validity and extent of the input parameters of the health care process), enabling long term
planning of expensive health care facilities to be undertaken. Some results reported by Centner et al. 3 and by
Ryan and Dillard 32 are significant steps in a move towards the Total Health System Model, as is the steady
progress being made in econometric modelling of the
health sector by Feldstein,33 Yett and Mann 34 and
others.
Problems of health information system research
rationalization
Introduction
As Elam has noted, " ... our problem [in America]
is not that we lack technology; we have enough to
frighten us all. It is not that we lack a concept of comprehensive health care or that there have not been
isolated attempts to practice it. What we do not have is a
marriage of technology and comprehensive personal
health care, and an' assessment of the results (emphasis
supplied). . . ."26
As has been suggested earlier, the success of Collen's
work at Kaiser Permanente (and Jungner's work in
Sweden) has led to proposals for similar systems in
regional medical programs now developing as a result
of Public Law 89-239. One of the most significant of
these programs is the Tennessee Mid-South Regional
Medical Program described by Elam,26 where researchers are attempti:qg t~ determine whether comprehensive, family=oriented health care in a neighbor-
Health Information and Planning Systems
"hQQd health centre cQQrdinated with an autQmated
multiphasic screening labQratQry will result in imprQved mQrtality, mQrbidity, health service utilizatiQn
and health attitudes amQngst a PQPulatiQn. The determinatiQn Qf whether such a prQgram reduces the
CQst Qf medical care and, at the same time, whether it
imprQves and restQres the family unit, is also. prQPQsed.
There are many Qther Qn-gQing develQpments acrQSS
the U.S.A. fQr similar studies to. implement the aims Qf
Public Law 89-239. Since these prQPQsals invQlve the
use Qf health care facilities including hQspitals, what are
the likely prQblem areas that might fQrestall the
achievements expected fQr cQmprehensive health care
using autQmated health infQrmatiQnsystems?
The problem areas
The majQr prQblem areas are thQse already discussed
in the paper to. this PQint, and essentially they are related to. reSQurces-manpQwer, mQney, machinery-and
to. the methQd Qf attack.
Manpower - As has been suggested, manpQwer prQblems will PQssibly appear in varying prQPQrtiQns Qf:
• medical personnel with little Qr no. knQwledge Qf
autQmatiQn, even at such a level as WQuld render
the automatiQn Qf screening prQgrams mQre meaningful to. them .
• systems analyst/programmers with little Qr no.
knQwledge Qf medical systems.
If we cannQt sQlve the manpQwer prQblems that exist
in current iSQlated hQspital prQjects, there WQuld seem
to be little chance Qf adequately staffing regiQnal develQpments Qf health infQrmatiQn systems, particularly
if all systems require staffing Qf the Qrder suggested
belQw.
Costs - The financial crunch that has hit all sectQrs
Qf the eCQnQmy will WQrsen' the fundiot?; situatiQn fQr
medical research prQgrams such as enVisioned by
Tennessee, 9Qnnecticut a:r;:td Qther fQrward-looking
states. It is wQrthwhile recQrding the actual level Qf
CQst Qf autQmatiQn in hQspitals that have grQuped together by studying the IndianapQlis HQspital AssQciatiQn repQrt36 Qn estimated expenditures, and attempt
to relate N repetitions Qf such a cost to a natioswide
hookup Qf health care systems.
FQr a cQmputer system capable Qf SUPPQrting thirteen area hQspitals (6000 beds plus) and five health
agencies, the prQPQsal estimated that
.79 people WQuld be required in the periQd 1968-71
to administrate, analyze, design, prQgram and
Qperate the system;
699
• the system, if cQmmenced in 1966, WQuld CQst
$9.4 milliQn by the time all aspects Qf the system
were Qperating in 1971, at which time the Qperating CQst WQuld be $2.4 milliQn per annum.
It is emphasized that the IndianapQlis studies are
just Qne Qf a number Qf shared hQspital cQmputer
studies QngQing at this mQment in the U.S.A. Assuming
that such hardware and people SUPPQrt is capable Qf
performing the data processing tasks of an automated
(in the equipment sense) "multiphasic test screening
labQratQry fQr a regiQn cQntaining hQspitals and health
agencies, the CQst Qf renting autQmatic, multichannel
analyzers plus the CQst Qf reagents is estimated at
being in excess Qf $0.20 per test, withQut allQwance fQr
labQr, space and allied CQstS.36
Hardware - As has been indicated earlier, the hardware required fQr cQllecting and prQcessing multiphasic
test screening data is already in use at Oakland, but
when many hQspitals are linked tQgether in remQte
access to a central facility, the size, speed and CQst Qf
direct access stQrage, plus the input terminal prQblem
PQsed earlier, WQuld still be present.
Thus, certain elements Qf a cQmprehensive health
care prQgram can already be autQmated, while Qthers
will depend very much Qn manufacturer mQtivatiQn befQre wQrthwhile results will appear.
In essence, it WQuld appear that existing systems
staffing shQrtages, CQupled with the current lim~ted
level Qf cQmputer expertise in the medical prQfessiQn
and the need to. pressure manufacturers to. prQvide
reliable wQrking hardware fQr a large-scale remQte
access, time shared hQspital QperatiQn, should lead to.
the cQnsolidatiQn Qf all that is gQQd in Qn-gQing hQspital
autQmatiQn prQjects into. Qne Qr two. prQjects supporting
a comprehensive health care system.
This cQnsolidatiQn Qf expertise, funding and pressure
Qn manufacturers by the federal government and by
grQUps such as SIGBIO, WQuld result in the one Qr t~Q
prQjects being adequately funded and supPQrted WIth
staff and equipment CQmmensurate with the system
needs. It WQuld nQt necessarily mean the future cutback Qf funds Qn all Qn-gQing prQjects, but WQuld
prQbably mean that the rate Qf increase Qf new projects
might decrease.
At this mQment, it is dQubtful if subsequent evaluatiQn Qf the efficiency Qf such cQnsideratiQn WQuld nQt
indicate
• better use Qf the available human resources (systems and medical)
• a favQurable benefit/ CQst ratio. cQmpared to a proliferatiQn Qf smaller projects
• that manufacturers reacted apprQpriately to. pressure to design equipment fQr such systems.
700
Spring Joint Computer Conference, 1969
CONCLUSION
Some of the more significant problems and issues in
medical automation have been discussed, and related
to each other.
It is suggested that current human resource shortages, together with the costs of and working efficiency
of large-scale computer hardware facilities, should
lead to a consolidation or rationalization of on-going
research into medical automation..
The effects of automation within a comprehensive
health care system might really be felt if such rationalization led to more efficient use of all resources, financial
and others.
ACKNOWLEDGMENTS
The critical advice of Drs. Barnett, Caceres, Collen,
Lamson and Vallbona through their correspondence,
is greatly appreciated, as is the typing expertise of
Miss S. Wenger, Secretary of the Faculty of Administration, University of Saskatchewan, Regina.
11
12
13
14
15
16
17
BIBLIOGRAPHY
P F GROSS
The computer in health care: Needed-A. plan for
development
World Hosp:tals Vol 4 : 4 189-200 October 1968
2 M F COLLEN
The multitest laboratory' in healh care of the fu'ure
Hospitals JAHA 119-125 May 1967
3 D LINDBERG
Computers and medical care
Spr:ngfield IlLno:s Charles C. Thomas 1968
4 C CACERES
In: Computer.], electrocardiography and public healthA nport of recent studies
PHS Publication 1644 USPHS US Depar~ment of
Health Education and Welfare June 1967
5 C VALLBONA et al
A non-line compu,ter system for a rehabilia/rion hosp1:tal
Methods of Information in Medicine Vol 7 : 1
31-39 January 1968
o B G LAMSON
Data processing in a medical centre""-Progress report 1966
Department of Patho!ogy Schoo! of Medicine Center for
the Health Sciences University of Californ:a Los Angeles
1966
7 Massach'USetis General Hospital Computer Projec'Progress Report May 1966 to September 1967
MGH Memorandum 10 October 1967
8 Personal communication from Dr. O. Barnett of
Massachusetts General Hospital 28.1.69
9 N LINDGREN
Future goals of engin'3ering in biology and medicine
IEEE Spectrum 93-100 November 1967
10 G 0 BARNETT H J SUKENIK
Hospital information systems
18
19
20
21
22
23
24
Inv:ted paper given at NJH Conference
Future Goa~s for Engineering Biology and Medicine
September 9 1967 reproduced in MGH Memorandum 10
October 19 1967--.see reference 7
P F GROSS
Crisis in system education
Canadian University 3:4 30-33, 56 June 1968
P F GROSS
Systems education-Needed: A reass,essment and upgrading
Faculty of Administration University of Saskatchewan
(Regina) January 1969 (mimeo)
P B HOFMAN W A GOUVEIA G 0 BARNETT
Computers: great future perilo'US present
Modern Hospital July 1968
G 0 BARNETT R A GREENES
Interface aspects of a hospital information system
Paper presented at N ew York Academy of Sciences
Conference on Use of Data Mechanisation and Computers
in Clinical Medicine January 15'--17 1968
G SAMUELS
~~1ed7ico-legal aspects of clinical records
National Hospital Volll : 5 9-18 February 1967
E SPRINGER
You, the computer and the law
Medical Record News 15 February 1965
J SEGALL
Legal implications of autornated hospital information
systems
Paper presented at the Conference on Advances in the
Applications of Computers in Hospital Management
University of Michigan Engineering Summer Conference
May 15-19 1967
F MOORE
Health information systems: Volumes 1 and II
University of Southern California School of Medicine 1962
(Available from USC Bookstore 2025 Zonal Avenue
Los Angeles 33)
New contracts
Computers and Automation 50 September 1967
K BARTSCHT R JELINEK
A management information and control system for
health services
Paper presented at University of Michigan Engineering
Summer Conference on Advances in the Applications of
Computers in Hospital Management May 15-19 1967
C FLAGLE
CriteloW for evaluation of health service informatio-n systems
Paper presented at University of Michigan Engineer:ng
Summer Conference on Advances in the Applications of
Computers in Hospital Management May 15-19 1967
C FLAGLE
Implications of health service information systems
Paper presented at University of Michigan Engineering
Summer Conference on Advances in the ApplicaCons of
Computers in Hospital Management May 15-19 1967
Detection and prevention oj chronic disease utilizing
multiphasic health screening techniques
Hearings from the Subcommittee on Health of the Elderly
of a Special Committee on Aging-U.S. Senate 49th
Congress Second Session September 20-22 1966 U.S.
Government Printing Office
M COLLEN
The rnultitest laboratory in health care of the future
Hospitals JAHA 119-125 May 1 1967
Health Information and Planning Systems
25 Proceedings of conference/workshop on regional medical
programs January 17-19, 1968, Volumes I and II
National Institute of Health US Public Health Service
US Department of HEW Washington DC
26 L ELAM et al
Health evaluatiOn studies utiliz.ing a multiphasic screening
centre operating with a comprehensive health care program
for persons in an urban poverty area
In 25 Volume II 1-4
27 Mathematics and computer scie'nce in biology and medicine
Proceedings of a Conference held by [U,K.] Medical
Research Council in association with the Health
Department Oxford July 1964
28 W PHILLIPS
Record linkage for a chronic disease register
Paper presented at the International Symposium on
Medical Record Linkage Oxford England July 1967
29 D NITZBURG
The methodology of computer linkage of health and vita'
records
:~O
31 S CENTNER et al
Computer simulations to assist rational resources allocation
in health science education
Health Science Functional Planning Unit
University of Toronto November 1967
32 J RYAN C DILLARD
A. computer model of the total emergency care system
Paper presented at 6th Annual Southeastern Regional
Meeting of ACM and National Meeting of Biomedical
Computing University of North Carolina June 15-17 1967
:3:3 M FELDSTEIN
Economic analysis for health service efficiency
Amsterdam North-Holland Publishing Company 1967
34 J K MANN D E YETT
The analysis oj hospital costs: A review article
The Journal of Business Vol 41 : 2 191-202 April 1968
35 EDP implementation planning study, technical report,
Indianapolis hospital development
Information Science Associat.es Cherry Hill New Jersey 1966
36 D SELIGSON
Reprint from Social Statistics Section-Proceedings of
Amer Stat Assoc 1965
Provision of optimum chemical laboratory services for
3,000,000 people
U.K. council proposes medical data bank
In Proceedings of Conference/Workshop on Regional
Medical Program op cit 4-6
Datamation 105-106 September 1967
701
Computer assisted instruction in the
diagnosis of cardiac arrhythmias *
by E. J. BATTERSBY
V anderbilt University School of Medicine
Tennessee
~ ashville,
INTRODUCTION
Disorders of heart rhythm, known as cardiac arrhythmias, are most accurately diagnosed from selected
electrocardiographic (EKG) tracings. Their interpret~tion is necessary for the correct treatment, somet~mes o~ an emerge?-cy basis, of a large number of patIents WIth heart dIsease. Analysis of the contour and
sequencing of component waveforms taken with the
knowle~ge of the set of defined electrophysiologic
mecharusms allows categorization and in most instances
specific identification of the rhythm. Most of these
dia~oses depend upon the specification of the site
or sites of electrical impulse generation in the heart
and its subsequent spread through speciali~ed conduction pathways. The logical process leading to the
diagnosis is inferential because the tissues involved
in impulse generation and specialized conduction are
of suc~ small mass as to have no direct electrical representatIOn on standard EKG leads. Only the electrical
activation of larger masseE of cardiac tissue as a resultant of those fundamental mechanistic events produces the component waveforms of the clinical electrocardiogram.
It is the purpose of this paper to describe a digital
computer simulation of the events that are the determinants of cardiac rhythm and the resultant activation
of those portions of the heart that result in the generation of the clinical electrocardiogram. The simulation
is intended to assist instruction in the inferential process of arrhythmia diagnosis. A number of analog devices with a restricted repertoire of rhythm disorders
* This publication is supported by the following Grants:
US, PHS Career Development Award, Grant #1-K3-HE-10
130
!
US, PHS Program Project Research Grant #HEO 8195
US, PHS Cardiovascular Training Grant #5 T2 HE 5025
are available but to the author's knowledge the system
described herein is the first allowing programming of
the basic mechanism of rhythm determination.
To be useful in training medical and paramedical
personnel in this important subset of clinical electrocardiography several goals must be met. The language
of coding used to change basic mechanisms must be
minimal and in phrases acceptable to a student of electrocardiography. The simulation should be based
upon accepted mechanistic behavior of well defined
electrophysiologic components and not merely a set
of arbitrary "function generators". The output of the
simulation should be an analog signal that appears to
the student as a bona fide EKG lead as would be recorded from a patient in real time. Changes in the
behavior of the underlying mechanism during the
course of a rhythm strip generation must be implementable with display of the resultant without any
break in continuity of the analog output across the point
of change of mechanism. Not necessary but desirable
from the pedagogic point of view would be expansion
of the time base of the output to provide a "slow motion" electrocardiogram for oscillographic viewing.
Two versions of this program have been implemented.
One is in Fortran IV and was written to define the
logic in an easily communicable form and to yield a
detailed sequential listing of events to provide interactions of events. The version described herein in detail is written in assembler language for an SCC-650/2
digital computer with a 12 bit word length and 8 K of
memory. During the input of parameters, each command is evaluated for syntax and the appropriate
parameters inserted into the model. When a command
is given to execute the model, a poll of all the functional
modules is conducted at a simulation interval of 1/200th
of a second. As particular portions of the simulated
heart are fired, those contributing to the EKG appear
-----------------------------703 -------------------------------
704
Spring Joint Computer Conference, 1969
as a string of numbers stored in memory. The form of
each type of waveform is available in a pre-defined
list. At the time of display the string is passed to the
D-A converter for display.
Operational logic
Pacemakers
After electrical discharge a pacemaker region undergoes a predictable recovery cycle leading to spontaneous discharge if uninterpreted. This type of periodic
behavior is the mechanism that allows the heart to
produce its own intrinsic repetition cycle. During the
initial phase of recovery the pacemaker is said to be
refractory and is insensitive to waves of depolarization
travelling in adjacent tissue. After this refractory period
local discharge may "enter" the pacemaker region and
discharge it causing it to return to the beginning of
the recovery cycle. This is known as pacemaker ~eset
ting and pacemakers protected from this discharge
from without are known as parasystolic. When repeatedly reset from without the duration of the recovery period from onset to spontaneous discharge may
be lengthened and when subsequently released from
such suppression will gradually return to its basic
period over the course of several be,ats. This escape
phenomenon is termed warming. For the description
of these kinds of pacemaker behavior five specifications
are necessary. The length of the refractory period is
set as fixed data. The pacemaker command in the simulation language supplies an identification number,
a number describing the length of the spontaneous
Figure I-Pacemaker logic flow
This is the chain of tests performed on each simul2.tion cycle
of a pacemaker. Further description is in text
discharge cycle and' two Boolean variables specifying
whether or not the parasystolic and warming phenomena are in effect. Thus, with blanks as separators
a typical cO!!LTP..and appears as follows: P2 75 W; which
specifies that pacemaker two has a cycle length of
0.75 seconds and exhibits warming. The absence of a
P in the third argument means that the parasystolic
bit is not altered. The location of pacemaker two in
the geometry of the heart will be considered in the
Interaction section.
Figure 1 describes the logical steps for a pacemaker
during a single cycle of the simulation. Excepting
some details it may be read as follows:
IF
local depolarization has occurred and
the pacemaker is neither para...'3ystolic
nor still refractory
THEN
reset the clocks and GO TO EXIT
ELSE IF if the discharge clock countdown is
complete
THEN
set the indicator to note attempt to
fire adjacent tissue and reset the clocks
EXIT
reset the local depolarization counter.
Specialized conducting tissue
The most important functional elements of the
specialized conduction system join the two upper chambers of the heart, the atria, with the two lower chambers, the ventricles, as a conductor of impulses in either
direction. A~ there is ample physiologic evidence that
alterations ih conduction may occur at several levels
in this longitudinally distributed pathway it is simulated by a chain of similar modules that may be separately controlled by parameter modifications and which
interact with adjacent elements. This pathway, because of its relatively slow conduction velocities provides a delay in normal circumstances between the
electrical activation of the upper and lower cardiac
chambers. In abnQrmal situations, it may produce
an unusually long delay or fail to conduct. This transmission line, known by several names to electrocardiographers, will be called the junctional tissue in this
paper.
A typical recovery pattern for t:b.,is junctional tissue
may be divided into four phases in terms of its behavior
in transmitting impulses. For an initial period of time
following discharge the tissue is said to be refractory
meaning it will not respond in any way to the arrival
of an impulse. In the second phase, impulses may be
partially conducted in the region but will not in turn
execute the next succeeding segment. Sequential con-
C01:nputer Assisted Instruction in Diagnosis of Cardiac Arrhythmias
duction will f9.i1 as in phase 1 but the partial discharge
of the segment will result in resetting of the recovery
sequence back in time. The effect upon subsequent
conduction behavior for impulses arriving later may
be different. In phases 3 and 4 sequential conduction
does occur. In phase 4 after full recovery the conduction delay is a fixed minimal time. In phase 3, still
incompletely recovered, the segment conducts with
a delay that is a nonlinear function of the time still
necessary to accomplish full recovery.
A typical. command specifying the behavior of such
a segment appears as follows: J3 100 40 10; denoting
that junctional element three requires 1.0 second for
full repolarization of which 0.4 seconds is the length
of phase 3 and 0.1 seconds is the length of phase 2.
Phase 1 is the remainder· and the fixed delay of phase
4 is fixed data in the program.
Figure 2 shows in schematic form the logic of this
type of conduction module. Boolean "up" and "down"
are specified so as to indicate the direction of conduction. Thus, when an impulse is passed to such a segment
simulator a directional indicator is passed which will
determine the subsequent passing sequence if the segment conducts. The initial test is to determine if the
impulse pass bit is set. If it is the recovery clock is
checked for phase. If in phase 3 or 4 the delay is calculated and used to set the impulse clock and the directional flags are set. If in phase 2 the recovery clock is
partially reset and no impulse action is taken. No
action is taken if the impUlse switch is off on entry or
if it is on and the segment is in phase 1. Then the
clocks are advanced and at a cycle when the impulse
From Exteraal
I
PHASE
I
a_
, ___
IWPULSE
PHASE
loa.
J:NTaT
PHASJ:
z
~~.
eee
Figure 2-Junctional element logic flow
This is the chain of tests perlormed on each simulation cycle
of a Junctional Element. External Routines refer to similar
logical modules of adjacent ·Junctional Elements. Further
description in text
i05
clock countdown is completed an impulse will be passed
in the direction prescribed by the directional flags.
Certain abnormal rhythms are attributed by electrophysiologists to reentry paths. These are conduction pathways isolated in such a way as to be protected
from complete discharge by a wave of electrical depolarization passing through their region. Rather they
are shielded and slowly conducting conduction limbs
whose cycle is initiated by a passmg impulse and whose
transit time is slow enough that when they exit locally
or in nearby tissue they may initiate another impulse
propagation. This cycle may then recur or be extinguished on the next pass. These may behave in certain
instances as "rebound pacemakers" and in other instances to return impulses back through a strip of
specialized conduction tissue in the opposite direction
from which it entered.
The reentry command has the form R4 20 3; in
which the first specification identifies the rebntry path,
the second specifies a delay of 0.20 seconds, and the
third argument allows a single digit of zero through
eight that sets up "chances-in eight" of the event
occurring at any particular trial by reference to a random
number generator.
This type of logic may also be used to specify bypass
pathways of conduction with fixed delays that are
invoked to explain certain types of abnormal impulse
propagation.
Interaction
The communication among the elements described
above and the larger masses of cardiac tissue whose
electrical activity is seen in the standard electrocardiogram depends upon their relative geometric disposition
as well as their functional properties. Figure 3 shows
the spatial relations of the elements simulated in the
model. The principal potential pathways of conduction
are indicated by directed arrowheads. Programmed
reentry loop paths are omitted for simplicity.
The spread of excitation in one of the elements of
the atria or ventricles has several consequences. It
may reset the spontaneous depolarization cycle in an
adjacent pacemaker. It may after a period of time
initiate activation of an adjacent element. It will supply
from a table amplitude information to the D-A converter routine for display. Since the direction of depolarization of the portions of the atria may be either
upward or downward and the direction of the ventricular septum rightward or leftward, and since this
will affect the resultant waveform, these possibilities
are accounted for in the program and the waveform
element tables. The waveform of repolarization of
ventricular elements is seen on the surface electro-
706
Spring Joint Computer Conference, 1969
2. Those concerned with storage and display of
the rhythm strips.
3. Exits out of the command program and input
TOP
z t>,==:::!::=:::
ATRIA
;ta~~na
"'ala...~I"Io"I'CI
.a.vv ~\.J~\.JV uv~a.;;;r.
BOTTOM
t>
O
\A.\J Y
PACEMAKERS
JUNCTIONAL
ELEMENTS
6
RIGHT
SEPTUM"
LEi"T
VENTRICLES
Figure 3-Disposition of the simulated portions of the heart.
Note that a string of junctional elements connects the atria
(the upper portion of the heart) with the ventricles (the lower
portions of the heart). The septum is the wall separating the
two ventricles
cardiogram and is supplied to the display modules.
Note that transmission from the fifth junctional
element downward is by two pathways, one to the
right ventricle called the right bundle branch and one
to the left ventricle and to the left side of the septum
called the left bundle branch. Normally, conduction
down this latter pathway will cause left to right depolarization of the septum. Since certain changes
in the EKG waveform will result from deletion of
either or both of these pathways, such an option is
included in the programming language.
Simulation language
An interpretive program for the simulation language
was written in assembler language for an SCC-650/2
digital computer with 8 K of memory and a 2 microsecond cycle time. This allows teletype input of commands and viewing of the output immediately after
construction of a rhythm strip either on an oscilloscope
face or a strip chart. So as to be able to execute previously tested programs in the simulation language~
command strings can be input from paper tape. For
the remainder of this discussion keyboard input will
be assumed.
Commands in the language may be divided into
three types:
1. Those that establish electrocardiographic parameters.
Each command is preceded by a colon supplied
by the program and indicates readiness to accept the
command. Each command is terminated by a semicolon and at any time prior to the entry of the semicolon terminator, a colon may be used to delete the
command. Comments fields are admitted. A command
is syntactically evaluated after the entry of the semicoln
terminator and before execution. Syntax error messages are generated and allow immediate reentry of
a correct command.
Type I commands that determine EKG parameters
are those described under pacemakers, junctional
elements and reentry paths and four others. Time of
the simulated rhythm strip in integer seconds from
one to thirty may be specified by the command:
TIME 8 SECONDS; A command exists establishing
normal parameters so that the rhythm will be produced by pacemaker one and transmitted without
conduction delay or disturbance resulting in normal
sinus rhythm in the electrocardiographer's language.
This is of the form:
NSR; and is useful in establishing baseline initial
conditions. Lead selection commands allow the operator
to view either of three lead displays. Lead II is the
standard body surface lead used in rhythm diagnosis
and is established by the command:
LEAD II; In addition, a lead taken in special circumstances from within one of the atria in which the
atrial deflections may be more clearly discerned may
be designated. Finally, a lead not available to the
clinical electrocardiographer is generated which shows
by spikes the passage of conduction through any or
all of the junctional elements. The command:
BBBL; establishes block of the left bundle branch
and commands :;Ire available to create or remove block
of either the left or right bundle branch.
Storage and display commands allow storage and
retrieval for display of generated rhythm strips. The
command:
UPDATE; states that the operator is ready to begin
generation of a new string of rhythm strips. This simply
resets a memory pointer. If it is desired to have the
rhythm strip displayed on an output device during
generation the command:
VIEW; is used. This will generate the segment according to the functional element parameters then
present. The command:
ENTER; will do exactly the same but without
display. Display of the sequence of arrhythmias gener-
Computer Assisted Instruction in Diagnosis of Cardiac Arrhythmias
ated since the last update command without break
in continuity is accomplished by the conunand:
DISPLAY;
Other conunands are not formally part of the language but used in the present implementation to transfer control to a debugging program and a device flipflop that transfer control to the paper-tape reader
when executed on the teletype and vice versa.
The coding of the simulation language is minimal
and is in terms readily accepted by the student of
electrocardiography. More detailed description of
the command structure is specified in a manual defining the language and, the presentation here is abstracted from that source.
RESULTS
By definition, rhythm changes that are produced by
other than the mechanisms defined in the model cannot be prqduced.They are few and in general not
amenable to the usual type of analysis that this simulation is expected to assist in teaching. While they
might be included in the repertoire by supplying a
list describing them this would not increase the usefulness of the simulator as a pedagogic tool.
A wide variety of important rhythm disorders can
be produced yielding a noise free signal and the opportunity to view special leads that is not usually
available in the clinical setting. The underlying mechanisms are clearly defined by the operator's input commands. Some examples of the tracings produced l>y
the machine will be considered to illustrate certain
features of the system.
Figure 4 illustrates how the display command may
be used to portray as a continuous tracing two segments
that were sequentially created with a change in mechanism between them. The test below the records is the
nonerating program. Strip 1 is a two second run of
normal rhythm. Then the rate of pacemaker three
(upper nodal focus to the electrocardiographer) was
increased and a five second record created. Then, by
use of the display command the entire seven seconds
are seen as continuous record. The point of fusion is
indicated by the triangle.
The interval of time between the onset of the wave
associated with the firing of the atria and that associated with firing of the ventricle is usually constant
in normal situations. If the period of the pacemaker
firing the atria is shorter than the recovery period of
a junctional segment the arrhythmia seen in Figure 5
may result. Because of incomplete recovery this interval is progressively longer until conduction is blocked;
recovery is allowed and the cycle repeats.
Note also the atrial waveform obscured in the
portion of the record indicated by the triangle. An
experienced cardiologist would recognize this. The
short strip below shows the appearance of the special
atrial lead in this circumstance showing the clear presentation of the atrial wave obscured in the upper
tracing which would alert the student to the obscured
wave in the standard tracing.
Figure 6 shows the usefulness of the other lead se-
Figure
5-Demonstr~tion
of the use of the simulated intraatrial lead (bottom strip). See text
!II!!! !!111m! !I!! Iii! i!lllill:ii'I .'
WI~~ ~m !II~ I!!l !!I! i~l! "!' !!~
Iii, ~
"
I!!! iI!~ ;!I! I!!! ! II
·!nu~!!I! 'j~ !:arl!,lil!~ !!1.lrK:: t!!I'~lt
'l!'.......
! 1m Pli'mi
9i ·h 1111111 JIll
!m~
II!'! "if!
I •.•..•"II
I.lt.l.I.
• .•..•
I •. I.II!.!
.. ' ....
:UPDATE::NSR::TIME 2 SECONDS ::VIEW:
(Strip 1)
:TIME S SECONDS ::P3 550 ::Y; ACTIVATES
THE UPPER NODAL FOCUS AT A RATE
SUOHTLY GREATER THAN THE SINUS RATE
OF 100 .:VIEW;
IStrip 2)
:DISPLAY;
(Strip 3)
Figre 4-Demoilstration of fusing of two separately generated
strips. See text
lUI
""''''''''
mnUmnm'iillWi 111i
"
,m
,~,' hUh!' film! In!l ":
I ,: IIUl !fi!ifii !I!i [lit
i,'1
!
I
-
dl
I i!
!;~
ad !II! 7ri! f!Il Iii! fil: !H!
1m
Figure 6-Demonstration of a lead marking activation of one
of the junctional elements (bottom strip). The effect of the nonconducted impulses marked by triangles on subsequent conduction is seen. This is an instance of so-called concealed conduction
708
Spring Joint Computer Conference, 1969
lection option. Here the lower strip shows activation
of one of the junctional elements indicated by a spike.
At the two instances indicated by the triangles the
junctional element is activated by an adjacent pacemaker while LTl phase 2 of its recovery cycle. It does
not propagate the impulse but the effect on subsequent
conduction is seen. In the first case the interval between
atrial and ventricular activation is prolonged (indicated
by the bar) and in the second instance the spread of
the impulse is blocked. This is an example of what
a cardiologist would refer to as "concealed conduction."
Strip chart recordings produced by the system have
been used by the author as instructional material for
continuing education courses for physicians and for
students in the medical school curriculum. On line
oscilloscopic displays have been used in the education
of Coronary Care Unit nurses. At present, there is
no proof that this approach that synthesizes rhythm
abnormalities from underlying mechanisms will allow
students to develop the analytic ability that undergirds arrhythwia diagnosis. A classroom is currently
being supplied with teletype and output devices and
a proposal to train half a medical school class using
the system and the other half in the standard manner
is being entertained. It is hoped that this will yield
information as to whether this experiment in computer
assisted instruction is in fact superior to standard
classroom instruction. The emphasis has been thus
far on the instructor as user, rather than the student,
In the course of the planned evaluation it is expected
that the student will be able to interact with the simulator on an individual basis.
Hospital automation: Something
more than a computer
by WALTER L. BENNETT, CHARLES F. STROEBEL
and BERNARD C. GLUECK, Jr.
The Institute of Living
Bartford,. Connecticut
INTRODUCTION
The introduction of computer techniques into the
hospital environment offers an exceptional opportunity
to reassess traditions and procedures developed over
the years of a non-automated era. 1 However, there is
an apparent danger that computer applications evolving in many hospitals tend to perpetuate the stereotyped roles of departments and personnel confined
within traditional organizational boundaries. Their
primary emphasis on conventional business or other
specialized areas serves to sustain long ,standing and
often outmoded rituals and procedures, imbuing them
with the aura of modern automation. Such stereotype
can be avoided by centering design of the computer
system on the patient and his care as the crucial basic
unit, thereby optimally meeting the needs of both
patient and staff.
This approach provides "something more" than
mere automation; it reduces communication barriers
by integrating and focusing the efforts of the administration and a diverse staff on optimizing the care of
the patient; it encourages a redefinition of traditional
duties and roles to minimize the functioning of human
beings at repetitive, mechanical tasks which can easily
proliferate with an unimaginative installation of data
processing equipment; it encourages a fuller and more
flexibJe version of the ultimate capabilities of computer
technology in providing complete medical care.
This paper reviews and generalizes on the experience gained in the application of the patient centered
concept to the implementation of a computer based
infonnation system in a 400 bed private psychiatric
hospital, using an IBM 1440 computer and 12 Bunker
Ramo cathode ray tube terminals for on-line service
eight hours a day for the past two years.
The proliferation of computers in hospitals has
been extensive. A survey made in the Fall of 19622
showed that only 39 hospitals were using computers.
Four years later, January 1966, the American Hospital
Association reported in their annual survey of "Hospitals Accepted for Registration" that 586 hospitals
either had their own computer or received computer
services through a service bureau. From the Fall of
1965 to May, 1968, ECHO, a national organization
of hospital personnel engaged in the installation of
computer systems, experienced a membership increase
from 74 representatives of 49 instutitions to 457 representing 241 private institutions plus numerous state
and federal hospitals systems.
A review of current periodical literature and ECHO
membership applications describing the status of
hospita1s' automation programs reveal that the majority of operating systems emphasize patient billing,
accounts payable, general ledger, payroll,inventory,
and statistical reporting programs. A smaller number
report the development of computer applications serving the research department or the clinical laboratory.
In the vast majority of hospitals, it appears that
the implementation of computer services is under the
direction of the comptroller, a comparable administrative officer' to whom the data processing personnel
report, a research scientist, or a laboratory technician.
In relatively few instances is the responsibility for
an automation program vested at an administrative
level where the joint requirements of the whole hospital-clinical, research, business affairs-are seen
in their proper perspective and can be effectively incorporated into an overall plan.
Considering those in whom control of computer
programs is commonly vested, this concentration
700---------------------------------
710
Spring Joint Computer Conference, 1969
of attention and resources in the more conventional
and better understood uses of the computer for business
or scientific purposes is understandable. Another factor
which may contribute to perpetuation of this emphasis
on specialized areas .is the lessened likelihood that the
status quo in clinical areas will be disturbed by the
encroachment of computers on traditional doctor/
patient/nurse relationships.
A study made by McKinsey and Company3 on the
profitability of computers employed by large companies
has clear relevance to hospitals attempting to secure
maximum returns on their investment in an automation
project. The study found that In.any large companies
have unprofitable computer installations because "technicians", not "managers", control the ways they are
being used. The report further states that unless companies go beyond the "super clerk" uses of computers
and apply the machines to crucial management and
operations problems, the heavy expense of a computer
installation will probably not be justifiable.
From the findings of the McKinsey study emerge
three fundamental principles pertinent to the problems
and organization of a hospital:
1. The direction taken toward design of a computer project should follow what engineers
recognize as the "Systems Approach".4 Simply
stated, this calls for consideration of total
systems needs before proceeding to the selection
and design of compatible components.
2. Development of a hospital management information system calls for the commitment of the
highest level medical and administrative staff
to the direction and support of the project,
thus securing a perspective which visualizes
the relationship of the many functions, or
sub-systems, of the hospital to each other and
to the total needs of the hospital.
3. InterdisciplinalY specialists should be members of the development team; i.e., physicians
who understand the problems of data processing; researchers who understand the problems of the physician and the programmer;
accountants who see the relationship between
other hospital sub-systems and their own; systems specialists who can relate successfully to
the other members of the group.
The Institute of Living patient centered information
system has departed from the standard pattern seen
in the majority of hospital systems which center around
and cater primarily to a single component of the hospital complex or sets of isolated components. Adherence
to the "Systems Approach" is exemplified in its stated
objectives:
1. To provide a more effective method than otherwise possible through traditional means, to
record, communicate, and display, when required, a comprehensive and dynamic profile
of patient progress. This is accomplished through
provision of simple inquiry procedures with
which the user can extract an almost limitless
variety of information through an on-line terminal.
2. To streamline administrative procedures, thereby freeing professional personnel for more productive purposes in the patient care and hospital
management areas.
3. To increase the efficiency, economy, and safety
of patient logistics; i.e., scheduling of medications, meals, diagnostic procedures, patient
privileges, etc.
4. To provide a better and more sophisticated
means to record, analyze, and present psychophysiological data on all types of patients for
clinical and research purposes.
5. To satisfy the need for financial, personnel,
and other conventional business applications;
i.e., payroll, accounts receivable, personnel
. data, financial reports, accounting, inventory
control, etc.
Progress toward these objectives has been achieved
in the implementation of a hospital dependent, reactive
system which has been in daily operation for two years
serving the clinical, administrative, and research needs.
The system includes the following features:
1, An automated master patient record file of
current and historical information on all inhospital patients (see Figure 1).
2. Twelve key areas of the hospital are equipped
with Cathode Ray Tube terminals with alphanumeric keyboards which hospital staff members
use to update the patient file and request information as needed (see Figure 2).
3. A privacy feature has been incorporated to
insure positive identification of a person attempting to operate a terminal and to prevent
unauthorized personnel from entering or receiving privileged information.
4. The administrator, clinician, or researcher can
request a report on any group of the hospital
population according to desired parameters receiving an immediate reply; for example, sex,
age, diagnosis, religion, origin, and/or length of
stay. An example is shown in Figure 3.
Hospital AutOInation
711
DEMOGRAPHIC INFORMATION: Patient's residence,
marital status, religion, education,
occupation, birthdate, sex, citizenship,
social security number.
ADMISSION DATA: Date, legal basis, type of
admission, time and place of previous
patient stays, referring party, personal
physician (office and residence).
LOGISTICS: Residence, group, observation,
and doctor assignments (current and
history), date and type of privilege,
place, time, and frequency of departures,
visits, and returns.
QUANTITATIVE BEHAVIORAL ANALYSIS: MMPI, MHPA,
scores and rater ID, (current and history),
nursing note scores, special behavior
data.
MEDICAL EVALUATION: Duration of illness,
drug study group code, diagnosis, medication data, mental status.
BILLING: Room and medication rates, charges
and credits, current balance, billing
party for all or specified charges.
FAMILY AND FRIENDS: Responsible party, emergency notification, other relatives
(address, occupation, and telephone
number of above persons) •
PHYSICAL MEDICAL DATA: Neurologic and physical
exam results, blood type, drug sensitivities, other abnormalities.
Figure 1-Master patient record file data
5. Since daily behavioral observations are the basic
laboratory data for psychiatric patients, a patient's behavioral status, over time, can be
graphically displayed as desired using factors
derived from an automated nursing note system,
as shown in Figure 4. These "fever chart" displays have been found especially meaningful and
useful to clinical personne1. 6 Figure 5 is another
example of a similar display comparing two patients on the factors derived from the scores
achieved on the l\1innesota-Hartford Personality Assay.
6. Computer aided instruction is provided through
interactive procedural aids displayed on the
terminal screens. Examples are the availability
of a glossary to define terminology presented in
an on-line mental status description and a selfadministered test in the use of the newly adopted
international list of diagnostic categories.
7. Automation of pharmacy orders provides a
record of patient medications, produces labels
for the pharmacist as a by-product, and notifies
clinicians when it is necessary to renew a drug
order.
Figure 2-0n-line cathode ray terminal
8. Payroll, patient billings, census, and other related applications are also provided.
The programs, written in Autocoder, run on an IBM
1440 computer utilizing 16,000 c~acters of core
storage, three 1311 disk drives, a 1442 card reader/
punch, and a 1443 printer. A Bunker-Ramo 200 Display System provides the on-line capability with Bunker-Ramo 204 Display Stations and a Teletype Corporation Model 35 RO. By the end of the year it ~
anticipated the system will be transferred to a Univac
494 with central processor backup, Fastran drums
and tape storage. The number of terminals will be
expanded to approximately 40 in order to provide complete coverage of all hospital areas.
In retrospect, the following three premises on which
system design philosophy has been based appear as
crucial factors. 6 ,7,8,9
First, the patient, his care and treatment, have
been recognized as the center of the hospital universe.
Every activity is directed toward this end; no machine
or automated procedure is permitted to disturb the
therapeutic relationship between the patient and his
environment.
Spring Joint Computer Conference, 1969
712
INPUT REOUEST (CODED);
MINNESOTA - HARTFORD
OUTPUT
PERSONALITY
ASSAY
MEAII ADMISSIOII I'RO'ILES I AIIO 14 I'OSITlV£ Sl'l1e.1
COWA"IIOII 0' I'OIlTI'IE "lID II!lATI'IE l"OUl'S
04-21-IT
I. DATE RESTRICTIONS MO.l DA. I YR. TO PRESEN'
2. INCLUDE SEX I EQUAL TO I FEMALE
3. INCLUDE MAR!TAL. STATUS! EQUAL. TO! MARRIED
4.INCLUDE RELIGION I EQUAl TOI PROTESTANTS.INCLUDE EDUCATIONI EQUAL TOI ATTENDED POSTHIGH SCHOOL TRAINING
10090-
-
--
40 -
-
-
-
-
2
3
4
5
6
61
16
51
16
64
1111 47
"
77
1111
711
.~~ ~~
DISPLAY;
29049 MRS JONES, NELLIE RCOLE
GRAY, C. - T
9A
35498 MRS SMITH. CLYDE C.
TO. I
GRAY. C.
44000 MRS TAYLOR, GRACE W.
W. H.
SIMPSON, G. 0
3020 I
I AIIO 14
YES
• AIIO 14
7
47
8
9
10 II
12
13
14 15 16
17 18 19 20
45
I.
115
10
58
12
54 61
5'
47 57
114
n
10
.~:
51 ' :
511
45557053
44 . :
n
55
NO
Figure 5-A patient behavior profile produced by scoring
twenty factors of the Minnesota Hartford Personality Assay.
The normal profile is equal to a score of 50 on each factor with a
standard deviation of 10
UNDER
39
49
59
lisT
TOTAL 3
Accordingly, from the point of view of both the
systems engineer and the hospital, a patient centered
information system provides the most logical approach
to a viable system, as illustrated by Figure 6.
Secondly, the Human Factor is a critical element
in the success of the computer project. The degree of
AVERAGE LENGTH OF STAY FOR THE
PATIENTS IN THIS GROUP IS 44 DAYS.
Figure 3-An example of the master patient file "extractor"
capabilities
100
SOCIAL ADAPTATION
Med i co I
Services
3
5
15
7
17
19
21
23
25
DAYS
Figure 4-A longitudinal 25-day display of three nursing note
behavioral factors for a sociopathic patient compared with the
group mean (=50). Compared with the group mean, this
patient "ras more socially adaptive and showed an increase in
anxiety over the 25-day period. The psychiatrist believed that
therapy wouid not be effective until anxiety had been moDilized
Figure 6-A schematic illustration of t.he patient-centeredhospital system concept
Hospital Aut01nation
appropriateness and acceptability of new techniques
is directly proportioned to the understanding and
contributions of the users in their development. to
To this end, all levels of hospital staff, from top
medical and administrative down, who might in any
way come into contact with the system or be affected
by it, have been involved in the design effort. This
involvement has included on a continuing basis the
following, as appropriate to the needs of the individual:
1. Exposure to the potential- usefulness of computers in the care and treatment of patients
through booklets, visual aids, lectures, group
discussions, visits to other hospitals, etc.
2. Solicitation of ideas, even if apparently farfetched, as to how a computer might be used
in the hospital.
3 Assistance and advice in setting objectives
and priorities for their accomplishments.
4. Active participation in the development of
automated procedures by those involved; for
example, pharmacists, nurses, the chairman
of the pharmacy committee, and data processing
personnel were closely involved in design and
implementation of the automated medication
file.
5. Frequent personal consultation by project
staff members with the users of the system
for their guidance and advice especially to ensure
the proper use of the unique terminology employed by clinicians, nurses, and other professionals.
It has been observed that the mere involvement of
key personnel from all departments can of itself improve
hospital efficiency and patient care procedures, automated system or not.
Thirdly, the man/machine interface plays a vital
role in the successful integration of an automated system into the hospital environment.
It is recognized that the users of the system need
to enter, receive, and utilize information comfortably,
effectively, and preferably without an intermediate
filter, such as a clerk, ward secretary, nurse, or other
personnel. For the majority of the' hospital staff their
only contact with the computer will be the means of
communication. Quite literally, to them this is the
computer.
In a more conventional business environment, a process control situation, or a computational research
effort, such emphasis on choice of communications
device may not be warranted. In these areas one can
expect clerks, engineers, or scientists to be familiar
with various types of terminal equipment. Where one
713
must deal with personnel both unfamiliar with and often
resistant to "machines", a psychological, and often
a physical, barrier is interposed to the free flow of
information on which the system depends.
By centering the system on the patient rather than
on the "computer", new and productive patterns of
staff interaction have been encouraged, leading to a
re-analysis of every dimension of hospital operation
that affects patient care. We conclude that the ultimate
potential for applying the patient centered concept
depends not on hardware which is already planned
or available, but, most importantly, on capable medical,
paramedical, research, and data processing personnel
who can use the computer as a means and not an end
for crossing traditional interdisciplinary barriers in
the care of patients.
This does not mean the potential of the computer
to monitor, condense, and analyze information is being
relegated to a secondary level of consideration. With
the acquisition of adequate third generation hardware
we plan to use the data base now being accumulated
for continuous monitoring by the computer for essential
missing data, "essential" being determined by continuous comparison of already received data with
paradigms of illness or treatment p.rediction patterns.
We assume the essential information will vary considerably from one clinical problem to another, and
hope to exploit the resources of advanced computer
technology to make the models as varied and numerous
as necessary.
We would judge that the ultimate success of an information system can be evaluated by the degree of
increased communication and interaction it encourages
amongst these various specialists; this criterion implies
that all relevant judgments would be used in the care
of the patient. Early evaluation of such a system at
the Institute of Living demonstrated a significant
increase in such communication. ll This approach has
used the computer as something more than an instrument for automation.
ACKNOWLEDGMENTS
The computer project at the Institute of Living has
been supported in part by NIMH Grant MH-08870,
Bernard C. Glueck, Jr., M.D., Principal Investigator
and Director of Research. This research was also supported by ~I~1H Grant l\1H-08557 and by the Gengras
Foundation.
The authors acknowledge the assistance of Mr. R.
Peter Ericson, Miss Dorthie McIntyre, and Mrs.
Dorothy E. Reiss.
714
Spring Joint Computer Conference, 1969
REFEREKCES
C F STROEBEL W L BENNETT R P ERICSON
B C GLUECK JR
Designing psychiatric computer inf{)nnat'l~()n. syste.m,s:
problems and strategy
Comp Psychiat Vol 8 No 6 1967
2 R H GIESLER
How many hospitals
equipment
u,.'~e
automatic data processinr,
Hospitals JAHA Vol 38 January 1964
3 Me KINSEY AND COMPANY, INC
Unlocking thR computer's profit potf'niial
4 W L
BE~NETT
The systerm approach to hospital automation
Hospital Financial Management J HFMA January 1969
5 M ROSENBERG B C GLUECK JR
W L BENNETT
A. utomation OJ behavioral observations on hospitalized
psychiatric patients
Amer J Psychiat 123 1967926-929
6 B C GLUECK JR C F STROEBEL
The computer and the clinical desicion process: II
Supplement to the American Journal of Psychiatry
Vol 125 No 7 January 1969
7 W L BENNETT
How to live with a computer and tik.e. it
Medical Record News J iLt\MRL Vol 39
No.3 1968 42-44
8 W L BENNETT J A HOUCK
A three step plan Jor automation
Hospitals JAHA Vol 41 196761-66
9 W L BENNETT
.4 viable computer-based hospital information system
Hospital Management Vol 103 196743--47
10 M ROSENBERG R P ERICSON
The clinician and the computer-affair, marriage, or
divorce'!
Supplement to the American Journal of Psychiatry
Vol 125 No 7 January 1969
] 1 M REZNIKOFF D HOLLAND C F STROEBEL
Attitudes toward computers among employees of a psychiatric
hospital
Mental Hygiene Vol 51 1967419--425
A position paper--Computers in medicine:
Automation vs. improvement of status quo
by ALVAN R. FEINSTEIN
y ale University School of Medicine
~ ew
Haven, Connecticut
Computers have thus far been applied in medicine
most effectively in situations where a standard mechanism already exists for dealing with the data: in the
accounting problems of administrative work; in sorting
and printing out the resl}lts of laboratory tests; and in
conventional types of mathematical calculation performed during research or other activities. Despite these
obvious and desirable successes, computers have not yet
had an important impact on the more inherently clinical
features of medical strategy and tactics. The intellectual
qualities of scientific practice in clinical medicine do not
appear to have been significantly affected by the many
theoretical models and grandiose systems proposed
during the recent exuberance of "computers m
medicine."
Perhaps the greatest barrier to true progress in
applying computers to clinical problems is the premise
that satisfactory scientific approaches now exist for
acquiring medical data and for interpreting the data
during diagnostic and therapeutic decisions. Since this
premise is not valid, enonnous amounts of time, effort
and money may be expended in constructing computerized systems and models that will be obsolete or
inadequate for the real needs of clinical medicine.
Computational approaches to diagnosis might have
been useful 40 years ago, but are often obviated today
by the modern precision of individual pathognomonic
paraclinical tests. With the aid of radiography, biopsy,
cytology, endoscopy, and diverse laboratory procedures,
many diseases can be accurately identified today
without the use of complex inferential logic or statistical
computations of probability. The major intellectual
need in diagnosis today is for a better way of choosing
the tests rather than calculating the names of diseases.
Such improved strategies cannot be devised and
checked, however, until appropriate clinical algorithms
are constructed to demonstrate the flow of logic in the
diagnostic "work-up," and until appropriate medical
data are assembled to show the values and risks of
paraclinical tests at each step in the logical sequence.
The construction of such algorithms and the assemblage
of such data require attention not to computers and
statistics, but to the basic ingredients of clinical
reasoning and activities.
Current systems for acquiring and storing the data
of patients' histories are ingenious but inadequate
because the types of data, the necessary descriptive
constituents, and their subsequent tactics of application
are not clearly recognized or defined. J\fany critical
types of information-such as iatrotropic stimuli, subtle
nuances in symptom descriptions, sequential patterns
of symptoms, and the effects of co-morbid ailments, as
well as the entire class of communications that are
transmitted non-verb ally-are omitted from information now being stored in automated systems, and
inadequate attention has been given to the different
rational procedures that must be used when the same
data are analyzed for different clinical purposes.
The automated interpretation of electrocardiograms
and of other paraclinical tests cannot be effective until
specific, rigorous criteria are established and standardized for the diagnostic interpretations. Such criteria
have not been developed for most of the "diseases" of
modern medicine. ~{ost of the existing diagnostic
criteria for disease are derived from observations made
at necropsy, but the histopathologic concepts have not
been subjected to careful studies of observer variability,
and precise criteria have not been formulated and
accepted for integrating the combination of clinical,
technologic, and morphologic data that must be used
for diagnoses made in living patients.
Concepts of "normality" are currently in a state of
confusion because the "normality" defined by a
statistical Gaussian curve is quite different concept
------------------------------------------- 715 -------------------------------------------
716
Spring Joint Computer Conference, 1969
from the "normality" defined by a state of health or
disease. Moreover, regardless of which definition is used
for "normality," a satisfactory range of epidemiologic
populations has not been assembled and followed as a
source of reliable data for analysis.
"Support systems" for clinical decisions will be
intellectually chaotic until they recognize and separate
the different types of data and reasoning used for
diagnosis, prognosis, and therapy. Each type of reasoning requires different data, different logic, and different
criteria. Because the taxonomic categories for data are
currently undefined or incomplete; because standardized
interpretive criteria do not exist; .and because the
available data are not satisfactory either in epidemiologic range or in temporal extensiveness-the current
attention to s-ystem rather than to data, clinical logic,
and criteria seems directed at peripheral rather than
basic issues.
By providing a magnificent means of storing,
retrieving, and counting complex data, computers offer
clinicians an opportunity for major improvements in the
scientific practice of medicine. The opportunity will be
lost if the computer is used merely to automate a
defective status quo. A more exciting challenge of the
computer is the incentive it offers clinicians to explore
the basic data and complex reasoning of clinical
medicine, so that intellectual clarity and precision can
, be established for constructing suitable clinical
algorithms, for developing appropriate criteria fOf
decisions, and for performing new research projects that
will yield respectable data with which to enlighten the
future rather than embellish the past.
An analytic model of multiprogrammed
computing
by ROBERT R. FENICHEL
Massachusetts Institute of Technology
Cambridge, Massachusetts
and
ADRIAN J. GROSSlVIAN
Borden, Inc.
New York, New York
INTRODUCTION
The work described in this paper was undertaken in
order to provide estimates of the throughput capacity
of certain multiprogrammed computer systems. In
particular, we consider those systems whose users are
never simultaneously receiving input-output and central processor attention. Systems making" use of "demand paging" tend to fall within this class.
Our definition of "throughput" should be made more
explicit in this introduction. We initially considered a
model in which the measure of system performance
was response time. But this model required us to phrase
each result in terms of user reaction time; the same
system can give snappy service to lethargic users and
inferior service to a more energetic clientele.
The current model looks to system perfomance in
tenns of completed interactions per unit time. * This mea• This measure is identical to that used by Gaver (Journal of
the Association for Computing Machinery, Vol. 14, No.3, July
1967, pp. 423-438), and it is useful to compare our work to h~s.
Gaver's work is characterized by sophisticated statistical analysIs,
and Gaver's analytic assumptions were made in order to facilitate
his manipulations. For example, Gaver assumes that the service
times of input-output peripherals approximate an exponential
distribution (page 428). While this approximation can be made
to fit real system behavior quite closely, the effect of the assumption upon the whole analysis is not clear. Insofar as real
equipment behaves less smoothly than the distribution suggests,
is the system degraded or improved?
Many of Gaver's idealized systems differ in what prove. to
be only minor ways. For example, he compares systems w~ch
differ only in the variances of the distributions of their respectIve
parameters. It is greatly to Gaver's credit that these com-
------------------------------717
sure has the merit that it is indifferent to the energy and
even to the total number of competing users of the system. Our only assumption in using this measure is that
the number of users is sufficient to maintain a non-zero
load on the system at all times.
We wish to understand the effects of each of our
analytic assumptions. In particular, we make the following claim: Each of our assumptions is optimistic. To
the extent ~that our model over-simplifies, it over-estimates expected system performance.
For example, we assume of many parameters that
they are taken from distributions of zero variance. This
is always an optimistic assumption. In every case, these
parameters may be regarded as demands upon system
components. The variances which we bar could only
lead to the idleness of a component; utilization, like
time, cannot be recaptured.
System: CPU, care, drum
We shall first consider a system whose resources are
a single central processing unit (CPU), some fixed
quantity of executable memory (core), and a drum. .
Our first assumption is that there is a fixed, determlIlable number k which is the number of user programs
simultaneously in core. ** In any paged environment, of
parisons were published, but we perceive the~ as stric~ly ~ega~ive
results. That is, Gaver has shown that dIfferent dlstnbutlons
really are not ever very different.
.. To take account of shared code, we prorate its ownership
among its users in the obvious way.
718
Spring Joint Computer Conference, 1969
course, programs may be only partially in core. We
count a given program among the k if, and only if, it is
either (1) now using the CPU, (2) waiting for the CPU
and sufficiently loaded so that the system would transfer the CPU to it were the CPU free or (3) not using or
waiting for the CPU (that is, using or waiting for some
other component of the system) and as fully loaded into
core as the least-loaded program in condition (1) or (2).
Certainly, k is bounded by the physical size of core;
each core-resident user needs at least the space which
will be necessary for storage of his current machine
conditions. But in order to decrease the frequency of
page requests, the system's supervisor will probably
limit k so as to increase the quantity of core provided
to each core-resident user. If the supervisor wisely attempts to allot core space for the working-set! of each
user, k may have to be quite small indeed. 2
During the time that a user's program is in core, its
state will cycle between
j
a, waiting for or receiving CPU service, and
{j, waiting for or receiving a single page from the
This flow out of core is exactly the rate at ·which the
system produces evidence of useful work.
In order to compute these flow-rates, we shall need
to compute the occupancy levels a and b, where a is the
number of user programs in state a ilnd b = k - a is
the number of user programs in state {3.
It is convenient to discuss the system in terms of the
follmving figure:
F1
THROUGHPUT:
No.2
m:--.a~~
I
a , Waiting for
~r
"~Fl~,,\2
A~
rece1v1ng
Flow No. 1
,...------...".
1
- It---
c pu
_ se_rvice----.'
!
I !
8 : Nai ting for
Flow No. 4
or receiving
drum.
1 page
We specifically ignore, in this analysis, all core requirements of other peripheral devices which may be
present. For example, we assume that if one of the users
comes to wait for typewriter action, he effectively disappears from the system. In particular, such a user is
not tying up any of the k blocks of valuable core.
We assume that during each interaction, each user
will require exactly C seconds of CPU attention. Similarly, we assume that each user will require that D
pages be fetched from the drum on his behalf during
every interaction. "ltVe specifically ignore the problem of
writing pages back onto the drum. t We assume, moreover, that in a single-interaction cycle of
Figure l·-Flo\VF:: CPU/drum ~yHtem
In terms of this diagram, we have already stated that
1. Flow No.2 =
Flow No. 1
D
+1
D X Flow No. 1
2. Flow No. 3 = - - - - - D +!
3. a = k-b
the C seconds of CPU attention are divided among the
intervals of state a into D + 1 equal pieces.
Our fundamental concern is with the rate at \vhich
user programs leave state a; that is, the rate at which
users cease to require CPU service.
We know, after all, that only D / D + 1 of this flow
is toward state {3. The remainder of the flow from a
consists of users v:ho have completed their use of core.
t
This as~umption is not neeessarily very generous. Espe('iaily
in systems utilizing much pure-procedure pl'Ogramming, the
read/write ratio may he very high. Also, reading is inherently
more difficult than writing, since an item to he read must he
read from where it is written, whereas an item to he written ean
well be placed \vhel'e (:onvenient. 3
Moreover, over any long run it must be true that the
number of user programs which have arrived at state (:3
is exactly equal to the number of user programs which
have left that state. The most optimistic possible assumption (by the old congestion/idleness argument)
is that the rates of flow Nos. :i and 4 are constant
over time. But then,
4. Flow No.3 = Flow No.4
N ow to solve for the unknowns of the diagram (that is,
for a, b and the four rates of flow) it will be necessary to
determine the functions! and g such that
5. Flow No.1 = f (a)
A!1..alytic Model of Multiprogrammed Computing
6. Flow No.4 = g (b)
+
The system.could even be more complicated, and the
same technique would work. For example, a new f
function could easily take account of any number, n ,
of anonymous processors. We could even add other
peripheral devices; the CPU-drum system might stand
to a disk, say, as the CPU alone stands to the drum.
Such a system would look like:
But what if a is non-integral? For example, suppose
that only one user program can fit into cor~. If D i~ not
zero, then the average number of programs seeking CPU
attention must surely be properly between one and
zero. The most optimistic interpretation we can make
is that f (a), for a non-integral, may be computed by
linear interpolation from the values of f at the surrounding integral values of a.
Thus, in summary, we have as the CPU output rate'
=0
7b. f (a)
= (D +
f
=aX
7c.
(a)
1) /e
(D
+ 1) /e
[if a
= 0]
[if a
~
[if 0
n) are just waiting, and their presence does not
improve the effectiveness of the CPUs. If this excess
core is removed, the model shows no change in throughput. That is,
Core utiliza.tion
=
min (1, n
!
+ + c)
Utility of the model
We believe that this model has three distinct sources
of utility.
1. Our assumptions of zero-variance behavior may
be reasonable for some special-purpose systems
(e.g., reservation systems). The model should
accurately predict the behavior of such systems.
2. However close the model's assumptions are to
the realities of other systems, these other systems
can surely do no better than the model expects
them to. The model provides upper-hound values
for the performance of these systems.
3. The model suggests at least qualitative explanations for many complex system phenomena.
For example, the model allows a simple explanation of how increasing paging demands might
be met by increasing CPU performance.
ACKNOWLEDGMENTS
The work described in this paper was initiated while
the authors were consultants to the MEDINET Department of the General Electric Company. Several
discussions with MEDINET employees, particularly
T. N. Hastings, were seminal to the work. P. J. Denning
of M.I. T. reviewed an early draft of the paper and made
many helpful suggestions.
The work was supported by Project MAC, a Massachusetts Institute of Teclmology Research Program
sponsored by the Advanced Research Projects Agency,
Department of Defense, under Office of 1'\aval Research
Contract No. N01'\R-4102 (01).
REFERENCES
1 P J DENNING
The working set model jor program behavior
Communieations of the Association for Computing
Machinery Vol 11 ~o 15 May 196X :~2:3-:{:{:{
2 L C VARIAN E G COFFMAN
Further experi'mental data on behavior ()f proyramB in a
paging ent'ironlllenl
Communications of the Association for Computing
Machinery Vol 11 No 7 July IH68 471-474
:3 P J DENNING
Effecis of scheduling on file memory operations
Proc S J C C 1967
APPENDIX A
Sample ALGOL routines for computing a and b given k
real procedure f(a) ;
real a; value a;
begin if a = 0
thenf: = 0
else if a ~
then f: = (D + l)/C
else f: = a X (D + l)/C;
end;
real procedure g(b) ;
real b; value b;
begin own real array ig [O:k] ;
comment The array ig is magically filled by simulation.
The entry ig [n] is the proper value of g(b) for
b = the integer n;
real eb;
eb: = entier (b);
ifb = eb
then g: = ig [b]
else g: = ig [eb] + (b-eb) X (ig [eb + 1] - ig [ebl)
end;
procedure Distribute k (k, D, C, a, b, tolerance);
comment Half-interval attack upon k = a + b;
real k, D, C, a, b, tolerance;
value k, D, C, tolerance;
begin real frac, CPU output, drum input, drum output;
a: = k;
frac: = k/2;
aset: b: = k - a;
CPU output: = f(a);
drum input: = D X CPU output/CD + 1);
drum output: = g(b);
if drum input> (1 + tolerance) X drum output
then a: = a - frae
Analytic Model of Multiprogrammed Computing
else if drum input < (1 - tolerance) X drum output
then a: = a + frac
else go to done;
frac: = frac/2;
go to aset;
done: end Distribute k;
Sample ALGOL routines for computing a, band c given m
procedure Distribute m' (m, C, D, Ds, tolerance, n, a,
b, c, CPU output, drum output, disk output,
throughput) ;
real m, C, D, Ds, tolerance, n, a, b, c, CPU output,
drum output, disk output, throughput;
value m, C, D, Ds, tolerance, n;
begin real k, frac, disk input;
procedure Distribute k;
begin real frac, drum input;
real procedure f;
begin if a ;::: n
thenf: = n X (D + Ds + l)/C
elsef: = a X (D + Ds + l)/C
endf;
b: = k;
frac: = kj2;
seta: a: = k - b;
721
CPU output: = f;
drum input: = (D/(D + Ds + 1)) X CPU output;
drum output: = g(b);
if drum output> (1 + tolerance) X drum input
then b: = b - frac
else if drum output < (1 - tolerance) X drum
input
then b: = b + frac
else go to donek;
frac: = frac/2;
go to seta;
donek:end;
c: = m;
frac: = m/2;
setk:k: = m - e;
Distribute k;
disk input: = (Ds/ (D + Ds + 1)) X CPU output;
disk output: = h(c);
if disk Otltput > (1 + tolerance) X disk input
then c: = c - frac
else if disk output < (1 - tolerance) X disk input
then c: = c + frae
else go to donem;
frac: = frac/2;
go to setk;
donem: throughput: = CPU output/CD + Ds + I):
end
Measurement based automatic analy·~is
of FORTRAN programs *
E. C. RUSSELL and G. ESTRIN
University of California
Los Angeles, California
INTRODUCTION
A graph model of computer programs has b~en developed in a series of studiesI - o directed toward improving analysis of the structure of programs executed
on different computer configurations. One inherent weakness of the model has been the need for estimates of the
mean number of times a program would cycle around
its loop structures and estimates of branching probabilities. Extensive improvements were made in the
model on the assumption that good estimates would be
inserted during a manual transformation of a given
program into a computer processable graph representation. The combination of improved tools for measurement of program activities and recently developed
analysis programs now permit automatic analysis of
source programs. The automatic analysis is based on
more reliable measured a priori statistics. This paper
discusses a valuable by-product of this measurement
and analysis which directs attention toward those parts
of a program which are leading candidates for application of optimization techniques. In particular we present an example of the automatic analysis of programs
written in the F0RTRAN IV language. F0RTRAN
was selected as a first target for analysis because there
exists a large number of time-consuming programs
written entirely in F0RTRAX.
The first part. of the paper presents a simple summary
of the graph model of programs. The second part deals
with a particularization of this model to F0R TRAN
programs. The last part presents the results of an experiment which illustrates the use of the graph model
based on measurements. Automatic analysis pro-
* This research was sponsored by the Atomic Energy Commission [AT(I1-1) Gen 10 Project 14l, the Advanced Research
Projects Agency ARPA SD 184, and the Office of Naval Research,
Information Systems Division. Reproduction in whole or part
is permitted for any purpose of the United States Government.
cedures obtain an ordering of F0RTRAX statements
according to their frequency and time-of-execution
along with other structural data.
The computational model
A principal goal of the several investigatorsI - o
who have developed a graph model for representing
computer programs has been to study the structure
of the program for analysis of its space and time
requirements on a variety of hardware configurations.
This model is illustrated in Figure 1.
The salient properties of the model are:
1. There is one original vertex (VI)
2. There is one terminal vertex (vs)
(When either of these conditions does not exist.
a pseudo-vertex is appended. Thus multiple terminal
vertices are connected to a pseudo terminal vertex
and multiple origin vertices are preceded by a pseudoorigin vertex.)
3. Each vertex is connected to other vertices
by directed arcs. There may be more than one arc
directed either to or from a vertex, in whieh
case the interaction of the arCR is specified
by a logic condition. Arcs may enter a vertex or
leave a vertex in a simultaneous ("AND")
fashion or in an exclusive ("OR") fashion. The
"AND" condition indicates situations in whieh
multiple-processors may be used to advantage.
4. Cycles are represented by arcs which are directed
from Vj to Vi where j ~ i. This impJies that care
is taken in the choice of numbers for vertices.
Thus far only structural properties of the program
are described. The remainder of the description is
concerned with the definition of the operation to be
performed at each vertex. Such a description includes:
723 ------------------------------------
724
Spring Joint Computer Conference, 1969
Additional generalizations are also possible. In the
experiments performed, FORTRAN statements are
taken as the primitive computations represented as
vertices. It may not always be desirable to make such
a choice. In highly parallel computations, a refinement
or "blowup" of a particular vertex may reveal parallel
processing potential within complex statements. Conversely, large portions of the program may represent
such a minor portion of the computatioh time, that it
may be helpful to collapse portions of t~e graph into
single vertices. Such transformations are pdssible, given
that all the above descriptive parameters are available.
For the present an entire F0RTRAN program is
. analyzed and represented as a single graph. If subprograms are referenced, they must be described
parametrically prior to their inclusion. The parametric
description of a subprogram can be developed independently and a library of subprograms prepared.
Particularization to FORTRAN programs
Nomenclature
Vertex definition
The application of the model to FORTRAN will
be made at the statement level. That is, each executable
Figure I-Graph model of a computation
5. The block of instructions required to perfonn the
computation.
6. The identification of required input data.
7. The identification of required output data.
8. The amount of intennediate (temporary) storage
required.
One of the goals of this modelling process is· the a
priori analysis of the execution of a program on a particular hardware configuration. In order to complete
the program description for this purpose, the following
additional parameters are required:
9. For each "exclusive or" output, a probability
for each arc.
10. The iteration factor for each cycle (These two
parameters may be derived from a single
"frequency count" for each vertex.)
This model has the advantage over some others
(Rodriguez8), that only a single type of vertex exists.
Variations such as input connections, output connections, actual computations, etc., are described
parametrically. This le.ads quite naturally to the
description of the graph in terms of Boolean matrices.
FORTRAN statement will be assigned to a unique
vertex. Other choices could be made: for example, if
more than one vertex per statement were permitted
then each arithmetic operator could be assigned to a
unique vertex and analysis of parallel arithmetic expressions could be performed. This would result in
graphs with large numbers of vertices. On the other
hand, a single vertex could be made to represent several
statements or even an entire subprogram. This would
provide for smaller graphs but could obscure potenti~ 1
parallelism. With an initial analysis at the statement
level, a refined analysis could then be performed on
those portions of the program which consume significant
portions of execution time, whereas less significant
portions can be collapsed into fewer vertices.
Each program will contain one origin vertex (WI)
which is predecessor to all other vertices in the graph.
(A program with multiple entries will still have one
pseudo-origin with immediate outbranchings to the
various entry points.)
Each program will contain one terminal vertex (wn )
which is successor to all other vertices in the graph.
(lVlultiple exits from the program will be tied to this
one terminus.)
For each vertex, the input data set, I i, consists of the
names of those variables which are referenced by the
statement represented by the vertex. For example, for
an arithmetic assignment statement this includes all
variables in the expression and any subscripts.
Measurement Based Automatic Analysis of FORTRAN Programs
For each vertex, the output data set, 0 i, consists of
the names of those variables which are modified by the
execution of the statement represented by the vertex.
Arc definitions
Three categories of connections between vertices
will be established; sequential connections, logical
connections and loops.
Each executable F0RTRAN statement which does
not explicitly specify the successor statement implicitly
"falls through" to the next executable statement in
the program. These connections (of the form (w i, w i+1) )
are designated sequential connections. There can be
only one sequential successor vertex for each vertex.
Each executable F0RTRAN statement which does
specify explicitly one or more successor statements
produces connections which are designated logical
connections. The connections are of the form (w i, wi)
where i ~ j.
Some of the arcs of a program represent the return
path of a programmed loop. Of course, any one arc
in a cycle can be selected as the return path but often
one' is recognizable from the syntax of the language
(e.g., the F0RTRAN "DO" statement). Each arc
which closes a programmed loop is designated as a
feedback connection.
Gra.ph representation of FORTRAN IV
A complete specification for the graph representation
of FORTRAN statements is given in the Appendix.
Experimental measurements
Two attributes of the vertices of a graph are determined from experimental measurement. These are:
(1) vertex activity number and (2) vertex single-execution time.
Vertex activity in a sequential program
Vertex activity can be determined by making some
minor modifications to the source program before execution. These modifications are similar to those outlined in "SNUPER CO::\1PUTER, A Computer Instrumentation Automaton," Estrin.9 For these experiments, however, only vertex activity and loop activity
are desired and not all arc activity as in the reference.
Because of this, the artifact introduced is considerably
reduced. The required measurements are as follows:
1. the number of times the program is entered.
2. the number of times each labeled statement is
executed with special treatment of DO loops
and unusual branches.
725
3. the number of times the auxiliary statement of
a "logical if" is executed.
From these measurements, the entire set of vertex
activities and loop factors may be calculated.
Introduction of artifact
The artifact introduced into FORTRAX program~
consists of a series of subroutine calls. RoutillO E~"IIT
(i) is introduced to perfonn the activity of counting
the number of times vertex i is executed. For efficient
execution, the subroutine E':\HT is written so as to
perfonn the emit table address calculation and then
modify the calling instructions to perfonn the counter
incrementing with "inline" code after the first encounter
of that call.
The monitoring of vertex activity must be introduced
at the following points in a FORTRAN program:
1. iHeasurement of origin vertex:
Following the SUBROUTINE or FU~C
TION statement or preceding the first executable statement of main program, insert
CALL E':\1IT (i). In order to properly monitor
entries into a program via the ENTRY statement, the CALL E':\lIT which follows an
ENTRY must not be executed if control
"falls through" from above the ENTRY
statement. For example:
A=B
ENTRY FIRST
CALL EIVIIT (i)
C=D
would record an erroneous measure of entry to the
program at FIRST. In such a case the following is a
correct modification of the program:
A=B
GO TO XX
ENTRY FIRST
CALL El\lIT (i)
XX CONTINUE
C=D
2. Measurement of labelled statement:
Replace labelled (executable) statement L : s
by L : CALL E:NlIT (n) where L is the state-
...
726
Spring Joint Computer Conference, 1969
ment label (external formula number), s is
the statement and n is the vertex nunlber
assigned to s.
3. :;Vleasurement of DO loops:
Insert a CALL EMIT (n + 1) after the DO
statement where n is the vertex number
assigned to the DO statement.
4. Measurement of unusual branches:
In the case where CALL or READ statements
provide unusual returns, the activity of the
succeeding statement must be monitored.
For example:
Two problems in implementation now occur.
If this logical IF is the terminal statement of a DO loop, the program meaning has been
altered. Also, the statement label XXX
may already have been used. If the logical
IF is the terminal statement of a DO loop,
the DO reference should be changed to XXX.
(This might be most easily implemented by
adding a unique terminal for each DO of
the fonu XXX COKTINUE.) The uniqueness
of statement labels can be guaranteed by
keeping track of all statement label references
or generations during the source program scan.
CALL SUBl (A,B,$2)
A=D
2B = C
The activity of the statement A = D is not
known unless specifically monitored.
5. Measurement of logical IF statements:
In order to monitor the conditional statement,
it is necessary to introduce "CALL EMIT"
but the restriction is a single statement as
the conditionally executed branch. Therefore
the. following scheme is proposed (as in Estrin9).
a. Negate the logical condition
b. Replace the conditional statement by
a 'GO TO' statement branching around
the original conditional statement and
an inserted 'CALL EMIT.' For example:
IF (t) s
becomes
IF .KOT. (t) GO TO XXX
CALL EMIT (i + 1)
s
xxx
COXTINrE
c. On the other hand, if s cannot pass control
to the next executable statement, the
control is simpler:
IF (t) s
becomes
IF (t) s
CALL El\1IT (i + 2)
where Wi is the vertex assigned to the
IF statement.
Subprogranl inclusion
There are at least two methods of including subprograms in the analysis. The first is to do an independent analysis of the subprograms and provide
only the aggregate attributes of the subprogram for
inclusion in the programs which call it.
The second method is to combine the subprogram
with its dynanlic ascendants replacing CALL statement
by GO TO XX statements where XX is the first executable statement of the subroutine (now a part of
the same graph). The RETURX from a subroutine
is replaced by a GO TO (nl,Il2,na ... ) ILX where Ill,
n2 ... are the statements after each CALL to the subroutine and IXX is an index specifying which particular
call is being executed. In the process of including a
subprogram in the graph, all of the COM]\10N statements can be systematically eliminated. This involves
transforming variables used in the subprogram to
their calling program equivalent names and generating
unique names for local subprogram variables.
Discussion of experiment
A process flow chart describing the experimental
procedure is illustrated in Figure 2. The program to
be analyzed goes through a process which produces
two types of outputs. The first type of output (on the
left) is the actual graph model of the program in machine-processable form. The second type is the modified
source FORTRAN program ready for compilation
and for execution during which raw frequency data
is to be gathered. The post-execution program analyzer
accepts the two sets of output data and produces the
listed vertex and program attributes.
Figure 3 gives a listing of our example program
which was written to simulate the UCLA Boolean
Analyzer. lO It has 127 vertices as defined in Part 2 of
this paper. These 127 vertices are numbered on the
right of the listing. Figure 4 shows the computer gen-
Measurement Based Automatic Analysis of FORTRAN Programs
e
727
"'I[.
, · · · . · • .,s IS A reATIIA'Ii !Y PRS;j,A,,1oI St""UL,AT! ...G T,.[ oJc.L. ... B~ltI.£" ....... AI.
~ ••••• ,.lIe~QA"''''EIJ: ""IGU[l, A. . . "Alh~ ')£" ... 11,.. 1tJ' [trtGl"i[£AI'rIIG, J.~.L.."'.
l"'IrEG£AL,ltUI!>OO,2i?I,TCI22I,I..ITI221
A... OflOOOOI"HTll21.T( .. P ......
I""T(~[A
c!t..~!tP, 0, = and outbranching arc (w i,W HI)'
PAUSE
The PAUSE statement is represented by a
vertex Wi with Ii = cf> 0, = and outbranching arc (Wi,Wi+I).
RETURN
The RETURN statement produces an arc
of the form (w i-I,WJ. This statement does
not result in a new vertex. (w z is the pseudoterminus of the program.)
STOP
The STOP statement is repreRented just the
same as a ret.urn.
CALL name (al,a2, ... an)
The CALL statement is represented by a
vertex Wi. In the usual case t.here is a single
l
3.
4.
5.
6.
7.
8.
outbranching (w ijW ~+l)' However, it is pos,"iible to specify other return paths as parameters
to the subroutine in the form CALL name
(al,... & anI'"
& a n 2) in which &a~l
and &ar.2 represent statement numbers ill
the calling program. In this case, multiple
outbranching arcs are generated Cw i,W i+1),
(w i,Wnl), Wi,W~), ... with output logic exclusive
ot. In the absence of further information, a.ll
parameters are assumed to be members of
both Ii and Oi. Also any CO~L\rON variables
must be considered part of hoth sets. Thus
Input/output statements
There are five I/O statements which will be incll1de(l
in this discussion: READ, WRITE, E~D FILE, REWIND and BACKSPACE.
1. READ Ca, b, END = nl, ERR = 112) list
This statement is represented by a vertex Wi
with input data set Ii = {a,ml,m2.' . 1 where
{1l11,tn2 ... } represent allY loop limits ill thp.
list. 0 i = {list}. The exclusive-outbranching arcs are (w "w i+l) and optional arc~
(W"Wnl) and (w i,W~). Other variations 011
the READ statement are processed Rimilarly.
2. WRITE (a,b) list
This statement is represented by a vertex
Wi with input data Ret Ii = {a, ml, m2, ... ,
list} where {ml,m2, ... } represent any loop
limits in list and list represents the variableR
to be output. 0, = 0 and there is a single ou1branchin~ (W"Wi+l).
3. ENDFILE a
REWIND a
BACKSPACE a
The structure of these three statements is tlH~
same, Each is represented by a vertex Wi with
Ii = fa}, Oi = and a single outbranching
arc (W,:,WHl).
Arithmetic statements
The arithmetic statement, most generally of the
form "a = e" is represented by a single vertex, Wi,
with 0, = {a} and Ii = {kl' ... ,kn b 1, . . . ,b n} where
the k's are subscripts used anywhere in the statement
and the b's are variables in the arithmetic expression
"e". A sinJ2:le outbranchin~ arc (Wi,WHl) is produced.
Software measurelnents and their influence
upon machine language design *
by L. PRESSER and M. A. lVIELKANOFF
University of California
Los Angeles, California
INTRODUCTION
At present, software development is responsible for a
large part of the total cost of computer systems. A .segment of this cost is traceable to the development of
programming language (e.g., FORTRAN, ALGOL,
PL/I) translators which constitute major components
of any software package.
Albeit machine languages have evolved through the
various computer generations, the machine language of
present day conventional computers is still too elementary (e.g., string manipulation operations require considerable set-up time) for a simple and concise implementation of translators and for carrying out the actual
translation process in a manner which makes effective
use of the available hardware.
In order for future information processing systems to
make effective use of the available technology, an
appropriate evaluation! .of the complete operation of
present information processing systems is needed. In
particular, we are interested here in obtaining information concerning the manner in which the translation of
programming languages may influence the machine
language design of future computers, the objectives
being the production of a wefl-balanced integrated
design and the simplification of the translator writing
task.
In this paper we shall discuss a specific programming
language translator and a measurement control center,
and associated software artifact, incorporated into the
translator at implementation time in order to gather,
optionally, information about the translation process.
• The work was supported by Atomic Energy Commission
AT(lI-I) Oen 10 Pro,j. 14; Advanced Research Projects Agency,
SD 184; Information Systems Division Office of Naval Research.
Reproduction in whole or in 'part is permitted for any purpose
of the United States Government.
-------------------------------------733
Utilizing a number of benchmark programs measurements are collected to determine the relative effort
spent in the various sections of the translation process
by this particular translator. The type of information
so obtained contributes to a better understanding of
how the translation of programming languages may
influence machine language design.
Translation technique
The system described here is essentially the META5
translator writing system. 2 This system has been extended and implemented at UCLA on both the IBM
SYSTEl\'1/360 and the SDS SIGMA 7 computers.
Henceforth, for purposes of this paper, we may view
this translator writing syst43m as a translator for the
lVIETA5language.
The META5 system employs a two-pass technique.
The first pass transforms, interpretively, a META5
program into a pseudo-code or intermediate language
(i.e., between machine and programming language)
representation. The second pass interpretively executes
the pseudo-code on the associated pseudo-machine.
Essentially, given a language, we refer to a computer
and associated routines which behave as a pseudomachine for which the given language is the machine
language as an interpreter of that language.
Through a bootstrapping approach a pseudo-code
version of the program which transforms META5 programs into pseudo-code programs was obtained. *
Execution of this program, on the pseudo-machine, is
what constitutes the first pass of the overall process.
* First, Oppenheim'st implementation was bootstrapped to the
IBM SYSTEM/3W; obtaining a META5 to PL/I translator
in PL/I. The next bootstrapping produced a META5 to pseudocode translator, in pseudo-code, on the SYSTEM/360.4
734
Spring Joint Computer Conference, 1969
Measurements
The primary type of measurementsfi ,6 in which we are
interested are:
1. Event statistics (in particular as required to
determine' that part of the total translation
effort contributed by the various sections of a
translator) :
a. Time
b. Frequency
2. Employment of resources (storage space in particular)
3. Interaction with the Operating System
4. Structure of translated programs
The measurement process can be carried out to varying degrees. 6 Hence, the control information supplied
by the Operating System to the translator may contain
an indication of the amount of effort to be dedicated to
the collection of measurement data.
At the completion of the translation process (in the
case of META5 at the completion of each pass), the
collected measurement information is processed, formatted, and recorded on the appropriate data set
(organized collection of related information) which is
then made available to the Operating System. This is
done in the same manner as for the other various forms
of output.
When a translator is being specified it is possible to
indicate the type of measurements desired and the
maximum cost one is willing to pay for the obtainment
of the measurements. This cost may be stipulated as a
percentage of the time employed by the measurementfree translation process as far as timing specifications is
concerned, and as a percentage of the resources (storage
space in particular) employed by the translator when it
contains no measurement artifact, as far as the utilization of resources is concerned.
It is to be emphasized that the introduction of measurement artifact for collecting most of the type of measurements in which we are interested should be an inexpensive undertaking if this task is taken into consideration during the design of the translator; moreso
if the translator is a well-organized and well-designed
translator. What may involve some cost is the processing and formatting of the measurement data obtained.
However, this is considered as a separate task subsequent to the translation process proper.
A special unit has been incorporated into the control
section of the META5 translator with the sole purpose
of controlling the collection of information about the
translation process. This unit controls simple software
measurement artifact which has been introduced into
the system.
From the programmer's point of view, the measurement instrumentation consists of a set of possible
measurements (i.e., l\IEASUREl, MEASURE2, ... ,
NIEASUREI, ...where I > 0) where each of :1fEASUREI gathers information on a specific set of events
and each can be turned ON/OFF (for either the first
or the second pass) at the META5 language level by
appropriate control commands.
In the lVIETA5 case the measurements (only the
collection of event statistics is discussed in the sequel)
are obtained as follows. The META5 implementation
consists, in part, of a pseudo-instruction decoder and a
set of routines. Each time a pseudo-instruction is decoded a series of calls is made to the appropriate routines in order to execute the pseudo-instruction. Most
of the measurement artifact has been introduced at the
decoder level. Each time a routine is called the measurement artifact increments a frequency counter associated
",ith that routine and records the clock; when that routine returns, the clock is recorded again and the elapsed
time added to a time counter associated with the routine.
These measurements provide statistics on the various
pseudo-instructions.
Measurement artifact has been introduced at various
other points (very few outside decoder) in order to
record the activity associated with certain specific
events. For it""lstance, the clock is recorded right before
and just after an I/O ·operation and the elapsed time
recorded and associated frequency counter incremented.
Also, measurements are gathered on the total time spent
in such events as the pseudo-code loading process. At
the end of a pass the collected measurement data are
processed, formatted, and output in an easy-to-read
form. Figure 1 displays a structural diagram of the
l\1ETA5 system which includes an indication of the
location of its measurement artifact.
The perturbation introduced into the translation
process by the measurement activity is relatively minor,
as shown below.
1kfeas".,trement data
The results of a number of benchmark measurements
are tabulated in Tables I through III.
The benchmark programs utilized were:
)lETA5 to pseudo-code.
ECR to pseudo-code.
Denotes the translation
(first pass) of META5
(which is written in l\IETA5) to pseudo-code.
Denotes the translation
(first pass) of a META5
program to pseudo-code.
This program analyzes
Software Measurements
735
program. The input data
used was a small set of
logic equations.
LOADER
DECODER
Tables I through III are self-explanatory; however,
some of the salient points should be noted:
1. Status restoring, in the backtracking process,
represents the most time-consuming (about 29
2.
RECOGNIZER
UNIT
BACKTRACK
UNIT
3.
COMMUNICATION
Ind
CONTROL UNIT
STORAGE
HANDLER
ERROR
PROCESSOR
4.
5.
UTILITIES
6.
Figure 1-8tructural diagram of the MET A5 system
7.
RM to pseudo-code.
CK to pseudo-code.
Execution of ECR.
Execution of RM.
FORTRAN programs for
purposes of parallel execution.·
Denotes the translation
(first pass) of a META5
program to pseudo-code.
This program accepts as
input certain logical
equations and produces
as output wire-list information. a
Denotes the translation
(first pass) of a META5
program to pseudo-code.
This program reformats
META5 programs into a
specified format.7
Denotes the execution
(second pass) of the ECR
program. The input data
used was a FORTRAN
program which simulates
a Boolean Analyzer. s
Denotes the execution
(second pass) of the RM
percent) section of a META5 translation (first
pass) process.
Inputting and outputting together represent the
second most time-consuming (about 25 percent)
section of a IVIETA5 translation (first pass)
process.
String comparisons and table look-ups together
represent the third most time-consuming (about
20 percent) section of a META5 translation
(first pass) process.
Arithmetic operations constitute a relatively
minor part (about 2 percent) of a META5 translation (first pass) process .•
The effect of the measurement artifact is relatively minor (:::; 6 percent).
The system is printer bound when source listings
are requested. If no listings are required the
translator is compute bound.
The backtrack stack requires many levels (37
levels for the benchmark programs used here).
Finally, the following definitions may clarify the
headings appearing in Table III.
The inputter is a unit which obtains, decodes, and
places in a repository buffer, elements from the input
stream. It permits backtracking the head of the input
stream if required, and allows the optional advancing of
the head of the input stream past certain characters
Table I
L1st~
or
IIOIIl'Oe ~
~or_
L1st~
or ..,.....,. _
on!
....
167.01.
137.5911
123.~
61.9»
133.758
19._
..
151.978
131.082
117.6~
58.~
126.~
18.~
••
1.a.722
117.702
J08.~
53.7l1li
122.880
17.rtT2
on!
m~or_
1Iou.t~orllOlll'Oe_
on!~d_
Spring Joint Computer Conference, 1969
736
Table II
The outputter is a unit which serves as a repository
buffer for the output stream and allows the specification of output record format. It also permits backtracking the head of the output stream if required.
CONCLUSIONS
J_Sn~1>e
_
_ _ tol1at~
of _ _ • • • • • • . • • •
12
17
2211.591
173.383
159.602
78.-19
193.925
26.23'1
........... .
253
3l.8
231
121
IS'
37
output • • • • • • • •
.,.,.
575
~
2!!5
70!!
15'1
37
Jl
31
29
20
I'
27.Wi
27.~
27.~
27._10
2l.~
18.308
15
'_Sn1ntos'pftt1
_
1 m _ _ to ..
~of_
••••••
_iaw..- ....... .
fIo.of_Sn_
-~
110. of _
--
_heiptof _ _
............ .
on.~-.
__
cadoSnIl1~
•.•.••••
Table III
...
--- --- -'""-*"P (Sie _
Ia1.-l~
(SIe_2)
~
-..
--..
-.-...
-
1)
_]a I-~
-"-
~ ~
AJ'I.
~
~
ObI
,.-.. ,.-..
ISle
_31
ICII5 to
~
------------
I'
31
13
26
15
32
1
11
15
:ze
1
10
12
ICllto
I'
11
III to
11
at to
12
or IDI
-_2:
'l!>o~lJ..ot.I_lB1ool~
to tho . . " _ _ or ln1al
_3: _
17
__
.lar~...
(no_1 _ _ ...
~'l.
... -"-w1tbtbo_ortbo1qlut_;tbllthU _ _
to tboiqlutWr.
11
11
111
or III
12
10
111
111
23
17
_-1
~1IIpl1.1toollo
~. _ . ~ ~ ... _ _ lJ..ot.I_ thU 001I00I18 _
_ _ _ _ _ lIboladlqlut_.
tod....
(e.g., blanks). The inputter is a component of the lexical analyzer.
This paper suggests the stipulation of a measurement
control center and associated artifact as a regular
feature of programming language translator specifications. Experience shows that the introduction of the
software measurement artifact required for the collection of the type of measurement data discussed here is a
simple and inexpensive task if carried out at translator
design time. Furthermore, the sample data presented
here indicate that the optional measurement activity
places a minor burden on the translation process.
The information to be gathered with such systems can
have great influence on future computer architecture,
especially machine language design, and in the simplification of the translator writing process. In addition,
this type of data aid in the determination of the direction of effort for future translator improvement and in
the evaluation of newer translator versions.
I t should be emphasized that the results presented
here were obtained on a single translator and specifically
on the :YIETA5 SIG:J,IA 7 inlplementation with which
the authors were involved. Thus, even though there are
no reasons to consider the implementation in question
atypical, the data must be viewed in proper perspective.
It is also worth noting that ~lETA5, as implemented,
is an interpretive system. If it were a compiling system
with, for example, elaborate optimization as a goal, the
relative percentages would show some changes.
These measurements substantiate the fact that the
translation of programming languages is not an arith~e
tic-oriented problem but rather a string-manipulation
problem. Hence, as far as the translation of programming languages is concerned, a machine language based
on string manipulations rather than arithmetic operations, should allow the effective, simple, and concise
implementation of programming language translators.
These considerations suggest some very interesting
nonconventional machine organizations.
As far as the determination of syntactic structure is
concerned, the high cost of backtr~wking serves as strong
justification for the considerable effort spent by many
researchers on precedence techniques6 which do not require the backtrack mechanism.
Finally, it is indeed worth mentioning some simple
hardware generally absent from present-day computers,
which would facilitate the coding of software measurement artifact. To wit:
Software Measurements
1. A variety of clocks, especially very fast clocks
(of the order of an instruction cycle) with a very
fast access time, as well as clock manipulation
instructions. Another type of clock which would
be useful would be clocks which accumulate time
intervals.
2. A number of counters, as well as counter manipulation instructions.
There is no reason why these features could not be
incorporated into a system at system design time in the
same manner, for instance, that hardware facilities have
been added to the newer generation of computers for
purposes of error detection and correction.
REFERENCES
G ESTRIN et al
Snuper computer-A computer instrumentation automaton
Proc S J C C 1967
2
7:{7
K OPPEXHEIM
The Jlf ETA.5 language and sysieul
~ystem 1>evelopment Corp Report 1':\1 -23!Jo 1006
;~ R MAX DELL
Private communication
-1 E C RUSSELL
Private communication
5 G ESTRIN
.vleasurement definitions and discussiolils
Unpublished paper
6 L PRESSER
The structure, specification, and evaluation of translators and
translator writing systems
PhD dissertation Dept of Engineering University of
CalifOlnia Los Angeles 1968
7 C KLI~E
Private communication
SMA MARIN
Investigation of the field of problems for the Boolean analyzer
PhD dissertation Dept of Engineering University of
California Los Angeles 1968
g T E CHEATHAM JR
The theory and construction of compilers
Computer Associates Inc Report CA-6606--0111 1966
j)
More on simulation l$ln011~u)'p.~ $lnd
---design methodology for computer
systems *
-~--~--
by DAVID L. PARNAS
Carnegie-Mellon University
Pittsburgh, Pennsylvania
INTRODUCTION
In an earlier paper! we attempted to set forth (1) a
design methodology for computer systems which made
heavy use of simulation and (2) a simulation language
intended to facilitate the use of the design methodology presented. The basic justification for the design
methodology presented an old precept from engineering
design: a problem must be defined before it is solved.
The result was a methodology which laid great stress
on specifying the behavior of a system or a component
in a system before producing the design. The simulation language, SODAS, was designed to allow a design
to proceed in a hierarchical way, treating any system
as a set of components, specifying the behavior of those
components, then treating the components themselves
as systems. By means of the SODAS language it was
to be possible to evaluate the design at any stage in
its development without excess effort.
One of the most fruitful results of the publishing of
"SODAS ..... "1 has been a number of useful discussions on design methodology and simulation with
other workers. Probably the most fruitful of these
discussions has been with Brian Randell, who had been
interested in similar problems, but with a somewhat
different emphasis and result. 2 A major result of those
discussions has been the realization that while the
basic design methodology described in "SODAS..... "1
* This work was supported by the Advanced Research Projects
Agency of the Office of the Secretary of Defense (F 44620-67C--D058) and is monitored by the Air Force Office of Scientific
Research. This document has been approved for public release
and sale; its distribution is unlimited.
is most general and should apply to all sorts of computer
system design problems, the specific characterization
of it given in "SODAS ..... "1 itself fails to meet
such application requirements.
An examination of the work leading to and motivating .SODAS shows that all the motivating examples
fall Into a rather restricted class of hardware modules.
!hat class can be roughly characterized as single level *.
Involving no interpretation of programs or even microprograms. It is not surprising then that we find that
the particular description of the design methodology
given in "SODAS ..... "1 and the structure of SODAS
itself are fairly closely restricted to that class of system.
I t is our purpose in this paper to explore a somewhat
less restricted expression of our basic design met hodology in an attempt to extend it beyond the limited
confines covered by "SODAS ..... ".1 In particular,
we expect to explore the design of computer systems
consisting of at least two (and often more) levels of
hardware and software. We shall refer to our system
class as the design of Operating Computer Systems
(OCS), since it usually includes both hardware and the
software known as the operating system for the hardware. It is also our hope to take into account the concepts about multilevel simulation given in Zurcher
and Randell,2 working them into the design of a sim-
* It is necessary to note here that we are deviating from the
way that level is used in "SODAS..... "1 to a usage that is more
consistent with Zurcher and Randell.2 In "SODAS..... ",1 level
referred to level of detail, i.e., the number of levels of definition
design completed in a state of partial design. The use of level here
is somewhat more complex and will be defined more precisely in
the text.
739------------------------------------
740
Spring Joint Computer Conference, 1969
ulation language which is more broadly applicable
than SODAS.**
The principal difference between the class of systems
discussed in "SODAS ..... "1 and the class that "\ve are
now interested in arises from the existence of a program
known as the operating system, which should be considered an integral part of the design problem. Early
computers were designed with no thought of an operating system, simply because they were to be run without
an operating system, As the need for an operating
system became apparent, these were designed separately from the fixed piece of hardware and had as their
aim efficient and convenient use of that piece of hardware.
The premise that we should proceed by specifying
the behavior of a syste~ before desigpjng its components implies that we can no longer look at an operating
system as an item to be placed on a previously designed
piece of hardware. The actual design should begin with
a specification of the overall behavior of the hardware/
software combination. It continues by dividing the
system into components and they, in turn, are designed
with little or no attention to the question of what win
be hardware and what will be software until very late
in the design.
In the type of system that SODAS deals with, the
nature of the svstem building block was clear; each
hardware moduie is composed of smaller or lower level
hardware modules until one gets to the realm of logic
elements. For syst3ms of hardware and software (OCS)
we must use as a component or building block a unit
which will allow us to postpone the decisions about the
hardware/software tradeoff. The unit we have selected
is the "sequential process", a rather fuzzy concept
which has been discussed elsewhere. 3 ,4,5 For our present
purposes we note that a sequential process is a fully
ordered set of events in an operating computing system
and may be performed either by hardware or software.
By building a design as a set of such processes we can
postpone the hardware/software decision as long as
desired.
Difficulties with SODAS
In the following section we shall attempt to discuss
some of the difficulties that the existence of hardware
** We have chosen in this paper to talk not about languages, but
about. the characterist.ics or features of languages. We will not at
any stage in this paper give a syntax OC the language, or even a
part of that syntax. Rather, we shall talk exclusively about
properties that a language must have for the purposes outlined
here. In part this is due to a feeling that the syntax of the language
is an irrelevant detail as well as the fact that the syntax of the
language is far from frozen at thiR stage,
and software as part of a system design introduces
into any attempt to use SODAS for such designs.
10 The existence of interconnectors at a lower leve 1
(further progress in the design) that did not
exist at higher levels (earlier in the design).
In the hardware modules any wires that
connect parts of one subsystem with parts of
another subsystem must exp licitly connect those
two subsystems. As a rule (though not invariable) all significant interconnectors between
two components are specified at the time that
the functions of those components are spec ified.
"X0 new interconnections show up as the design
progresses. In operating systems this is not the
case. It is reasonable and desirable that at
certain stages in a design the several sequential
processes will be described as entirely independent of each other except for certain explicit
attempts at communication. At a later stage
in the design we will note that these processes
have an implicit intercommunication because of
resource sharing. In SODAS with its requirement of explicit interconnectors, this would
require that the descriptions at the upper leve 1
be rewritten. This vio lates a design criterion
for SODAS-the use of SODAS should require
no extra effort
2. The problem of hidden resources.
At an early stage in the design it will be
reasonable to assume that all of a certain class
of resource that will ever be required by a
process will always be available. At a later
stage we decide that for cost reasons it will not.
The process will then go to use that resource,
find that it is not there and ,v':1it until it is 3.'v'ail=
able. SODAS will not permit us to add this
level of detail without rewriting the description
we produced at the more abstract level.
3. Communication through global variables.
The pretense that all communication is
through an explicit set of wirel'1 or variable:-;
becomes unreasonably restrictive when talking
about software operating systems. The simulation language and design methodology must
recognize the communication of processes
through global variables and files as well as
more subtle means of communication (e.g.,
changing the instruction counter of a process
or changing its code).
4. Expansion of time points to time intervals.
At early days in the design of an OCS certain
sequences of computations can be considered
. a "pom
. t'" In t'Ime
to he single events occupymg
Simulation Languages and Design Methodology
and separated by a specified period during which
nothing happens. It is assumed that the event
cannot be interrupted and that no time passes
except between events. At later stages in the
design it often becomes necessary to recognize
that time passes during an event since conditions not considered at earlier stages of the
design may cause the process to be interrupted
during an event. This in itself could conceivably
be handled within SODAS, or other simulator,
but there is no facility that would allow the
simulation system to determine the simulated
time of this interruption of the event unless we
force the programmer to insert timing throughout. The latter requires either recognition of
the problems of a later stage of design at too
early a stage or substantial modifications to a
description which is actually perfectly valid
for the level at which it is written.
Multi-level modeling-two views
Randell and Zurcher2 have presented a view of system
design and simulation which, on the surface, is quite
similar to that presented in "SODAS. ~~ ... "1 Both
papers discuss the value of being able to have a
simulation model which simultaneously includes descriptions at many levels of detail which are interacting.
Close inspection, however, of the two papers indicates
that the word 'level' is being used in two different senses.
The design process discussed in "SODAS ..... "1 can
be viewed as repeated functional decomposition. Each
unit is decomposed into a sub-unit, each with a distinct
function. When "SODAS ..... "1 speaks of 'levels of
detail' it is referring to the number of times this decomposition has been carried out in a given unit. Randell 2
sees a different direction of progress for a design, a
given functional unit will initially be described as an
abstraction from reality. Certain facts about its implementation are initially ignored, \vhile certain design
features are being explored. As one recognizes and
deals with these facts of life \vhich were initially ignored,
one proceeds from a high level of abstraction to a lower
level of abstraction. Often in doing a functional decomposition one is simply iatroducing functional units
which are needed to proceed from an abstract description of a component to one which enables the
component to exist in a restricted real environment.
In proceeding to a lower level of abstraction one is
often simply specifying the nature of certain components of the given component. Often, however, the two
notions of level are quite different. In functional decomposition the functional units specified are always
sub-units of the unit we are decomposing. That unit
741
is always viewed as self contained; in contrast, it is
common in going to a lower level of abstraction to
recognize sub-units which must be viewed as shared by
other components. Thus we are not simply decomposing
a given component into its sub-components. Often,
too, proceeding to a lower level of abstraction does
not involve any functional decomposition at all; it
may merely involve taking into account certain external influences on a given component. On the other
hand, functional decomposition does not always involve proceeding to a lower level of abstraction. 'fo
avoid confusion between these two concepts, we shall
hereafter use a "level" to refer to levels of abstraction.
"Ex-tent of functional decomposition" will be referred to
explicitly, where necessary, by that rather unwieldy
phrase.
Both extending functional decomposition and lowering the level of abstraction are consistent with the basic
precept of our design methodology; both involve proceeding from a specification of desired behavior to u,
means of achieving it.
The nature of distinct levels in
oes
To date we have left "level" as a fuzzily defined
concept. It is necessary now that we determine the
nature of levels of abstraction within a complete
system, i.e., that we answer the question: Under what
circumstances must we consider two actions in a computer system to occur at different levels-or-how do
we justify the statement that two subroutines within
the system deal with it at a certain level?
A fairly easy answer is that there is no concrete
realization of the term level within the system. That
the division between levels of abstraction is entirely
in the mind of the analyst or designer, who determines what is in the top level by what he chooses to
consider first. This rather easy answer, however,
ignores a regularity that can be observed if one studies
a number of examples of systems so divided into levels.
It appears to be the case that if we have described
a set of processes at some level when we proceed to
the lower level, we are either specifying or modifying
the specification of the interpreters of those processeH
previously described. In other words, a top level
description of a system is a description of a set of processes with an assumed interpreter, that interpreter
being essentially passive and accomplishing the actionH
specified by the process description as directly U,H
possible. When we move down to a lower level, we
begin to assign more complex fUIlctions to the interpreter, e.g., managing the resources being used by the
process and suspending action on the proces.'3 should
immfficiellt resources be available.
742
Spring Joint Computer Conference, 1969
What SODAS needs
SODAS was designed under the assumption that all
the component descriptions andlor process descriptions could be run using the same fixed interpreter.
There was no provision for making any substantial
alterations to the behavior of the interpreter or for
including new ones as part of the design process. Thus
SODAS HAS AN IXHERENT LL\UTATION TO
SINGLE LEVEL SYSTE?vlS.
Each of the difficulties pointed out earlier can be
neatly avoided by providing the ability to (a) make
certain changes in the operation of an interpreter
supplied as part of the system and (b) to provide for
the possibility of some simulated processes being the
interpreters for others.
SOCS
Having explored a little further the nature of the
design process for an OCS, we shall now look at the
design of a simulator for use in designing an OCS
(SOCS). We can first review the features that we found
missing from SODAS.
1. Communication through global variables rather
than interconnectors.
2. A flexible interpreter.
:3. Ability to sL."'1lulate a process which is beL.l1.g
interpreted by other processes being simulated.
4. Integration of the process describing languages
with the network description language. *
We may also list the features that we found in
SODAS that were missing in such process oriented
languages as SL\IULA. 4
1. Ability to have a process that consists of a set
of processes, e.g., recursive structure.
2. Ability to handle difficult cases of simultaneous
events.
3. Ability to handle structural descriptions of
hardware.
4. The "wait until" or monitoring feature found in
SOL, proposed for SODAS, but missing in
SE\lULA.
It is not possible at this point to give a detailed
description of the SOCS language. It is clear that it
will be somewhat reminiscent of SL\IULA with extra
constructs to provide the features that we have discussed. It is desirable that the language be such that a
SIl\1ULA program could be run without substantial
* This refers to the fact that SODAS was a language for connecting components described in other languages rather than a
language system,
changes though we would not object to extensive
surface changes. Although not essential, it will probably
prove convenient to provide constructions which allow
processes to be dealt with as SOL facilities or stores.
The sub-languages and connection concept will be
carried over from SODAS, though with a somewhat
subdued role as it will be possible but not necessary to
leave the SOCS language to describe a process (SODAS
allowed no primitive process to be described in SODAS
itself). At present the problem of simultaneous events
looks somewhat less central than it· did earlier and will
be provided as an optional, run time resolver rather
than the compile time solution planned for SODAS.6
On following a design philosophy
It is fairly easy to talk about designing from specifications to plans, outside in, top down, or from process
to processor. The way that a design should progress
is, at least at a certain level of generality, agreed upon.
It is quite a different matter to actually carry out a
design in that way when dealing with an OCS.
There are two serious difficulties that are encountered
should one try to follow this philosophy. The first of
these is an inability to really get started, to begin to
write down concrete information about the design.
One finds oneself in the position of trying to write a
program for a machine of unknown characteristics.
There is no starting point, no structure to build upon.
We are used to designing processes or programs by
starting with a very specific tool and looking for a way
to take this rather limited tool and get around the
limitations. Without the limited tool, with the limitations that we have become accustomed to suddenly
gone, we feel lost; the space of possible first steps has
become so large that ,eve cannot make the decision.
This difficulty can be somewhat alleviated by providing a higher level language in which to write. We
again have restrictions; the syntax and semantics of
that language, and the space is again reasonably small.
(The space, however, is nowhere near as small as that
provided by a machine language and there are very good
machine language programmers who still cannot readily
get started when faced with a higher level language to
write in. This is not a widespread phenomena, however.)
A difficulty which is expected by many people with
whom I have discussed the philosophy is the problem
of duplicate work. There have been many system
designs in which simulat~on played a part, but it was
clearly separate from design work. There was a separate group doing the simulation and it required either
extra money or a slower effort by the design group.
With talk of really extensive reliance on simulation,
people with such experience see a project. in which
Simulation Languages and Design Methodology
everything is done twice-once for the simulator and
once for the actual system. 'Vhile some might argue
that even such double effort would be. worth it if a
well designed system were to result, I wish to argue
that such double effort can and should be avoided.
The code written for the simulator must eventually
become part of the running system. If we write a
description for a process in some higher level language,
such as SOCS, and later specjfy and design an interpreter for that process, the higher level language win
have to be translated into a pseudo-code that is the
language of the simulated interpreter. The translator,
if the translation is done by a program, and the translated code should both eventually become a part of
the system. If, for example, the interpreter is designed
directly as hardware, the code is now machine code;
if the interpreter becomes a program on some other
hardware, it will continue to operate on the same code.
The effort involved in producing it for the simulation
is not wasted; the product becomes a part of the
system that is eventually produced.
Another important aspect of avoiding duplicate
work is that it not be necessary to rewrite a description
correct at the level of detail at which it was written,
because we are progressing further in the design'
(We will never avoid rewriting descriptions when we
make design changes.) This can be avoided to a very
large extent by our ability to modify the behavior of
processes, without altering their description, by
altering their interpretation or interpreter. The original
description thus remains both for purposes of explanation and as a specification of what is expected.
The second real difficulty is encountered at the end
of the design process, and has been reported to me by
Brian Randell. Randell had been following the design
process outlined using a facility for multi-level modeling implemented using FORTRAN running under
OS/360. vVhen he reached the point that he felt that
the design was complete, he found that it could not
become the system, since it still contained many points
of dependency on FORTRA.X, OS, and the /360 itself.
A design done in the way we are discussing cannot ,be
considered complete until the only processes being
interpreted by the system interpreter are those simulating the hardware. All other processes must be interpreted by the simulated hardware or by processes being
interpreted by the simulated hardware processes, etc.
A system like Randell's which was not specifically
7Lf'.2
.-:>:u
designed to allow Olle process to interpret another, callnot alIo\v the design to proceed to that stage.
Future work
The alert reader will note that while we have beel!
talking about design we have not been designing. It i~
our intention to design a version of SOC:S which can be
quickly implemented. We intend to go through a
complete design of a system of interest in itself) keeping
a Pl:otocol of the way that the design progresses. III
this way we hope to determine just how accurate our
picture of the design process is and further, in what
ways SOCS will have to be altered in order to keep from
interferjng with or distorting the design process. We
feel that after using the rudimentary system in a real
design, we will have a much better picture ot the final
version of SOCS.
ACKXOWLEDGl\1EXTS
I wish to acknowledge most gratefully the many
hours of discussion that I have had with Brian Randell;
each of those hours has improved my understanding of
the problems dealt with in this paper. I am also grateful
to C. Eastman and A. Perlis, who were kind enough to
read early drafts of this paper and to provide many
helpful comments.
REFERENCES
PAR~AS J A DARRI~GER
SODAS and a methodology for s!Jstem design
Proc F J C C 1967
2 F W ZURCHER B RA~ J)ELL
.11 ulli-level modeling-A methodology for computer
system des'igh
Proc International Federation of Information Processing
Societies 1968
D L
aD
L PAR:\'AS
Sequential process: A. fuzzy concept
Unpublished memo available on request from the author
-! ()
J DAHL K XYGAARD
SIMULA.-Au A,LGOL based simulation langllage
C A C M 670-678 September 1966
5 E W DIJKSTRA
Cooperating sequential processes
Technological University, Eindhoven, X etherlands
6 D L PARXAS
Sequential equivalents of parallel processes
Carnegie Institute of Technology Pittsburgh Pa
February 1967
Calculating and plotting equipotential lines for objects
with cylindrical geometry
by WILLIAM W. SHRADER
Raytheon Company
Wayland, Massachusetts
INTRODUCTION
A computer program has been prepared that calculates the position of equipotential lines in cylindrical
geometry for a multidielectric and multiconductor
environment using a modified extrapolated Liebmann
method. The output consists of printed voltages on
evenly spaced grid coordinates, and an automatic
drafting machine drawing of the dielectric and conductor boundaries and the equipotentials. The program has
been used to design Corona-free high voltage bushings
and terminals, and has been applied to other problems
where knowledge of the electrostatic field was desired.
The program is an example of how the advent of large,
high-speed digital computers has made possible easy
solutions of previously intractable engineering problems. Running time on the Univac 1108 computer is
typically one to two minutes.
The following are previous techniques used in an attempt
to solve this type of problem.
1. The cwnbersome tilted electrolytic tank,1.2
2. Resistance paper that ignores th~ cylindrical
geometry,3.4
3. The tapered resistance analog that represents
the cylindrical geometry properly but cannot
readily accommodate different dielectric constants,6
4. The inflexible approximate analytical methods. 6
Fortunately the author prepared and used this program before he read Reference 9 which states that this
approach will not work for dielectric ratios of 10:1.
The author, an engineer, has used the computer as an
engineering design tool. The program may not be optimum in a pure mathematical sense, but it does giv ~
the re:}uired engineering answers quickly and easily.
The method of solution is iterative relaxation using a
modified extrapolated Liebmann method7 The results
appear similar to those obtained in Reference 8. Briefly,
the problem to be solved is specified in terms of the
boundaries of the materials in the region of interest,
their dielectric constants, and the voltages, where known,
at the boundaries of the region of interest. The computer
then lays out a resistance analog matrix of resistors.
The value of each resistor is inversely proportional to
both the dielectric constant and the distance from the
axis of symmetry of the cylindrical geometry. Typical
matrix sizes are 48 X 80, but matrices as large as 100
X 100 can be accommodated so that adequate accuracy
can be obtained without the need to compensate for
boundaries that do not fall exactly on a grid point. 6
The computer then solves for the voltage at each point
of the matrix in terms of the adj acent four points. This
is an iterative procedure. After the computer goes
through the matrix several hundred times, the finish
criterion is met (the voltage at each point changes between subsequent calculations by less than one part
in 105 ), and the resulting voltage matrix is printed.
The computer also provides punched cards, if desired,
which are the input to an. automatic drafting machine
for drawing the material boundaries and the equipotentiallines.
Sample problem
Following is a description of the evolution of the design of a high voltage feed-through blishing. Figure 1
shows the cross section of the geometry of the problem.
The 41kv high voltage is to be fed through air from one
tank of oil to another. The pair of bushings is ceramic,
and the diameter of the metal center conductor has
been enlarged in an attempt to reduce the - voltage
stress in the air adjacent to the center conductor.
745------------------------------------------
746
Spring Joint Computer Conference, 1969
AXIS OF
CYLINDRICAL
SYMMETRY
~
CERAMIC Cit -6,0
_
OIL E,,~ 2.22
o
AIR E,,-1.0
Figure I-Geometry of high voltage feed through
Because of the symmetry of the problem, a solution
for the electrostatic field of any quadrant is sufficient.
The quadrant analyzed is the lower righthand quadrant
as indicated by the dashed line.
Figure 2 illustrates the drafting machine output of
the electrostatic field. Excessive bunching of the equipotentiallines occurs at the interface between air, ceramic,
and center conductor. The stress in the air at ~his point
is 50kvlinch as determined from the computer matrix
printout. It was then decided to provide an electrostatic
shield for the critical point by undercutting the ceramic
and metalizing the undercut surface. The result of
providing this shielding is seen in Figure 3. The stress
in the air at the junction of the center conductor, ceramic, and air is now 25kvlinch. The stress in the air pocket
between the first two ceramic fingers is also about
25kvlinch. There is a bunching of the lines at the inter-
Figure 2-Eiectrostatic field with original ceramic bushing
section of the shield, the ceramic, and the oil, but because
this bunching occurs in the oil, it creates no problem.
In another application of this same bushing, a high
voltage modulator deck wIll be located in the oil close to
the bushing. Figure 4 shows the analysis of this situation. The maximum voltage stress in air now occurs
between the third and fourth ceramic fingers, but it is
no greater than the maximum stress in air shown in
Figure 3.
The above problem was solved on a matrix grid of
88 by 48 points. The ceramic fingers were not identical
in the calculation because the actual ceramic fingers,
when traced onto graph paper, did not fall on the grid
in the same relative position. The closest matrix coordinates were used for each finger. Examination of the
problem on a fuier grid has shown that the approximations involved in using the 88 by 48 grid have not compromised the results. There is an edge effect that may
occur where the equipotentials meet the boundaries.
This effect, particularly noticeable in Figure 4 on the
right-hand edge, is a'local effect caused by the computer method of estimating the Neumann boundary
voltages and should be ignored.
Figure 3-Electrostatic field with modified ceramic bushing
Figure 4-Electrostatic field near H. V. modulator deck
Calculating and Plotting Equipotential Lines
747
The program
Two concepts are borrowed from techniques used
for manual relaxation. 7 One concept is that a
solution of the problem obtained on a coarse mesh can
be used to estimate the potentials for solution on a finer
mesh. The second concept is that with some boundary
voltages unknown (Neumann boundaries) a solution
of the problem in a region larger than specified can
yield accurate estimates of the voltages at the
periphery of the region of interest. For the above reasons,
the problem is solved in three successive steps where
the dimensions of the matrix are increased by a factor
of two for each step, and the dimensions of the problem
are increased by a factor of four for each step. The
final step is the solution of the problem as initially specified.
The problem shown in Figure 3 will be used as an
example. The actual shape of the pieces are traced on
graph paper; then the nearest coordinates on the grid
are selected for describing each piece as shown in Figure 5. The tapered ceramic fingers were identical before
the nearest grid points were selected to describe them.
When the voltages on the boundary are known, they
are specified as fixed voltages. This is true for the 410
volts (representing 41 kv) on the center conductor and
o volts on the metal on the right-hand edge. The N eumann boundary, along most of the bottom edge and part
of the right edge, i~ specified as an even gradifjnt from
410 to 0 volts on the bottom edge, and 0 on the right
edge. Specificatibn of the Neumann boundary is not
critical because this value will only be used for the first,
coarse solution of the problem.
The program reduces the mesh size by a factor of 4
and the coordinates of each piece by a factor of 16 (un-
111111 I1I11111111111111111
Figure 6-First solution
less the coordinate lies on a boundary; then the coordinate is reduced by 4). This results ih the problem
appearing as in Figure 6. This problem is solved, and
the voltages within the dashed line are used as initial
voltage estinlates for the next, more refined, solution.
The voltages on the dashed line are the Neumann
boundary voltages for the next solution. The second
solution uses a ::1esh one-half the size of the final mesh,
and the coordinates of each piece are reduced by a factor of 4 as illustrated in Figure 7. The third solution
is the final, full size solution. The initial voltage estimates obtained from the first and second solutions
generally vary only a few percent from the final voltages
of the subsequent solution.
To solve the problem, the program lays out a matrix
of resistors which connect each point on the grid with the
adjacent four points. The voltage at each point is successively calculated. The calculation at each point is
based on the voltage at the four adjacent points (refer
to Figure 8) . Values of El through Eli are stored in the
memory from previous calculations. 0 1 through O.
10 ..)
_._-
.-4
.----_.
-- .--
f:.; :~~~,
~ f:::~:-;:j.::: :-::=1··
..
• • --t . . -~--·-.··t
....
J.
:.:---:::-..:t:-_·-:--:::,·:::·· .... :---.::::..:++:
__
..
I-'--+-----'--
~-
~ .~~I~~~~tpt~l~ -L.::.::::: -~
" '•
_--.-._.---
'
-::-
.,.~~~
_. . .~~~
.-
~.....::.;:::;-=- -=:~:':: ~:;.+~ :"'::::......-:.~- ....... -~.:-...:..:::.----I------i-----.~.....:.:..:.
--- . --
.
W:::::r~i-~:'::~~f:t::~~;:t::~~~~~==T=-=====S-=t~]: ~ :-;~~
ffi=£p::~":f~:i:~2l=£:E=:--=e-' ftt-:--=PI-~::tf:[.H~
Figure 5-Problem as specified
Figure 7--Second solution
748
Spring Joint Computer Conference, 1969
calculations (Figures 6 and 7) use one part in 103 and
one part in 104 respectively as the finish criterion.
The first solution (Figure 6) of the sample problem
converged in 21 iter9J,lons; the second solution (Figure 7)
converged in 43 iterations; and the third solution
(Figure 5) converged in 89 iterations.
The practical problems examined so far have had the
relative dielectric constants not vary by more than a
factor of 10. Metal pieces, that in the resistance analog
are highly conductive, have always been attached to a
boundary where the voltage is given. To determine if
convergence would occur with a greater ratio of dielectric constants, the sample problem was rerun with a
piece of material with a dielectric constant of 25 inserted
in the air. This problem converged in 26 seconds
after 125 iterations for the third solution with the results shown in Figure 9.
Figure S-Resistor matrix
represent the conductances of resistors tying theadj acent
grid points together. The new value of E5 would be:
RELF
+ E5
(1)
RELFis the relaxation factor7 (also called the acceleration factor or convergence factor). RELF should lie between one and two; the speed of convergence of the
problem depends on the value of RELF chosen. This
program uses:
RELF
=
2(1 -
o.s.-vJ + j)
(2)
where the matrix has (p + 1) X (q + 1) points. For
example, a matrix 48 X 88 uses RELF = 1.88. Originally the equation is reference 7 page 273 was used;
this equation is identical to the above equation with
the 0.8 replaced by unity. For the few problem~ for
which a -comparison has been made, the above equation
leads to faster convergence than when the 0.8 is replaced by either 0.6 or unity.
The criterion that the iteratipn i~ finished is that no
point changes on successive iterations through the matrix by more than one part in 106 of the maximum voltage dlfierence in the matrix. Thus in the example given,
no voltage changes by more than 0.0041 volt on the
last iteration. This does not mean that the final voltages
are that precise, for spot checks have shown the absolute accuracy in places on the grid may be only one
part in 10 3, but this is believed sufficiently accurate
for most engineering applications. The two preliminary
Detailed description
The problem is laid out on graph paper where either
the horizontal axis or the vertical axis is the center of
the cylindrical geometry. It is assumed that the voltages
on the vertical axis are known (such as in the sample
problem where the vertical axis is the center conductor)
and the voltages on the horizontal axis are unknown.
The matrix size is determined, and the boundaries of the
dielectric pieces and the conductors are placed on the
grid. All coordinates are specified as row and column
grid coordinates starting at 0, 0 in the upper left-hand
corner. Thus a matrix specified as 48 by 88 will actually
have 49 by 89 points. This choice of input coordinates
simplifies both specifying the problem and scaling between successive solutions, bus it complicates handling
the matrices stored in the computer which must be subscripted, for example, from 1 to 49 and 1 to 89.
Figure 9-Example shoV\ring convergence with dielectric
ratios of 25:1
Calculating and. Plotting Equipotential
The program reads the input data in the following
sequence.
1. The matrix size (48 X 88) and a code number to
indicate which axis is the axis of symmetry.
2. The coordinates and voltages of each point
specifying the Neumann boundaries. The' program interpolates between the specified points
for the first calculation of the problem.
3. The coordinates and voltages of the points specifying the fixed voltages. The computer interpolates between the specified fixed voltage points
and sets the voltages on the boundaries to these
values before each solution of the problem.
4. The coordinates and relative dielectric constants of each piece of material. Metal is represented by specifying a very high dielectric constant (100,000.).
5. The voltage increment for drawing the equipotentiallines, if desired.
Three matrices are stored in the computer. The first
contains the voltages at each point (dimensioned as
E(101, 101)); the second contains the conductances of
the resistors to the left of each point and below each
point (dimensioned as G(101, 101, 2)); the third contains the sum of the conductances of the resistors meeting at each point (dimensioned as SUlVIG(101, 101)).
Although the space in computer memory is reserved
for matrices of 100 X 100, not all of this space is used
for smaller matrices.
The program examines the fixed input voltages, and
calculates 1/1000 of the difference between the maximum and minimum. This is used as the finish criterion
for the first solution of the problem. This value is multiplied by 0.1 and 0.01 for the next two solutions.
The size of the initial matrix is calculated to be the
specified size divided by four (12 X 22). Next, the
coordinates of the Neumann boundary voltages are
scaled to. match the initial matrix size, and the voltages are calculated for each point in the voltage matrix
on the Neumann boundary.
The scale factors for scaling the voltage coordinates
and the material coordinates are set for the first time
through the problem; the main portion of the program
is now entered. This main portion of the program is
re-entered for the second and third time through the
problem with only a change being made to the scale
factors.
The scaling of coordinates, whether for Neumann
boundary voltages, fixed boundary voltages, or the
conductor or dielectric pieces, is accomplished as follows. If the row (or column) coordinate equals the
height (or width) of the matrix, it is reduced by a factor
749
of 4; otherwise it is reduced by a factor of 16. Thus all
points specified as being on the matrix boundary remain on the boundary. For example, the coordinates
of the Neumann boundary voltage which was specified
as volts from point (34,88) to point (48,88) are scaled
to (2, 22) and (12, 22). (The coordinates are rounded
to the nearest integer.) The scale factors of 4 and 16
above are changed to 2 and 4 for the second solution and
1 and 1 for the final solution.
The main portion of the program:
°
1. Scales all the coordinates
2. Sets the fixed voltages on the matrix boundaries
3. Calculates the resistor matrix
4. Calculates the matrix of the sum of the conductances
5. Calculates the relaxation factor
6. Iterates the calculations of the voltage matrix
until the finish criterion is met.
After the first or second time through, the finish
criterion is multiplied by 0.1, the two scale factors are
divided by two and four respectively, the voltage
matrix is interpolated for estimating the voltage matrix
for the next solution, and the main portion of the program is reentered. After the third time through, the
resistance matrix is printed, and the voltage matrix is
printed. Finally if an input value is given for spacing
of the equipotential lines, the punched card output is
prepared for the automatic drafting machine.
Of the above steps, only two need further comment:
the calculation of the resistance matrix, and the calculation of the equipotential lines.
The resistance matrix is laid out in the sequence the
materials were specified. The materials should be specified in order of increasing dielectric constants, with the
conductors specified last. Thus the boundary of two
pieces will represent the conductivity (or the conductivity analog of the dielectric) of the piece on the boundary with greatest conductivity. The coordinates of the
pieces are specified on the mesh points. They may be
spaced any ~istance horizontally or vertically, but may
only be spaced one mesh square apart diagonally. The
points are specified in a clockwise direction around the
periphery of each piece.
The program examines the points in sequence. If a
point lies anywhere to the right or directly below the
previous point, resistors are inserted in the matrix. If a
point lies to the left or is identical to the previous
point (which may happen due to the scaling process), it
is ignored. When the resistors are inserted, they are inserted from the point vertically downward until a boundary of the piece is reached. The boundary is determined by examining the remainder of the points specify-
750
Spring Joint Computer Conference, 1969
ing the piece, looking for the nearest-below, right-toleft crossing of the boundary of the piece. Debugging
the logic of where resistors should be inserted for the
many possible shapes of materials required about 95
percent of the debugging effort of the program.
As mentioned earlier, the conductance of each resistor is stored in the resistance matrix. If the axis of
symmetry is the vertical axis, conductance of the resistor to the left of the point at row I, column J, is:
G(I,J~
1) = (2J - 1) D
voltage. Note that a given equipotential may cross a
row mQre than once. After all crossings of each row are
determined, all columns are searched for the specified
voltage. This completes the list of all points where the
equipotential crosses the lines of the mesh. These points
are then searched to find one on the mesh boundary.
Starting with the point on the boundary, all the other
points in the list are searched to find the closest one.
The process is repeated until all points are ordered in
sequence.
(3)
ACKNOWLEDGMENTS
where D is the dielectric constant. The conductance of
the resistor below point (I, J) is:
G(I, J, 2) = 2 JD
(4)
If the axis of symmetry is the horizontal
value of each conductance is:
aXIS,
the
I am indebted to Tom Weil for suggesting the problem
and providing the necessary background and references.
Ed Maybury has provided excellent continuing guidance in the use of the Univac llOS.
REFERENCES
W J KARPLUS
A.nalo(J sirnulalion
G(I, J, 1) = 2 ID
except where I
G(O, J, 1)
0, where
(5)
D/4
and
G(l, J, 2) = 2(1
+ 1)
D
The I and J in the above equations are based on the
mesh where the coordinates of the upper left corner are
specified as (0,0). T.he equation for G(O, J, 1) for the
horizontal axis of symmetry is commensurate with the
computer method of computing the E(O, J)'s, which
assumes a mirror E( ~ 1, J) equal to E(1, J), and a mirror G( -1, J, 2) equal to G(O, J, 2).
After the resistor matrix has been calculated, i~ is
examined for high values of conductances. All values of
conductance above 9999 are set to 1010. This ensures
that the conductors are not influenced by the voltages
in the surrounding dielectrics. This alfiP places the
limitation on the program that all conductors must be
attached to a boundary. (Before printing the resistance
matrix, all conductances of 1010 are set to 99999 so that
integers may be used in the printout.)
Each equipotential line is calculated in the following
manner. Each row of the voltage matrix is searched for
the specified voltage. Linear interpolation is used between grid point::; higher and lower than the specified
133 McGraw-Hill Book Co N"ew York 1968
2 P A EI~STEI~
Factors limiting the accuracy oj the electrolytic plotting tank
Brit. J Appl Phys Vol 2 49-55 February 1951
:3 J S BON~ESEN
A. corona free high vol/age feedthrough terminal design for
electronic application.~
Proc IEEE Electroni.c Components Conference 1965
4 J A ROSS
Submersible, pre-cast cable terrninators for splicing and
terminating at distribution voltages
Permali Ine Mount. Pleasant Pennsylvania
5 J R HECHTEL J S SEEGER
Accuracy and limitations of the resistor network used jor
solving Laplace's and Poission's equations
Pro(' IRE Vol 49 Xo 5 933-940 May H)61
6 H MCL RYA~ C \V WOLLEY
Sparking voltage. of (t, conductor passing thi Oiigh aft earthed
plate
Proc lEE Vol 114 No 1 172-178 January 1967
7 K J BI~NS P J LA WRE~SOX
1i. nalysis and computation of electric and
rnagnet?:c field problems
265-276 The Macmillan Company ~ ew York 196:{
8 J A SEEGER
Solution of Laplace's equation in a multidiel.ectric region
Proe IEEE let.tern Vol 56 No 8 1393-1394 August, 1968
9 R H GALLOWAY H MCL RYAN M F SCOTT
Calculation oJ electric fields by digital computer
Proc lEE Vol 114 No 6 824-829 June 1967
10 J) W PFJACEMAN H H RACHFORD JR
The numerical solution of parabolic and elliptic differential
equations
J Soc Indust Appl Mat.h Vol :{ No 1 March 1955
A modular system for reactor
calculations *
by L. JUST, A. KENNEDY, P. WALKER, A. RAGO··
and G. LEAF
Argonne National Laboratory
Argonne, Illinois
INTRODUCTION
The ARC (Argonne Reactor Computation) System has
been developed to facilitate the studies required for
fast-reactor design. The areas of physics, safety, fuel
utilization and core-design had initial priority. Other
general engineering capabilities will be added later.
Reactors have traditionally been designed by means
of stand-alone codes. However, it is rarely the case that
a single code will suffice for an entire calculation much
less for an entire reactor design. Usually, the solution
of one problem becomes the input to another problem,
but not without the intervention of conversion programs. This procedure is followed until the complete
solution is effected.
It was inevitable that the reactor industry would
sponsor the development of systems to automate the
design process. The first effort in this direction was
undertaken by the Knolls Atomic Power Laboratory
with the NOVA project in 1964. The ARC project at
Argonne National Laboratory was begun in 1965. Still
later, the JOSHUA project was begun in 1968 at the
Savannah River Laboratory.
The ARC system, when completed, will encompass
the field of reactor computations and automate what
was once a series of interrelated programs. A glossary
has been constructed that defines and formats an of the
types of data that can be expected for reactor calculations. In addition, a library of programs has been built
that will perform the mathematical and data handling
algorithms that occur in reactor computations.
A "system" capability has been provided that allows
the library and data to be used in a flexible, coordinated
manner. Reactor calculations can be accomplished by
designing a director program that executes modules from
the library in the proper sequence to operate on and
produce data.
Although such a system can be specified ·independently of a choice of computer, the implementation is not
computer independent; it depends upon a .choice of
machine and the manufacturer's software. ARC is
currently running on an IBM System/360 .50-75
combination using ASP. The system runs as an ordinary
job under OS/360 and it will run on any configuration
which uses OS/360. Practically speaking, ARC needs a
large amount of core and auxiliary storage, and a fast
CPU. These restrictions are caused by the nature of
reactor calculations rather than the nature of ARC;
reactor calculations involve a lot of computation and
require extensive data manipulation and storage
capabiliti~.
Design features
Original specifications
The original specifications for ARC required the
following features:
1. Modular approach. Any major computational
program consists of a collection of computational
units, certain of which are common to many
computations. A modular approach facilitates
the construction of such programs. In addition,
the modular approach provides a maximum
amount of core for each module provided the
system storage requirements remain small.
2. Common data base or data pool. In a modular
approach the data associated with each module
must be potentially available to any other module
in the system. This implies the existence of a
·Work performed under the auspices of the U.S. Atomic Energy
Commission.
··Present address: IBM Scientific Center, Palo, Alto, California.
751
752
Spring Joint Computer Conference, 1969
data pool which is responsible for intermodule
data management.
3. All coding in FORTRAN IV. If all coding is
done in high-level languages, then program
interchange is greatly facilitated.
4. Use of manufacturer's software whenever
possible.
5. Ease of use. This is probably part of the specifications for all systems and is an area where much
time can be spent even after a system becomes
operational.
Original iI-nplementation
Surprisingly, a simple initial approach satisfied all of
the criteria except 5. This approach was a huge overlay
'program with system functions in the root segment,
paths in region one and computational modules in
region two.
The overlay system shown in Figure 1 was in production before it collapsed of its own weight. Two flaws
dictated the approach described in this paper:
1. Overlays allow a limited number of external
symbols, and duplicate names are forbidden.
2. The system had to be reconstructed whenever
any change occurred anywhere in the system.
A small amount of assembly language coding turned
the overlay system into a dynamic loading system. The
computational modules of the overlay were assimilated
into the present system with few changes.
--~---
.- - -. - - .- ---,
R
~{
~
r
SYSTEH
FUNCTIONS
j
l~~~H'
COMPUTATIONAL
FUNCTIONS
Figure 1
The main components of ARC
1. A librar.i of programs (08/360 load modules).
2. ARC system subroutines that are useful to most
modules of the library.
3. A data set glossary that defines the data sets.
In addition, the ARC system is predicated on the use
of OS/360 with data in the form of 08/360 data sets.
Modules in ARC
ARC contains three kinds of modules, computational,
control, and system.
1. A computational module is defined in terms of its
input, output, and the algorithms that manipulate the input to produce the output. Input to
computational modules is in the form of data sets
and parameters lists; output is in the form of data
sets and printed output. All computational
modules are written in FORTRAN IV and are
loaded and executed by control modules.
2. A control module is a FORTRAN IV program
that can be executed as the main program of
ARC. A control module or path is directive in
nature; it causes computational modules to be
executed in the proper sequence to effect a series
of calculations. A path performs the following
functions:
a. Initialization of core to provide an environment for the computational modules.
i. Permanently loads resident system
modules.
ii. Initializes tables.
iii. Processes card input for later use.
b. Directs the computation.
c. Calls for subsets of the input data as they
are required.
:!1
J
2
The dynamic system
Paths are classified as standard if they exist in
the library at the start of a run or rwnstandard
if they are compiled at run-time. Any path is
allowed to use another path as it would any
computational module. This allows a new calculation to use an existing calculation if it performs
a useful subcalculation.
In order to initialize the system, a path must
contain two initialized arrays. The first array
contains the names of all of the data-sets used by
the path and by any module called by the path.
The placement of the name in the array determilles the data set reference munber associated
Modular System for Reactor Calculations
with the name. The second array lists the names
of blocks of input data that are required to
perfom1 the calculation. Input data is divided
into blocks with cards of the form
BLOCK = Nk\IEn
where N A~1En is an 8-character identifier. When
a path perfomls
a table that describes the input data set is
searched for the occurrence of the block XAIVIE.
If a block by that name that has not been
processed exists, it is formed into data sets.
Block names can be duplicated, and repeated
calls of the same name process the next block by
that name; when all blocks with that name hav::e
been processed, that fact is reflected in ~. This
facility is useful in repeated runs of a path. The
absence of a block can terminate the run or cause
another logical decision to be made.
3. ARC system modules perform functions that are
required by paths and computational modules.
They are of two types:
a. Resident. These are permanently loaded
into core and executed by the first path to gain
control. Resident system modules perform
the functions of system initialization, input
data processing, data management, and
internal table maintenance.
b. Transient. These modules are executed by
cert_ain of the resident system modules. Their
primary flllction is to ~f>rocess input data.
One module is used
0,
~in {y y ~ x, YES; } for x < 0,
for x
= O.
Rounding conversion:
r min {ylX <
R;(x) =
(y+y')/2, y
i min {y x ~ (y+y')/2, y
lO
E
E
Sa } for x > 0,
S~} for x < 0,
for x = 0,
where y' is the successor of y in Sa defined for y :;I: 0
by y' = min {z Iz > x, z E Sa} .
Note that a distinction is made in the definition of the
mappings of positive and negative numbers so that
Ta( -x) = -1p(x) and R~( -x) = -Ra(x).
Utilizing these definitions for describing input conversions by truncation to an F .P. system with six
significant digits base 16, one may simply state that
the decimal numbers 2.594, 3.5 X 10 6 and the binary
number 11.1~ become T~6 (2.594), T~6 (3.5X10 6) and
~6 (11.1 2) respectively. This notation is self contained
and unencumbered by any additional description of
the actual method of representing decimal and binary
numbers in a hexidecimal system. Turning to the
precise characterization of arithmetic operations in
F .P. systems, rounded multiplication of x and y in the
above F.P. system is succinctly denoted by R~6 (x·y),
where x . y has the usual meaning and no "pseudo
multiplication" symbol need be introduced. This procedure is readily extended to precisely describe whole
arithmetic expressions. For example, if X, Y, and Z
are input values which are truncated into an F.P,
system of six digits base 16, and if the following FORTRAN expression using X, Y, and Z is executed in
this F. P. syst.em utilizing rounded arithmetic,
Towards Atstract
x *Z * *2 -
SQRT(Y
~lr.athern.atical
+ 1000, * X)/2,
(1)
then a mathematical characterization of this expression
is given by the following formulation:
R~6(R~6(T~Q.(X) 'R~6([T~6(Z»)2»
- R~6 (R~6 ( -vi R~6 (T~6 (Y)
R~6 (1000T~6 (X) ) ) ) /2,) )
+
(2)
. The latter expression (2) is illustrative of how a
computerized calculation can be abstractly defined,
however, we do not suggest that such unwieldy expressions need often be written, Rather, if f(x) is the
desired function of x which we wish to calculate on a
computer, then we can let f*(x) refer to the appropriate
function of the form of (2) for computational analysis
purposes,
The collection of such functions available for computerized calculations can be characterized as follows,
Definition: For n ~ 1, f' ~ 2, the floating point rounded
n-digit base {3 digital functions, denoted F~, are exactly
those functions generated by the following rules:
Theor,i of Floating-Point Arithmetic
769
available on an n-digit base f' machine with rounded
arithmetic excluding underflow and overflow considerations (the case of truncated arithmetic may be treated
similarly). A computerized version of f(x) then is an
approximation in function space, with some function
f*(x) E F~ approximating f(x). Note that F~ effectively
includes the special functions (exponential and trigonometric) since these are generally calculated on
machines via polynominal or repeate4 fraction approximations, however the function resulting from pointwise numerical integration of a function f*(x) E F~
would generally not be in F~, since inequality side
constraints are used and this is not part of the procedure
for creating functions of F~, The utility of this definition of F~ is that the theoretical questions about the
properties of the class of expressions which can be
executed in the floating point hardware of the computer
can be abstracted to the level of investigating properties of Fa.
In summary the generalized conversion mapping
stands out as the important analytic tool which allows
us to abstractly characterize both base conversion
mappings and the functions equivalent to computerized floating point realizations of arithmetic expressions,
1. Constant Functions:
C
E
S~
=}
C
E
The analysis of floating point number systems
F~
2, Primitive Variables:
x a variable with domain S~
=}
x E Fa
3, Composed Functions:
Let f(Xl, x?, ' , "Xk), g(Yl, Y2, ' , ',Ym) E Fpbefunctions
of k and m variables respectively, then
h(xl, ' , "
=
Xk,
Yl, ' , " Ym)
R~(f(xl, x?, ' , "
Xk)
h(xl, ' , " Xk, Yl, ' , " Ym)
= Rp(f(xl, X2, ' , ., Xk)
+ g(Yl, Y2, ' , " Ym»
-
g(Yl, Y2; , , ., Ym»
h(Xl, ' , " Xk, Yl, ' , " Ym)
= R 8(f(xl, X2, . , "Xk) X g(Yl, Y2, ' , " Ym»
e F;
E
F8 .
E
F;
h(Xl, ' , ., Xk, Yl, ' , " Ym)
= R 8(f(xl, X2, ' , " Xk)/g(Yl, Y2, ' , " Ym» e F~
where appropriate modification of the arguments of the
function h is assumed if any of the variables Xi are
identical to any of the variables Yj,
Thus F~ includes mathematical characterizations of
the computerized arithmetic expressions which are
It will be instructive to demonstrate the formulation
of questions relevant to the structure of floating point
number systems in terms of the analytic structures we
have just introduced, The following five topics are not
intended to be exhaustive but do cover a wide range of
numerical questions relevant to floating point arithmetic.
It is not our intention to suggest that the new formulations of these problems will provide their immediate
resolution, rather we propose that these formulations
provide the precise mathematical characterizations
which are the necessary first step in any serious attempt
to develop a general theory of floating point arithmetic,
Errors of base conversion
In an earlier section the tape updating problem
pointed out one difficulty with decimal to binary base
conversion under truncation, Another question relevant to base conversion is: "how many digits should
be available in the computer's floating point numeric
base to maintain the distinctness of different input
quantities of a fixed number of decimal digits?" This
question may be formulated mathematically as: "Given m ~ 1, and f' ~ 2, what is the minimum value of
n such that the restricted mapping R8 : S~ ~ S~ is a
one-to-one mapping of S~ into (but not necessarily
770
Spring Joint Computer Conference, 1969
onto) S;?" In the solution2 to this problem it should
be noted that although elementary inequality conditions
are adequate to establish a number of digits, n, which
is sufficient to insure a one-to-one mapping; the necessity condition required to verify the minimlli'"ll value of
n was found by applying Kronecker's Theorem6 from
number theory to the appropriate number theoretic
formulation of this problem.
Proceeding further, the question of whether an iterated in-and-out conversion can always identically return
the original number is .formulated by asking for those
conditions on n, (J, m, 11 such that x = R;(R;'(x» for
all XES;. This problem was completely resolved 3 by
the same methods referred to above. It is instructive to
compare the general results of this abstract treatment 3
with a previous paper' which utilized representational
notation to establish only the simpler part of the general
theorem on i...l1-and-out conversion.
Algebraic structure of floating point calculations
Arithmetic calculations with floating point numbers
are intended to provide a realizable computational
process resembliIig operations in the field of real numbers. However, quite apart from the approximations
necessitated when calculating with floating point numbers, the invariance of the value of aritlunetic expressions under the familiar procedures of rearrangement
and cancellation is not obtained. Thus the algebraic
structure of floating point calculations is also only an
approximation to the algebraic structure of the reals.
This fact has been pointed out many times by showing
that the pseudo-operations of addition and multiplication realized in floating point calculations do not
possess the structure of a field.
Without appealing to pseudo operations, where the
addition and multiplication symbols must have meanings context dependent on the representational form
of the numbers on w:hich they operate, the questions
relevant to field theoretic structure can be succintly
stated utilizing significance spaces and conversion
mappings so as to preserve the normal meaning of the
arithmetic operators in the real number system. In
the following we fonnulate all the questions in our
notation and state the answers without proof, as they
are generally well-known and in any case represent
instructive exercises.
Doe8 Floating Point Arithmetic Satisfy the
Axioms of a Field?
If for x, YES;, we declare floating point addition,
subtraction, multiplication and division of x and y
to be given by R;(x+y), R~(x-y), R;(x' y) and
R;(x/y) respectively, then we have for:
Fl. Closure under addition:
Is R~(x + y) E S~ for all x, YES;?
Answer: Yes
F2. Closure under multiplication:
Is R;(x.y) E Sa for all X,y E S~?
Answer: Yes
F3. Associativity of addition:
Is R;(x + R;(y + z» = R~(R;(x
for all x, y, z ES;?
Answer: No
+ y)
+ z)
F4. Associativity of multiplication:
Is Ri3(x·Ri3(y·z» = Ri3(R3(x'Y) ·z) for all x, y,
z E',S;?'
. .
Answer: No
F5. Commutativity of addition:
Is R~(x + y) = R;(y + x) for all x, y
Answer: Yes
E
S~?
F6. Commutativity of multiplication:
Is R;(x·y) = R3(y'x) for all x, YES;?
Answer: Yes
F7. Identity under addition:
Does there exist x E S~ such that Ra(x
R;(y) for all YES;?
Answer: Yes (zero)
+ y)
F8. Identity under multiplication:
Does there exist x E S~ such that R3(x' y)
R;(y) for all YES;?
Answer: Yes (unity)
F9. Inverses under addition:
For each x ESa does there ex~t y ES~ such that
Rp(x + y) = O.
Answer: Yes
FlO. Inverses under multipJication:
For each· x ESp does there exist YES; such that
Rp(x.y) = I
Answer: No.
Note: Question FlO has many interesting
sidelights and has been the subject of a rather
extensive investigation. 7 Thus, for example, in
S~o the number 3 has the inverse .334, yet
R~o(I/3) = .333 is not an inverse.
FI1. Distributivity:
Is Rp(x·R;(y + z)) = R~(R3(x'Y) + R;(x'z)
for all x, y, Z E Sa?
Answer: No
Towards Abstract :Mathematical Theory of Floating-Point Arithmetic
The failure of many of the axioms of a field means
that many different functions can be suitable candidates for approximation of the single real function f(x),
and study should be given to detennine if a best choice
is possible.
771
is evaluated is much smaller than the t3 n - 1+ 1 points
of Sp in the interval [1,2]. However as the number of
halving procedures increases so that 2kN approaches
pn-l+ 1, the integration procedure will begin to add
significance to the erratic behavior of f*(x) and successive halvings may well determine a result deviating
more from
f(x) dx than previous results. Furthermore, increasing the halving procedure so that 2kN <
pn-l~ 1 does ~ot generate any new points but merely
duplIcates pomts already calculated, and it should be
evident that the consequent convergence of the numerical procedure does not in any way substantiate the
calculated result as a meaningful estimate of f(x) dx.
In performing numerical integration one must tread
his way along the same path as the physicist performing the classical derivations of thermodynamics, where
each of the infinitesimal intervals on which the limiting
procedure of the calcu1us depends must stilJ be 1arge
enough to allow a sufficient number of atoms so that
the statistical behavior of the assemblage of atoms is
meaningful. Thus the numerical analyst is obHged
to verify convergence of the integration when Z'N«
pn-l+ 1, otherwise the results .should be considered
spurious.
To appreciate the difficulties possible in numerical
differentiation observe that f(x) = x/ (x+2) is a monotonically strictly increasing function of x for positive
x, yet f*(x) = R;(x/R;(x+2)) exhibits a very peculiar
?ehavior. Note that as x~l, x ESp, each successive x
ill.creases the numerator, yet the denominator, R~(x+2),
will not change with every successive increasing value
of x E S~ in this range, and when it does change the
proportional increase in the denominator will be greater
than in the numerator for x sufficiently close to unity.
Therefore f*(x) shows an oscillating behavior as x~l,
hence numerical differentiation schemes which utilize
too fine a difference in x may pick up this spurious behavior of f*(x) and yield even the wrong sign for the
derivative.
It should be pointed out that the stock answer of
carrying more digits, that is, increasing n in the expression f*(x) = R~(x/R~(x+2)), would certainly decrease
the error function f(x) - f*(x), but does not alter the
oscillatory behavior of f*(x) compared to the monotonic
behavior of f(x).
Ii
Roots of equations
A general mathematical problem is to find a root
of the equation f(x) = 0, and when f(x) is suitably
behaved it is assumed that this is not difficu1t to solve
via algorithmic procedures with real arithmetic. However numerical work in evaluating f(x) is actually
performed with a specified approximation f*(x)E Fp,
and it appears pertinent to investigate the question of
whether f*(x) = 0 has any roots XES;.
Letting f(x) = ax + b be a simple linear equation
with a, b E S; and choosing f*(x) = R; (R;(a·R~(x))
+ b) E Fp, it is observed that a root of f*(x) = 0 must
satisfy R; (a· R~(x)) = -b.
For the case b = -1 this corresponds to finding an
inverse of a in S~ and it has already been pointed out
that such inverses need not exist, and, even when they
do, they are not necessarily given by R~ (l/a). The,
actual solution of R~ (a· R~(x)) = -b necessitates
solving a Diophantine equation subject to an inequality
constraint, and there is small utility in pursuing this
course.
However two pertinent observations emerge from
this discussion. (1) f*(x) = 0 need not have a solution
even though f(x) = 0 has, so that iterative schemes
which attempt to find a root of f(x) by working with
f*(x) must be designed with this knowledge in mind.
(2) f*(x) is a piecewise continuous step function of the
real variable x, thus f(x) - f*(x) is a piecewise continuous function in x giving the error in the computerized realization of f(x), and it is this well defined function which should be scrutinized for error bounds in
applied numerical analysis.
Integration and differentiation of f* (x)
The erratic behavior of a digital function f*(x) as a
function of x is a phenomena of immense importance
to numerical integration and differentiation. For our
purpose, a typical numerical integration procedure for
detennining
f(x) dx will divide the region 1 to 2
into N parts, evaluate f*(x) at these N mesh points and
average them, and then proceed through the same
procedure at 2N points (halving the interval), and
compare the results to see if a suitably small difference
is attained. It is evident that as this halving procedure
is continued one generally will converge towards
f(x) dx as long as the 2kN mesh points at which f*(x)
Ji
Ji
Ii
Accumulated roundoff error
The accumulation of roundoff error is the most
perplexing difficulty with computerized calculations,
and no overall resolution of this problem is available.
The simple propa.gative calculation of error bounds
yield bounds which are generally too wide when the
772
Spring Joint Computer Conference, 1969
same variable is encountered more than once in a calculation procedure, since the correlation of the errors
which are introduced is not reflected in the bounds.
Thus if it is known that a~f(x) ~ band 2a ~ g(x)
S 2b, then clearly 2a - b S g(x) - f(x) S 2b - a,
whereas if actually f(x) = x, g(x) = 2x, then the sharp
bounds would be a S g(x) - f(x) S b.
Statistical treatments of roundoff error have given
useful heuristic bounds but the fundamental problem
we wish to treat is deterministic. It is possible and
convenient in our notation to treat certain controlled
sequences of accumulating error. For example the
treatment of accumulated conversion error has been
fully described, 4 and it is suggested that the following
kind of investigations of accumulated calculation error
Let f(x) =
Xk,
and define f*(x) as follows:
flex) = R~(x)
fi(x) = Rp(x· fi-l(X) for 1
y), and conversely y directly reduces to x if and
only if there exist strings u, v, such that x = uZv and
y = uwvand
Z~wisinP.
x produces y (x ===
> y), and conversely
y reduces to x
if and only if either
x=y
or there exists a sequence of nonempty strings (wo,
Wl, .•. , wn ) such that x = Wo and y = Wn and
Wi
= >
W i+l
(i = 0, 1, ... n - 1 and n
~
1) .
x is a sentence of G if x is in T* - {e} and S produces x.
A contextjree language (abbreviated CFL) is then the
set of terminal strings that can be produced by grammar
G from its initial symbol S:
L(G)
= {x: (S:: > x)
& (x
E
T* - {eD}
777 ---------------------------------
Spring Joint Computer Conference, 1969
778
Let S produce x. A parse of the string x into the symbol
S is a sequence of rules PI, ... P n such that Pi directly
reduces Wi-l into Wi(j = 1, ... , n) and x = Wo, S = w".
Let x = aI, ... a, be a string of symbols a i in T, Then,
in some reduction sequence in which x = wo, let x
reduce to Wi = uak ... ar, with u in V* and 1 ~ k ~ r.
If Pi directly reduces string wi into w ft.l and P;1
directly reduces w i+1 into w i+2, then (P;, P il) is called a
leftm.ost reduction sequence if
W ft.1
= u'ak' ... a r
u' in V* x (V - T)
with Ail, Ai:!, Ail, Akl in V - T and ak2, 3m1 in T.
A very simple algorithm exists for converting any
grammar H into a grammar H' in normal form such
th9J. L(H) = L(H'). Because of this algorithm, all
derivations of sentences in L(H) are in one-to-one
correspondence with derivations of sentences in L(H ').
The algorithm works as follows:
All productions in P of H that are already in normal
form are taken into P' of H'. The remaining
productions in P are of the form
x
and
W ft.'
= u"ak
ll
•••
ar
u" in V* x (V - T)
~
Xl ... Xn
,
(n
>
2) & (Xi
E
V) .
Each production of this form is transferred to P' as
a sequence of productions.
and
Jv
k
~
~
Jv-1Xv+l
for
v = 1, ... , n - 1
k' ::; k" ::; r .
where I n - 1 is X. J o is Xl if Xl is in V - T of H;
otherwise an additional rule of the form
or
Wft.l = u'w and Wft.2 = u'A
is included in P'. The J lI are treated as new elements
in V' - T' of H', and the Jv are distinct from the
elements in V - T of H.
and
A parse (Pt, ... , P,,) is called a leftmost parse if and only
if the sequences (P i, P i+l) are leftmost reduction
sequences for i = 1, ... , n - 1.
If (PI, ... , P n) is a parse of string x into symbol S,
there exists a permutation of (PI, ... , P n) that is
leftmost. We define an unambiguous grammar G to be
one in which every x in L(G) has exactly one leftmost
parse.
We next define a normal form for CFG'~, in terms of
which a leftmost parsing algorithm can be designed.
The correspondence between this leftmost parsing
algorithm and a pushdown automaton model to be
introduced will then become apparent. Subsequently,
an algorithm for facilitating single-scan leftmost parsing
in a large class of grammars will be developed.
Normal form grammars
The fact that the J lI of the algorithm are "new and
distinct" leads to a simple proof of the one-to-one
correspondence between derivations of sentences in
L(H) and L(H'): Since each rule of P corresponds to a
particular rule or sequence of rules in pI, it follows that,
for each derivation possible in H, there is a corresponding derivation in H', and conversely. Because of this
unique correspondence, it also follows that ambiguity
in L(H) is equivalent to ambiguity in L(H').
Leftmost parses and normal-form grammars
In order to describe the algorithm for producing
leftmost parses of the sentences of a grammar G in
normal form, we introduce boundary markers ~ to the
vocabulary of G. A new initial symbol S' now takes the
place of S in G, and three new rules are added to G:
A grammar G = (V, T, P, S) will be said to be in
normal form if an the rules in P are of the forms
or
or
or
This has the effect of putting boundary markers at both
ends of all strings produced by the grammar.
Let Wo = ~ al ... an 11: be a string in the language
Systems for Designing Fast Prograw..:ming Language Translators
of such a grammar. In the initial step of the leftmost
parsing algorithm, rule P~ is applied, yielding string
Mter j steps,
Wo
has been reduced to
In this configuration, K I, ... , Kr are ail symbois of
V - T in the grammar. If Wo is in L (G), the leftmost
sequence of rules P~ = PI, ... , P j are precisely the first j
reductions of the leftmost parse of Wo to S'. Capital
letters are assumed to be members of V - T of the
grammars in the remaining discussion.
For the (j + 1) - th reduction, five different cases
must be distinguished:
Case (1)
For a rule of the form P i+1 = K;+I ~ as to apply for
the (j + 1)-th reduction, there must be one or more
symbols Z in V - T such that Z ~ KrY is in P and
Y ~ > ~+1U, with u in V*.
Since the set {K: W ~ > Ku & u E V*} can be constructed, the context in which Case (1) applies can be
found. The pairs (Kr, as) are the contexts in which the
rule ~1 ~ as applies.
Case (2)
For a rule of the form PHI = r<.~· Kr to apply for
the (j + 1) - th reduction, there must be one or more
symbols Z in V - T such that either
Z ~ Kr-IY
(0) S' does not produce w j, where w j
Kras
•.•
>
~
and
Y
and
X~RT
and
T
is in P
with u in V*.
Xu
an ~.
If S' does produce Wj, we have to distinguish
the following possibilities:
779
whereR ~
>
K;
betw~en
= ~I ~ as reduces w j
to Wj+I.
(2) A rule of the form P i+I = K;. ~ Kr reduces w j
to Wj+l.
(3) A rule of the form P i+I = K;.-I ~ Kr-IK r
reduces Wj to Wi+I.
(4) A rule of the form P i+1 = K;. ~ Kra s reduces Wj
to Wi+I.
(1) A rule of the form P i+I
That only these cases need be considered is proved in
[13]. Note that each of the applications of rules P i+1 in
cases (1)-(4) leaves the length of string w i+I either the
same as that of Wj or reduced in length by one symbol.
This fact is used in a later proof of the upper bound on
computation time required by the leftmost parsing
algorithm.
In general, the decision concerning which of the cases
(1) to (4) apply for the (j + I)-th step of a leftmost
parse must be made in terms of context. As an example,
there may exist rules in the grammar having Kr-IK r and
Kras on the right part. To decide which case applies at
a given step of the parse then requires algorithms for
discovering what symbols can legally be adjacent to the
symbols being reduced in that step of the reduction
while Wo is a sentence of G. The algorithms to be given
in what follows are similar to those of Floyd2 and Wirth
and WeberI6 in that they construct all legal cooccurrences of triples of symbols in some language from that
language's grammar.
>
~
Z~
or
is in P
Ya8
and
y
~
>
and
X
~
Kr-IR
where R ~
with y in V*.
a 8 y,
>
uX
with u in V*
K;.
The pairs (Kr-l, as) are the contexts in which the rule
K; ~ Kr applies.
Case (3)
For a rule of the form P j+1 = K;-I ~ Kr-IKr to
apply for the (j + l)-th reduction, there must be one
or more symbols Z in V - T such that
Z ~ YX is in P
and
X b
>
a~u,
and
y ~
>
wK;.-I with w in V*
with u in V*.
The pairs (K r- I, a 8 ) are the contexts in which the rule
K~-I ~ K r-IK r applies.
Case (4)
For a rule of the form P j+l = K;. ~ Kra s to apply for
Spring Joint Computer
780
Conf~rence, 1969
+
the (j
1) - th reduction, there must be one or more
symbols Z in V - T such that
y ~
and
> K;.u with u in V*.
The pairs (K r- 1, a 8 ) are the contexts in which rule K; ~
applies.
Mter the contexts for which cases (1)-(4) apply have
been determined, there may in general still exist rules
having the same contexts. The existence of such rules in
a grammar may imply t.he necessity of backtracking
methods for use in parsing a given string of that
grammar. Or, such a grammar may be ambiguous. In
the following section, we sketch a formal model for this
normal-form leftmost parsing algorithm. In terms of
this model, we can present an algorithm for eliminating
the necessity of backtracking in a large class of unambiguous CFL's.
NxNx {So} x(T U Ie}) U (N U {e}) xQx(T U {e})
-{e}xQx{e}.
e. So is the initial state of the computation, and F is
called the final state.
f. jiJ is a special symbol such that
K,.8.8
Let A = (Q, T, N, M, jiJ, 80, F) be a BCA. A configuration of A is an element of
{ # } x (N -
a. Q is a finite set, called the states of the machine.
b. T is a finite set of symbols, called the input-tape
vocabulary .
c. N is a finite set of symbols, called the pushdownstore vocabulary.
d. M is a mapping of N xQxT into the finite subsets of
-
{jiJ}) * x { ~
I.
Co = (jiJ Sox jiJ),
where x E T* - Ie} is the input string to be accepted.
The final configuration is (jiJ F jiJ). The computation
performed by a BCA is essentially a reduction sequence
that reduces Co to the final configuration.
Let C j and CHI be two configurations of a computation. Then, C j direztly reduces to CHI, or C j 1- CHI, if
C; = (t Z 81 a w) , CHI = (t Y 82 b w)
and where
(y,
Ss, b) E M(Z, S1,
a)
and
[(t
= e) & (Z =
& (Z
E
jiJ) V (t E { jiJ } x (N - {jiJ D*)
(N - {jiJ D)]
&[(w=e)&(a= jiJ) V (wE(T- {jiJ})*x{jiJ})
& (aE (T - {jiJ}) ) ]
& r-.J [(Z
P = (Q, T, N, M, jiJ, So, F) ,
where
* x Q x (T
the configuration (jiJ t SI y jiJ) denotes the fact that the
acceptor A is in state SI, with string jiJ t on the pushdown
store and string y jiJ remaining to be read on the input
tape.
By analogy to our notation for CFL's, we can define
an initial Configuration of ~ computation to be
Pushdown automaton parsing model
In this section, we present an automaton model of
our leftmost parsing algorithm. This model will be called
a bounded-context acceptor (BCA), and can be described
intuitively as follows: It has a finite number of states,
a finite input vocabulary, and an auxiliary memory
stack mechanism (called a pushdown store). In addition,
it has an initial (or starting) state, a final (or accepting)
state, and a boundary symbol jiJ whose function in the
scheme is analogous to the control cards used before and
after a computer program. In general, the BCA is in
some state, and is scanning the topmost pushdown-store
symbol K and an input-string symbol a. In a possibly
nondeterministic manner, the BCA goes to another
state, either by erasing K or by erasing a in the process,
and possibly storing a new symbol on top of the
pushdown-store. All these notions are restated more
precisely in what follows.
A bounded-context acceptor P is defined to be a
seven-tuple:
{~})
=
jiJ) & (a =
jiJ)]
and
(b
E
(fa} U {eD) & [(y
& (Z
~
V (y
E
E
(Z U {e}) x (N U {e}))
jiJ)
{ jiJ } x (N U {e D) & (Z = jiJ)].
We next define the sequence of configurations that
leads to a complete computation of the acceptor.
Let
and
be configurations of the computation. Then 0 1 reduces to
Ct, or 0 1 I..!... Ct, if there exists a sequence of configura+;nnQ
fR_ R.
U&V.a..a..;J , .........u, .... ..Ll'
••• ,
R.'\
~
_
A-.4.", "nnf'h
'u.a."'.a..a. vI =
R
nrl ~
vi
.......... 03u....'-A.
TT
~ nj
input-tape symbol. Since the full BOA model only allows
the pushdown store to be increased in size during a
transition into state So, this additional restriction means
that the pushdown store of a constructed BOA can
increase in size by at most one symbol for each input-tape
symbol read during a computation.
The BOA is constructed from a normal-form grammar
as follows: For all rules in the grammar of the forms
ana.
_1
(i = 1, ... , j) .
Then, the language accepted by a BOA P is the set of
input strings given by
L(P) = {x: [(# Sox#) I.!... (# F #)] & [x ET* - tel]} .
In the more standard pushdown-automaton acceptor
model, 3 M is treated as a mapping from
(N - {#}) x Q x (T U {e} - {#})
into the finite subsets of (N - { # }) * x Q. This formalism
implies the existence of transitions between states in
which the current input-tape symbol is ignored (i.e., the
empty symbol e is erased from the input tape). When an
input-tape symbol is used for a transition in this model
. .
'
It IS always erased during the transition. Thus, while a
standard pushdown automaton having the same
language can always be constructed from a BOA the
.
'
notIOn of context in determining a transition is lost, and
the resulting acceptor will generally have fewer uniquely
defined transitions than the original BOA. Moreover,
given a standard pushdown automaton, a grammar for
its language can always be found, 3 and, from this
grammar, a BOA can be constructed to accept the same
language, as will be seen. Hence, BOA's and standard
pushdown automata are equivalent in computational
power, but a BOA with uniquely defined transitions does
not always correspond to a pushdown automaton with
uniquely defined transitions.
A utomaton realization of leftmost parses
With the BOA model defined above, it is possible to
introduce a correspondence between rules of a normalform grammar and the states and symbols of a BOA. In
this correspondence, the initial symbol S of a grammar
becomes the final state F of the BOA. Furthermore, the
BOA constructed from a normal-form grammar is a
slightly restricted version of the BOA model. This is
because transitions from initial state So of a constructed
BCA can only occur together with the erasure of an
(where the capital letters are nonterminals and the small
letters are terminal symbols), the Ajl's and Ai'l's become
states of the BOA. The Aa's become members of N ,
the stack vocabulary, and the a J"2's become members
of T, the input-string vocabulary. What follows is the
algorithm for constructing a BOA that accepts the
language of a normal-form grammar. The algorithm is
in four sections corresponding to the four rule types
allowed in normal-form grammars.
I. Rule Ai
~
AaAt"2 with con.texts (A,")., a.):
If Ai E N, then (Ai, So, a,) E M(A,")., At"2, a.).
If Ai E Q, then (e, Ai, a,) E M(Ail, Ail, a.).
These transitions take care of all possibilities arising
from case (3) of the leftmost parsing algorithm. If Ai is
in N, that means that a pair of nonterminals A~J"2
appears on the right part of some rule of the grammar.
Hence, Ai is stored on top of the stack, and the automaton transfers to its initial state, from which it
proceeds to discover Aj2. If Ai is in Q, then Ai is either
the second nonterminal of some rule of the grammar or
is the first nonterminal in a rule of the form Ale ~ Aiak2.
In either case, the stack does not increase in length
during the' transition.
II. Rule Ale ~ ~lale2 with contexts (Kr-I, ak2):
If Ale EN, then (Kr-IAle , So, e) EM(K r_l, Alel , ak2)'
If AI;
E
Q, then (K r- l, A k , e) E M(K r- l, Akl , ak2).
These transitions take care of all possibilities arising
from case (4) of the leftmost parsing algorithm.
III. Rule Aj
~
a, with contexts (Kr, a.):
So, e) E M(K r, So, a.).
(Kr, Aj, e) E M(Kr, So, a.).
If Aj EN, then (KrAj,
If Aj
E
Q, then
These transitions take care of all possibilities arising
from case (1) of the leftmost parsing algorithm.
Spring Joint Computer Conference, 1969
782
IV. Rule Ai ~ Ail with contexts (K r - l, a 8 ) :
For every chain of rules in the grammar of the form
P l = A~A(1)
P2
P1l
=
=
A(l) - t ...A~(2) , ••• ,
A(1I-1)
~ A(1I)
with n
~
2 ,
and such that there is at least one context (l(;.-I, a;)
common to rules (PI, ... , P 11), we introduce automaton
transitions of the form
(l(;.-l, A (11-1),
a~)
E M (l(;.-I, A (11),
programming language having nested block structure,
conditional statements, and arithmetic assignment
statements. The ALGOL conventions are used for
representing symbols of the grammar; i.e., members of
V - T are enclosed by the metasyntactic brackets
" (" and" )", and members of T are not. The symbol
is a separator that allows two or more rules having
the same left part to be written together.
"I"
Table I-A grammar for a simple progranuning
language
a~)
G:
These (A (1),
BCA.
••• ,
A (11») are thus treated as states of the
(program) - t (body) (stat) end
(body) - t begin I (body) (stat);
(stat) - t (program) (assignment)
(assignment) - t (var) : = (expr)
I ,.,.
~expr ) - t ~Slmple expr) I ~11 ClaUSe)
(simple expr) else (expr)
(simple expr) - t (term) I (simple expr)
+ (term)
(term) - t (factor) I (term) * (factor)
(factor) - t (var) (number) [(expr)]
(if clause) - t if (relation) then
(relation) - t (simple expr) = (simple expr >
(var) - t
(number) - t (digit) (number) (digit)
(digit) - t 0111 ... 19
I
I
For all contexts (Kr-I, as) associated with individual
rules Ai - t Ail, we have the following:
If A j
If A j
E
E
N, then (Kr-IA j , 80, as) E lVI(K r _ 1, Ajl, aa).
Q, then (K r - l , Ail as) E A'l(K r _ l , A jl , a,).
These transitions take care of all possibilities arising
from case (2) of the leftmost parsing algorithm.
When all transitions of a machine have been defined
as described above, the language accepted by that
machine is the language of the grammar from which it is
constructed .14
A simple programming language translator
The following is a simplified grammar for a computer
\
I·
'1
\
I
'1
\
I
AIBlcl ... Iz
I
The programming language G easily reduces to the
following normal-form grammar G' augmented by the
addition of endmarkers:
Table II-The normal-form version of grammar G
G': 8
- t YIJ~
Y I - t Y2 (program)
Y2~
(program) ~ Xl end
Xl ~ (body) (stat)
(body) ~ begin X 2 ;
X 2 ~ (body) (stat)
(stat) - t (program) I (assignment)
(assignment) ~ Xs (expr)
Xs ~ (var) :=
(expr) ~ (simple expr) I X 4 (expr)
X 4 ~ Xl) else
Xl) ~ (if clause) (simple expr )
(simple expr) ~ (term) I Xe (term)
Xe ~ (simple expr) +
(term ) ~ (factor) I X 7 (factor)
X 7 ~ (term)*
*
I
I
I
(factor) ~ (var) (number) Xs]
Xs ~ ~ (expr)
X g -t l
(if clause ) ~ X IO then
X IO - t Xu (relation)
Xu - t if
(relation) ~ X I2 (simple expr)
X 12 ~ (simple expr) =
(var) - t
(number) ~ (digit) (number) (digit)
(digit > ~ 0\11 ... 19
AIBlcl ... IZ
I
"What follows is a table of contexts in which the rules of G' can be applied during a leftmost parse of some string
in L(G'):
Systems for Designing Fast Progrannuing Language T"ranslators
783
Table III-Contexts associated with rules in Table II
Rule
S
~Yl~
Contexts
(e,
~)
Y I ~ Y 2 (program)
(Y2,
Y2~ ~
(e, '*),
(program )
Xl
~
~
~)
(Y2, end), ( (body), end)
Xl end
(body) (stat)
( (body), end)
(body )
~
begin
(Y2, begin), ( (body), begin)
-(body )
~
X 2;
(Y2 ,
X 2 ~ (body) (stat)
;), (
(body), ;)
«body), ;)
-
~
(stat )
(program)
( (body), end), «body), ;)
(stat ) ~ (assignment)
( (body), end), «body), -;)
(assignment ) ~ X3 (expr)
(X 3, end), (X 3, ;)
X3
~
(var) :=
({body), :=)
(expr ) ~ (simple expr)
(expr)
X4~
~ ~
~
~
X 4 (expr)
(X3' ;), (Xs, end), (Xg,
])
(X4, end), (X4' ;)
---(Xs, else), (Xg, else)
else
(if clause) (simple expr)
( (if clause), else)
(simple expr ) ~ (term)
( (if clause), else), (Xs, ;), (Xs, end,
(X9,]), «if clause), + ), (X4, + ), (X a, +),
(Xg, +), (Xu, =)
(simple expr ) ~ X6 (term)
(X6, +), (X6, else), (X6, ;),
(X6, end), (X6, =), (X6, then), (X6, ])
X6 ~ (simple expr)
+
«if clause), +), (X4' +), (Xs, +), (Xg, +),
(X12,
+),
(Xu, +)
.....-
(term)
~
(factor)
(X 6,- +), (X6, =), (X6, then), (X 6, else)
(X6, *), ( (if clause), *), (XI2, *),
(X4' *), (Xg, *), (Xs, *),
«if clause), else), (Xs, ;), (Xa, end),
(~,]), «if clause), +) -, (X4, +),
(Xa, +), (Xg, +), (Xu, =)
784
Spring Joint Computer Conference, 1969
Contexts
Rule
(term)
---?
X 7 (factor)
(X7,]), (X7' ;), (X7, end)
X 7 ---? (term)*
(X6, *), ( (if clause), *), (X12, *), (Xu, *)
(X4' *), (Xs, *), (Xo, *)
(factor)
---?
(var)
(X7, *), (X7,
(factor)
---?
(number)
(X7' else), (X6, +), (X 6, =), (X6, then),
(X6, else), (X6, else), (Xa, *), «if clause), *),
(Xu, *), (X4' *), (X9, *), (Xs, *),
( (if clause), else), (Xs, i), (Xs, end),
(X9' )), «if clause), +), (X4' +),
(Xs, +), (X9, +), (811 , =)
(factor)
---?
Xsl
(X7,]), (X 6 ,]), ( (if clause ),]), (Xu,])
(Xu,]), (X 4,]), (Xv,]), X a,])
+), (X7, =), (X7, then),
Xs ~ Xo (expr)
(Xo,D
X9~
(Xv, l), (X7' [), (X6, l), ( (if clause ),
(Xl!, D, (Xu, [), (X s, [), (X4' D
[
(if clause)
---+ X IO then
(X3, then), (X4' then), (Xi" then)
XlO ---+ Xu (relation)
(Xu, then)
Xu ~ if
(Xs, if), (X4' if), (Xg, if)
(rela.tion) ---+ Xl! (simple expr )
(Xu, then)
Xu
(simple expr) =
---?
(var)
---?
(Xu, =)
A
(number)
D
(X7, A), «body), A),
(X 6 , A), (X 4, A), (Xo, A), (Xa, A),
(X12' A), (Xu, A), «if clause), A)
---?
(number) (digit)
I
I
( (number), 1») ... , «number), 9)
«number), *), «number), +)
«number), =), «number), then)
«number), else), «number), ;)
( (number ), end)
---------------------------------11-------------------------------(digit)
---?
i i ... I 9
0 1
( (number), 0), ... , «number), 9),
( (if clause), 0), ... , ( (if clause), 9),
(X7' 0), ... , (X 7, 9),
(X6, 0), ... , (X 6, 9),
(X4, 0), ... , (X 4, 9),
(Xu, 0), ... , (Xu, 9),
I (Xa, 0), ... , (X12,9),
I
I
· Systems for Designing Fast Programming Language T'ranslators
From Table III, a flow chart of the BCA that accepts
L(G') can be constructed. This flow chart is abbreviated
in that, for a given state, only those contexts necessary
for determining a transition are presented. Thus, when
no ambiguity will be introduced, only the stack symbol
or the input-string symbol is used for determining which
of several possible transitions can occur. In the flow
chart, the array N, with index i, is used to represent the
symbols of the stack, and the array S, with index j,
represents the symbols of the input string. Note that
"error exits," i.e., the instances of case (0) in the
leftmost parsing algorithm, are omitted from the flow
chart. An error is assumed to exist at any transition in
which the appropriate symbols are not present on either
the input string or the stack.
The next step after synthesizing a BCA as in Figure 1
is to design a translator· for the language accepted by
that BCA. To do this, we employ a notation similar to
that used in [13], and available in numerous versions in
the current literature. The basic idea of the notation is
to introduce rules of translation in a one-to-one correspondence with the rules of the original grammar.
These rules of translation describe the effect of trans-
NTIALIZATION
i-O
Ni-·
j-I
lating the right parts of the syntactic rules with which
they are associated. As an example, we might have the
following pairing in some grammar:
Syntactic Rule:
Rule of Translation:
(term ) ~ (term) * (factor) (term) (factor) multiply
This pairing of rules can be represented as a translation grammar G t = (G, 0, f), where G = (V, T, P, S) is
the programming language syntax, 0 is a translated
program vocabulary, and f is a one-to-one mapping
from Pinto PxO*. The rule of translation given in the
above example is easily recognized as one rule for
converting from standard arithmetic notation to reverse
Polish notation. In the translated sequence '(term)
(factor) multiply', the translated objects corresponding
to (term) are written out in the sequence determined
by the rules of translation associated with the syntactic
rules derived from (term), and likewise with (factor).
In general, if a rule of translation is identical to the
right part of its associated syntax rule, we write the
symbol 'I' in place of the rule of translation.
l-i+1
Ni -
i85
(If clause)
j-j+1
i-i+1
.-------fNj- 5j
j-j+1
(tlglt)
1-1+1
NI-
<'!:,Ie) Sj
j-J+I
To So
Figure I-The BCA acceptor of L(G')
i-I+I
NI-(body}
j-j+1
To So
786
Spring Joint Computer Conference, 1969
We can next present the-simple programming language given above as a translation grammar:
Table IV-Translation grammar for a small language
Syntactic Rules:
G:
Rules of Translation:
(program) ---» (body) (stat) end
I
(body) ---» begin
I
(body) ---» (body) (stat);
I
(stat) ---» (program)
I
(stat) ---» (assignment>
I
(assignment) ---» (var) : = (expr)
(var) (expr) assign
(expr) ---» (simple expr)
I
(expr) ---» (if clause) (simple expr) else (expr)
(if clause) (simple expr) then (expr) else
(simple expr) ---» (term)
(simple expr) ---» (simple expr)
I
(simple expr) (term) add
+
(term)
(term) ---» (factor)
(term) ---» (term)
*
I
(factor)
(term) (factor) muUiply
(factor) ---» (var)
I
(factor) ---» (number)
(factor )
~
numberoperand (number)
l (expr )]
{expr>
(if clause) ---» if (relation) then
(relation) if
(relation) ---»
(simple expr )(1) = (simple expr )(2)
(simple expr)(1) (simple expr )(2) equals
---------------------------------------------------------------------------------(var)
~
A
variableoperand A
(var) ---» Z
variableoperand Z
(number) ---» (digit)
I
(number) ---» (number) (digit)
1 10 (number) muUiply (digit) add
I
(digit ) ---» 0
I
(digit) ---» 9
I
Systerns for Designing Fast Progranuning Language Translators
The details of the translator grammar can be explained briefly: Essentially, arithmetic expressions and
relations are translated into reverse-Polish strings
through the rules of translation. Conditional expressions
are rearranged so that if, then, and else become placemarkers in the translated program, and the device that
interprets the translated program contains routines for
passing to the statements directly following if, then, or
else as appropriate. Since the effect of interpreting the
translated program is to coalesce assignment statements
into a single resultant operand that is the "value" of the
assigned expression, the semicolon ";" that separates
program statements is written into the translated
program so that the interpreting mechanism can erase
the resultant operand of an assignment. begin and end
are likewise written in sequence into the translated
program so that the interpretor of this program can
maintain a list of valid identifiers corresponding to the
program's nested block structure.
The translator of Figure 2 is thus a relatively
straightforward extension of the PDA in Figure 1, with
787
the additional structure arising from the appropriate
rules of translation. The sequencing of operators to
follow pairs of operands is accomplished by noting that
state transitions such as the one that recognizes the
sequence
(simple expr>
+
(term)
in Figure 1 are· appropriate points for writing out
operators (here, "add':;) into the translated program.
Likewise, a rule of translation such as
numberoperand (number)
requires some temporary storage in the translator to
store the symbols that comprise (number), finally
writing out the translated sequence
Code ('numberoperand')
Code (temporarystore).
To So
j-j+1
Nj-S j
j-"+I
INITIALIZATION
i-temp-O
Ni #
j-I
i-i+1
Ni-S j
j-j+1
!!!!.
ft. c
i-i+1
Nj-Sj
j-j+1
(vao
~
temp -
Sj +loxt8mJ,
j-j+1
S
Code C'variableoperand)
CodeCSj )
j-j+1
S" -?
other
other
Figure 2-The BCA tra.nsla.tor of L(G')
788
Spring Joint Computer Conference, 1969
Deterministic and extended-deterministic acceptors
An acceptor A is called deterministic if M is a partial
mapping from
NxQxT into NxNx{So}x(T U {eD
U (N U {e}) x Q x (T U {e}) - {e} x Q x {e}.
This is equivalent to saying that, for every configuration
C of A there is at most one configuration C2 for which
C: 1- C'/.. By an induction argument, if x is in L(A),
there is only one sequence of configurations by which
( # SoX #) I': ( # F # ). Thus, if A were constructed from
some grammar G, there wouid exist exactiy one
leftmost parse for each x in L(G), and G would be
unambiguous. However, it is fairly easy to construct
languages that are unambiguous and for which no
deterministic BCA can be constructed.13
Since not every unambiguous grammar leads to a
deterministic BCA, it is of interest to consider methods
for extending the BCA model to handle a larger class
of unambiguous languages in some "almost deterministic" fashion. This is important because any nondeterministic automaton is inefficient to use, owing to
t he necessity of repeating its computations until the
correct sequences of configurations are found. This
necessity for backtracking during computations of such
an automaton A 'with input string x in LeA) occurs
when a configuration C1 is reached for which
and
n ~ 2.
Since we assume that L(A) is unambiguous, there can
exist only one C li above for which C li I.:!... (# F # ). The
problem then becomes one of finding a general algorithm
for processing each of t.he n possibilit.ies 9obove; toget.heT
with their descendents, in some parallel f~hion, perhaps
similar to the methods used for "real-time" languages.4 ,1l
The algorithm that we present here for implementing
parallel computations of nondeterministic BCA's involves a basic computational strategy: No matter how
many alternative configurations exist at some step in a
computation, all the configurations must have the same
input-string symbol in common. Thus, simulation of a
parallel computation having no more than n configurations active requires only one input string and n
pushdown stores. Moreover, the number of these stacks
in use can shrink and grow during a computation, as
possible configurations are rejected or added. As will
become apparent, at most p stacks will ever be in use at
once, where p is the number of states in the original
BCA. In what follows, it will also be apparent that
there is no "communication" between the stacks; i.e.,
the extended BCA that results is still equivalent in
computational power to the BCA from which it
originated.
.
Given an iriitially nondeterministic acceptor A, the
algorithm constructs sets of states from A, and extends
the transition table ::.\1 to include transitions between
these sets of states. Transitions are also defined between
individual states of A and sets of states, and between sets
of states and individual states. In these transitions
involving sets of states, each state in a set is associated
with a single stack, and the number of stacks in operation during a computation increases or decreases
depending on the relative sizes of the sets between which
transitions occur.
The algorithm for constructing sets of states operates
in two phases: In the first phase, sets of states Sii are
constructed from individual states S i of the original
acceptor. These constructed sets have the property that,
for a given context (Kr-z, as), each state in Sij corresponds to one of the configurations that can result
from a configuration containing state Si. In the second
phase, the sets of states Sii from the first phase are used
to construct further sets of states Siik. These sets have
the property that, for a given context (K', as), each
state in Sijk appears in a configuration derivable from
some state in Sij.
There are two cases in each phase of the extension
algorithm, corresponding to the erasure or non-erasure
of an input-string symbol by the configurations active
in some step of a computation. The extension algorithm
acts so as to force the state-set transitions of an acceptor
to proceed by first erasing as many pushdown-store
symbols as can be erased before all states in the set that
results are ready to erase an input-string symbol.
Hence, on transitions from a set of states in which, for
some context, at least one state in the set erases a sta~k
symbol, the remaining states that take part in the
transition are "inactive." These inactive states present
in a transition are carried along from one transition to
the next until a configuration is reached in which all
states in that state set can read the input-string symbol
simultaneously. The formalism of the extension algorithm
in the following section merely implement.s these ideas,
and provides a method of determining whether, for a
given BCA, this extension algorithm is adequate to
prevent the necessity of backtracking.
1t1ultiple configurations
A muUiple configuration C' of some acceptor A is a
triple
where the v;. are in N*, SG is in (P(Q) -Q) (P(Q) is the
set of subsets of Q), w is in T*, and the number of states
in S8 is m.
Given a BCA, let 1- be the relation on
II. Let C] = «VIKl, ... , vtKt)Sa lVI(Ki' ak, d)]}
Then, Cll = «ViI Y~"1, ... , ViiY ii, V k1Kkl, ... ,
Vk1lKkn)SBdw)
and Ci 1- Cll . We say that
M(K, 81, a) = «Yl, ... , Ym), Se, a).
(b) Let
Se = {Ci: [(Yi, Ci, e) E M(K, SI, a)]
& [Yi E {K}x(N U {e})]}
Then,
C2 = «VYl, ... , VYm)ScW)
and
Cd- C2.
We say that
M(K, SI, a) = «Yl, ... , Ym), Se, e).
(b) Let SB = {B,: ~ai) [(ai E Sa) & [(y i, B" e)
E M(K" a;, d)]
.
& [y, E {K,}x(N U {e})]] &
~ (~ak) [(ak ESa)
& [({K,} U {e})x(N U {eD xQx{d} :::>
M(K" ak, d)]}
Then, C~ = «vuY."1, ... , ViPYip)SBW)
and Ci 1- C2. We say that
M«Kl, ... , K t), Sa, d) = «Y."1, ... , Y,p)-, SB, e)
790
Spring Joint Computer Conference, 1969
Note here that SB in one of the transitions above could
be a set consisting of one or more states. When SB is a
set consisting of one state, then the transition defined
from S to SB has gotten rid of the alternative configurations represented by Sa and its contexts.
We see that the transitions constructed above from a
single configuration to a multiple configuration and from
one multiple configuration to another preserve the
actions that would be taken by the original BCA. In
particular, the one successful reduction sequence of a
BCA over a string ·x is contained in the extended
reduction sequence involving multiple configurations. 13
The extra stacks used during a multiple configuration
reduction sequence simply keep track of additional
possibilities until all but one sequence of configurations
is eliminated.
In part I of the extension algorithm, the transitions
are not uniquely defined for those BCA's in which, for a
state s and context (K, a), the following two conditions
apply for the same context (K, a):
multiple configurations. We say that C1 /.!-. Cm when
there exists a sequence of (possibly multiple) configurations (C1, ••• , Cm) such that
Ck - 1
For this transition, 1- is not uniquely defined, since
there is no longer a one-to-one correspondence of
pushdown-store strings and states of S", In such a case,
more than one reduction sequence may exist for a string
in the acceptor's language. When these two degenerate
conditions arise during the extension of a BCA, it is
instructive to rewrite that BCA as a rightmost parsing
algorithm to see whether the same degenerate conditions arise when parsing strings of that language from
right to left.
We can next define the language accepted by a BCA
in terms of a computation involving sequences of
Ck
for k = 2, ... , ill
.
The language of an acceptor A which is extended to
handle multiple configurations is then given by
L(A) = {x: (x E T* - {e}) &
[[(j~SoX~)
I.!-.
(~F~)
& (SF E P(Q) - Q) & (~qi) [(qi E SF)
& (q i = F) & (V i = ~)]] }
With these preliminaries in mind, we can state the
following theorems that are proved in (13).
Theorem 1 Let P be a BCA for which 1- is uniquely
defined for multiple configurations. Let
[(K Ute}) x (N Ute}) xQx {a} ::> lVI(K, s, a)]
& [{K}x(N U {e}) xQx {e} ::> M(K, s, a)]
When these conditions occur simultaneously, the necessity of simultaneously erasing and not erasing the same
input-string symbol during a transition is incompatible
with our parallel-processing algorithm. It may be
possible to use "lookahead" techniques to decide which
of the two types of transitions above should take place
by scanning further symbols of the input tape. The use
of these lookahead techniques to improve the extension
algorithm will be discussed in another paper.
The remaining condition that leads to difficulties in
the algorithm arises when there exists a state g in some
multiple configuration S", such that g is immediately
descended from two or more states y iI, •.• Y i" in some
81/ for which
.
I~
P' = (Q', T, N ' , M ' ,
~,So,
F)
with Q' c P(Q), N' c N U Nx ... xN, and lVI' the
original :V1 of P together with the transitions defined on
multiple configurations.
Then,
L(P) = L(P') .
That this is so follows from the observation that, for /uniquely defined on multiple configurations of P, all
computations of P over some input st.ring x in L(P) are
contained in a single computation of P' over x. Conversely, no computation of P' over some input string y
will succeed unless y is in L(P).
Theorem 2 Let P be a BCA constructed from grammar
G having multiple configurations for which 1- is
uniquely defined. Then L(G) is unambiguous.
That this is so arises from the fact that the conditions
for uniqueness of 1- also insure uniqueness of leftmost
parses in L(G).
Upper bounds on storage and computation times
This concluding section contains a fairly elementary
proof of the fact that BCA's can accept their languages
in time directly proportional to the length of their input
strings (or programs to be translated). Our reason for
including this proof is to emphasize the need for a basis
of comparison between different compiler-writing systems. Thus, if compiler-writing system A can produce a
single-scan FORTRAN compiler whose translation
Systems for Designing Fast Programming Language Translators
speed is bounded by n 2 (with n the length of an input
program), and compiler-writing system B claims a speed
of, say, n log(n), it would seem fairly obvious that
system 0, with speed 3n, would be the economic choice
for a fast, single-scan compiler system. Again, if there
are limitations on computer memory size available for
the compiler, and if the compiler is to run in a "load and
go" or, possibly, a "reentrant" mode, it is desirable to
pick a compiler-writing system that uses as little "core"
as possibie.
The actual size of one of our compilers is determined
by the number of rules in the grammar of its language
and, also, by the length of these rules. Roughly speaking,
the number of "states" of a compiler is less than or
equal to the number of rules in its normal-form grammar
of the types
The number of comparisons necessary to specify a
transition away from one state is bounded by the
number of contexts that can determine a transition from
that state. Thus, the size of the compiler: program is
related to the number of rules used in the language and
to their lengths.
We can speak more quantitatively about the amount
of space required for the pushdown store of a deterministic BOA. Let x = al ... an be an input string to some
BOA, and let y = ~ Kl ... Km represent the string of
symbols on the pushdown store at some point during a
computation. Then, after symbol ak(k = 1, ... , n),
is "erased" by the BOA,
m~k+1.
This is so because, by our definition of a BOA constructed from a grammar G:
(a) For each input symbol erased, the stack can
increase in length by at most one symbol.
(b) For each stack symbol erased, at most one
symbol can take its place.
Hence, there are never more than (n + 1) symbols on
the stack, where n is the length of the input string. In
the case of an extended BOA with multiple-state
configurations, there can never be more than k stacks
active at once, where k is the number of states in the
original BOA. For such a BOA, then, there is an upper
bound of k(n
1) symbols stored on stacks during a
computation.
In order to derive an upper bound for computation
time of a BOA, we must first discover an upper bound
on the number of actions that can be taken by a BOA
+
791
without erasing an input-string symbol during a computation. Let p be the number of rules in the grammar for
a BOA such that the rules form a chain
i = 2, ... , p,
such that all rules of the chain have at least one context
in common, and such that p denotes the length of the
longest chain of rules of this sort in the grammar. Then,
·without the erasure of a symbol from the pushdown
store and the input string, at most p state transitions
can occur.
If ~ symbols are on the pushdown store after input
string symbol ak has been erased, at most
(1
+ ~)(1 + p)
state transitions can occur when erasure of stack
symbols is allowed before symbol ak+1 is erased. However, if only Wk symbols are removed from the stack,
then at most
(1 + wk)(1 + p)
, Wk
= 0, 1, ... , p
state transitions can take place before ak+l is erased.
Next, we can ask what total number of symbols can
be erased from the stack during any computation, i.e.,
what is the maximum value of
To answer this question, we note again that our BOA
model only allows a new stack symbol to be written as a
result of the erasure of an input-string symbol. Since,
for an input string of length n, no more than n symbols
can be written on the stack, no more than n symbols can
be extracted from the stack during any computation.
Thus,
Finally, we can arrive at an upper bound for the
number of configurations that can appear during the
computation of a deterministic BOA over a string x
of length n:
MAX ::; (n + 1) + (p + 1) (WI + ... + Wn + n)
or MAX
~
n(2p + 3) + 1
We know also that
MAX~n+l,
792
Spring Joint Computer Conference, 1969
where this lower bound is reached when the BCA of
some grammar has an empiy pushdown-store vocabulary; i.e., is a finite-state acceptor. Hence,
n
+1~
MAX ~ n(2p
+ 3) + 1
The upper bound on the number of configurations
during a computation also holds for extended BCA's
having multiple-state configurations. This is because
the computations of the nondeterministic BCA from
which the extended BCA was constructed are all
included in the computations of that extended acceptor.
ACKNOWLEDGMENTS
The author expresses his sincere gratitude to Dr.
IVIichael Ha.u~son for his thoughtful criticisms and
suggestions on the subject of this paper. The research
for this paper was supported in part by N.A.S.A. grant
N sG-398 to the Computer Science Center of the
University of Maryland.
REFERENCES
1 J EICKEL M PAUL F L BAUER K SAMELSON
A 8yntax-wntrolled generator of formal language proce880r8
Comm ACM 6 August 1963 451-455
2 R W FLOYD
Syntactic analy.~~ and operator preced.eru:.e
JACM 10 July 1963 316-333
3 S GINSBERG S GREIBACH M HARRISO~
Stack automata and compiling
JACM 14 January 1967 172-201
4 S GINSBURG
M HARRISON
One-way nondeterministic real-time lisi-8torage languages
JACM 15 July 1968 428-446
5 S GINSBURG
The Mathematical Theory of Context-Free Languages 1966
. 6 S GREIBACH
Inverses of phrase structure generators
Doctoral Dissertation Harvard University 1963
7 L H HAINES
Generation and recognition of formal languages
Doctoral Dis...<:ertation MIT 1965
8 E T IRONS
A syntax-directed compiler for ALGOL 60
Comm ACM 4 January 1961 51-55
9 D E KNUTH
On the translation of languages from left to right
Information and Control 8 December 1965607--639
10 P M LEWIS II R E STEARNS
Syntax-directed transduction
JACM 15 July 1968 465-488
11 C PAIR
Arbres, piles et compilation
Rev. Francaise Trait Inf 7 1964 199-216
12 A ROSENBERG
On the independence of real-time definability and certaiu
structural properties of context-free languages
JACM 15 October 1968 672--679
13 V B SCHNEIDER
The design of proce8sors for context-free languages
~ational Science Foundation Memorandum ~orthwestern
University August 1965
14 V B SCHNEIDER
Pushdown-store processors of context-free languages
Doctoral Dissertation Northwestern University 1966
15 V B SCHNEIDER
Syntax checking and parsing of context-free languages
by pushdown-store automata
Proc S J C C 1967
16 V B SCHNEIDER
A fast translator system for the EULER programming
language
Computer Science Center Technical Report University
of Maryland 1969
17 N WIRTH H WEBER
EULER: A generalization of ALGOL and its formal
definition: parts I and II
CACM 3 January-February 1966 13-25 and 89-99
Generating parsers for BNF grammars *
by FRANKLIN L. DEREMER
M assachusetls Institute oj Technology
Cambridge, Massachusetts
INTRODUCTION
The procedure described herein is in essence an extension, albeit a simplification, of the work Earley! which
in turn was based on Evans,2 Feldman, 3 Floyd,4.5 and
Standish.6 For a large subset of grammars, the procedure maps the Backus N aur Form (BNF) definition
of the grammar of a language into a deterministic left.
'
to-rIght parser for the sentences in that language. It is
shown below that the procedure by design, covers all
bounded right context gramm.ars and, as a by-product,
some LR(k) grammars which are not bounded right context. See Knuth7 for the definitions of these classes of
grammars. If two parameters are incorporated a priori
into the procedure, one limiting the look-back and the
other limiting the look-ahead capabilities of the parser
to be generated, an algorithm results. For each BNF
grammar G the algorithm either rejects G as not bounded right context for the specified limits or it generates a
parser for G.
More precisely, the algorithm maps a set of BNF
productions into a program: a "reductions analysis"
programt consisting of modified Floyd productions,
really reductions, referred to below as FPL (Floyd Production Language) statments. ** The program consists
of labeled, mutually exclusive groups of statements
called sections. Each section has a specific task to per• T~ work was supported in part by the Department of Computer SCIence, University of Illinois, Urbana, Illinois, and in part
by the Advanced Research Projects Agency as administered by
the Rome Air Development Center, under Contract No. US
AF 30(602)4144.
t It is assumed that the reader is familiar with reductions analysis
pro~rams and the associated stack. input string, and manipulatIOns thereupon. See Cheatham. s
** This nomenclature is adapted to clarify the distinction
between the BNF productions, which together define the granunar
of a language, and the FPL statements which, when combined to
form a program, describe a parser.
form. It is activated, by transfer of control to its first
statement :ria t.he ~ab~l, only at appropriate times. Upon each actIVatIOn It eIther scans a new terminal symbol
or makes a reduction (combined with an "unscan" in
the case of a production with an empty right part) and
then transfers control to the appropriate next section
or it transfers control to an ERROR routine if controi
falls out the bottom of the section.
The algorithm is based on Earley'S intuitive notion
that the top symbols on the stack matched against the
right parts of certain productions should determine
parsing decisions. It is an extension of his algorithm
in that it provides for both finite look-ahead and finite
l?ok-back and in that it covers productions with empty
rIght parts. It is a simplification of his algorithm in that
it allows reductions only at the top of the stack, therefore reducing the number of mapping rules.
A word about notation is in order before proceeding.
In this paper, non-terminal symbols are represented by
Latin capitals, terminals by lower case Latin letters,
arbitrary strings by the Greek letter O!, and the empty
string by the Greek E. The Greek letter (]' designates a
symbol which matches any other symbol.
The algorithm
The algorithm simply consists of: (a) three rules to
determine what sections are necessary for the program,
(b) three rules to determine which productions should
be mapped into statements for each section, (c) four
rules to map the productions into statements, (d) a
rule which prescribes the combination of some statements in a given section and a corresponding com~
bination of certain' sections, and (e) a contextual
analysis rule for expanding statements so no two statements in a given section are both applicable to a given
stack and input string configuration. The latter oper:.tion is referred to below as making the statements
793
794
Spring Joint Computer Conference, 1969
disjoint. There are also several rules for optimizations,
some of which are given toward the end of the paper.
a. Necessary Sections. A special START section
and a special sect.ion for SUCCESS EXIT are
required together with the following;
1. A section labeled Nh is required for each
non-terminal N which appears in the right
part of some production as other than the
first symbol. This section is activated whenever one of the terminals, which may begin
N, is supposed to be at the top of the stack.
I t is the purpose of section Nh to verify
that one of these terminal "head symbols"
is indeed at the top and, depending upon
which terminal is there, to take appropriate
action to commence, and perphaps conclude,
a reduction to N.
2. A section labeled t (11", p) is required for each
occurrence of a terminal as the p-th symbol
in the right part of each production 11", where
where p ~ 2. This section consists of exactly one statement which compares the
first p symbols of production 11" with the top
p symbols of the stack. It is activated only
when the match must occur for a wellformed string. Its purpose is to verify the
top 8)'lnbo1 and to take appropriate action
to continue the parse.
3. A section labeled Nt is required for each
non-terminal N which appears in the right
part of some production. The section is
activated immediately after a reduction to
N occurs at the top of the stack. The statements in this section indicate comparisons
t.o t.he stack to determine which of the pro~
ductions in whose right part N appears is
applicable to the case at hand. A match
determines the appropriate subsequent action.
b. Descriptor Sets. In order to generate the appropriate set of statements for a given section, a
descriptor set of pairs D = ( (11"1, PI), ... ) is associated with each section label. This descriptor
set serves to indicate to which part of which
productions the mapping rules described below
are to be applied. The pair (11", p) points to the
first p symbols of production 11" as the stack comparison symbols of the corresponding statement.
The descriptor sets are determined as follows:
1.
D Nh : Initially DNh is empty and the following recursive procedure is applied. The
right part of each production 11" that defines
N is examined. If it is empty, then (11", 0)
is added to D Nh ; if it begins with a terminal,
then (11"; 1) is added to D Nh; otherwise it begins with a non-terminal and the procedure
is applied to that non-terminal.
2. D ter • p) contains exactly one pair (11", p).
3. D Nt : The right part of each production 11" is
examined. If the non-terminal N appears as
the p-th symbol, then (11", p) is in D Nt •
c. The BNF to FPL Mapping Rules. Presented in
Table I are four rules for mapping BNF productions into FPL statements. Together with
the descriptor sets they represent a naive first
try at generating a parser for the grammar. Implicitly, the rules assume there is no question about
which production applies to the case at hand but
only what action is to be taken by the parser
next, given that a certain production is applicable. It is the purpose of the last two rules of the
algorithm to extend it to cover a reasonable set
of grammars by resolving confusion about which
productions may apply to different cases within
a given section.
Table I
The BNF to FPL mapping rules.
a represent:s the first !'
symbols of production 11, a is a SYMbol which matches any other
symbol, and q - p + 1.
BNF Production (11. e)
(1)
M ::- aN •••
(2)
H ::-
(3)
M ::-
(4)
M ::- £
ab
a
•••
FPL Statement
Maes Into
->
->
->
al
al
al
0'1
*
*
.
..
Nh
t(1I, q)
MI
Mt
Mia
Mt
The rules of Table I are explained intuitively
as follows. If the first p symbols of the right
part of production 11" are at the top of the stack and
1. if the (p + 1)st symbol is a non-terminal N,
then the parser should scan (*) the next
terminal and activate section Nh to begin
to reduce a substring to N.
:2. if the (p + l)st symbol is a terminal b, then
the parser should scan the next terminal
and activate section t(1I", q), where q =
p + 1, to verify that that terminal is indeed
Generating Parsers for BNF Grammars
b and to decide how to continue the parse.
3. if the p-th symbol is last in the right part of
the production, then the parser should make
a reduction (~) to the symbol M of the
left part of the production and activate
section Mt to decide how to continue the
parse.
4. if p = 0 and therefore the right part of the
production is empty, then the parser should
"unscan" the top symbol, push an M onto
the top of the stack, and activate section
Mt to decide how to continue the parse. The
symbol unscanned will be a terminal since
this statement will appear only in an Khtype section, the activation of which is always immediately preceded by a scan
(see rule (1)).
d. Combinations. In general, a reductions analysis
program generated according to the above rules
will contain sections in which some of the statements are not disjoint. That is, the conflicting
statements will indicate stack comparisons (1)
which are identical, or (2) the shorter of which
are identical to the top few symbols of the longer
ones. Thus, several statements may be applicable
to a single stack and input string configuration,
and the parser is in some sense non-deterministic.
To render the parser deterministic it must be
modified so it can either delay or determine the
decisions concerning which of the several similar
productions associated with the conflicting
statements is applicable in various cases. Decision delays are effected by pairwise statement
combinations as follows.
If two statements in a given section are not
disjoint and if each was generated according
to either mapping rule (1) or (2), then they are
replaced with a single statement: one whose
stack comparison is the shorter of the two and
which, upon a successful stack match, scans a
new terminal and activates a new combination Section which must be added to the program." The new section is that section whose
descriptor set is the union of the two descriptor sets of the sections which the original,
statements would have activated. Of course
the statements in the new section must be
checked for disjointness. The old sections, of
which the new one is a combination, should
be checked for usefulness, since the only
reference in the entire program to one or both
might have been deleted by removal of the two
statements.
795
e. Expansion by Contextual Analysis. The only
decisions which cannot be delayed are those
concerning reductions. This limitation is due
to the requirement that reductions be made
only at the top of the stack. Thus, conflicts with
statements generated according to mapping
rules (3) and (4) cannot be resolved by combination. In this case the statements' comparison
fields are expanded by contextual analysis to
provide the parser with whatever finite lookahead and look~back are necessary to make the
decision at hand; i.e.,
for each of the conflicting statements the
grammar is investigated and generation is
begun of the strings of symbols which, in the
context of the production associated with the
statement, may surround the original stack
comparison substring a of the statement.
Appropriate comparison of the composite
strings associated with each of the original
statements, indicates the minimum context
which must be checked to make the statements disjoint. In the worst case each statement must be replaced with several statements which differ from the original in that
they indicate more symbols which must be
matched in the stack and/or the input string.
Examples
Since the parser proceeds from left to right, always
making reductions at the top of the stack on the basis
of whatever finite look-ahead and look-back are necessary, the procedure by definition covers all bounded
right context grammars. Further, due to the fact the
sections of the program themselves imply certain extra
information about the stack configuration, in the same
sense that a state of a finite state acceptor implies information about the string read, the algorithm also
covers some LR(k) grammars which are not bounded
right context. An example grammar in this class is
S :: = aA I bB, A :: = cA I d, B :: = cB I d, the
sentences of which are a cn d and b cn d. This grammar
is not bounded right context since the clue as to whether
to reduce d to A or B is an a or b arbitrarily far down
the stack. The grammar is however, LR(O) and can be
parsed by the algorithmically generated parser of Figure 1. In both Figures 1 and 2 a transfer of control to
an ERROR routine is implicit at the bottom of each
section in case no match occurs.
As an example of a grammar requiring both lookahead and look-back consider the following LR (2)
grammar.
796
Spring Joint Computer Conference, 1969
al
hi
*
*
Ah
Ah
<:1
*
Ah
-+
Bh
dl
cl
dl
-+
BI
Bt
cAl
-+
AI,
At:
aAl
-+
sl
St
cBI
-+
Bj
Bt
bBI
~
sl
St
START (Sh)
At.
Bt
The confusion is between case (2) of production five
and case (2) of production three. One possible solution
is to construct the following Gt section:
Bh
AI
n.+
'-AU
I
daG xe
At
aGI
SUCCESS EXIT
St
Figure I-Algorithmically generated parser for a grammar
which is LR(O) hut not bounded right context
P
123
2 S
..
....
= dA
3 A
....
=
4 B
..
= xe
5 G
..t.
6 G
..
- cAB
aG
=
Gx
==
X
Confusion arises in the Gt section about when to
tenninate the gathering of x's into the non-tenninal G.
Generation of the context related to production five
produces three possible strings for two-symbol lookahead:
(1)
(2)
(3)
I ~ G I x ~ G I xx
G I ~ G I x ~ aG I x ~ daG I xe
G I ~ G I x ~ aG I x ~ caG I xB
G
I
Dt
DI;r
There are two possible strings for production three:
bDI
(2)
I
I
aG 1-7 caG I B ~ caG I xe
aG ~ daG e
t(a, 2)
~AI
At
t(5, 2)
Note that advantage has been taken of the sequential
nature of the program here. Since the first two statements will catch all configurations to which production
five is applicable, the statement as...c;:ociated with production three checks no extra context. That is, the restriction that the statements in a given section must be disjoLnt may be relaxed in special cases where advantage
is taken of the order in which statements are executed,
however the contextual analysis must still be performed
to ascertain the validity of such an optimization.
Finally, note that had production five been G :: = xG
the grammar would not have been bounded right context nor covered by this algorithmJ although it would
still be LR(2).
As a final, larger, and more practical example consider the grammar of Table II, which is Earley's example of a simple algebraic language. The corresponding
list of necessary sections and their descriptor sets are
presented in Table III, and the parser is given in Figure
2. This grammar requires no special look-back and lookahead of more than one symbol in. only one case, section
Dt. A single pair of statements was combined in section
Ht causing the combination of sections t (1, 2) and
t (4, 2) to form a section labeled t (1, 2; 4,2). Note that
such combinations are probably most efficiently effected
by operations on the descriptor sets before the sections
are generated. Also note that maximum advantage was
taken of ordering the statements.
For expositional purposes several optimizations were
not made: (1) since the first p-1 symbols are matched
immediately prior td its activation, a t(7r, p) section
need match only the p-th symbol with the top symbol
of the stack, (2) since a reduction to N occurs inunediately prior to the activation of an Nt section, it need
not match the top symbol, (3) many sections could
have been "concatenated" to reduce transfers and
multiple interrogations, as for example sections Dt
t (6,2), and t (6, 3) which would form
~caG xxe
(1)
*
*
Bh
*
1 S
G II xx
Lh
***
HII
Ht
(4) since sections Ph, Fh, and Th are identical, and are
subset of section Eh, all these could have been com-
a,
Generating Parsers for BNF Grammars
S TAR T (t
h)
~I
*
Bh
blr
*
Dh
bl
+
rl
*
11
+
Bh
Dh
Lh
'1' h
1i
+
(I
*
h
±I
S h
11
1
B
::-
H
e
2
H
::-
b
3
H
: :-
b
4
H
::-
H
5
D
: :-
r
6
D
::-
D
7
L
: :-
i
8
L
::-
L
9
S
: :-
i
and the
Corresponding Descriptor Sets for the Grammar of Table II
1
S~eticn~
4
D
S
L
r
L
1
+
E
START 0: h)
0,1
Bh
2,1
Dh
5,1
Lh
i,l
Th
17,1
18,1
Eh
11.1
17,1
Sh
9,1
Fh
17,1
18,1
P h
17,1
18,1
t (1,2)
t (4,2)
10
E
::-
T
11
E
::-
±
T
12
E
: :-
I
±
13
T
: :-
F
14
T
: :-
T
15
F
: :-
P
16
F
::-
F
17
P
::-
i
18
P
: :-
DESCRIPTOR SETS
NECESSARY SECTIONS
}
3,1
18,1
combined to form t (1,2; 4,2)
t (6,2)
!!Q!!:
t (8,2)
T
t (12,2)
*
F
t (14,2)
t (16,2)
+
P
t (0,3)
t (6,3)
t (8,3)
E
1 1s 1dencifier
r 1s
t (9,2)
!!!!
t (18,3)
Ht
1,1
4,1
Dt
6,1
3,2
L t
8.1
5.2
6,4
T c
10,1
14,1
11,2
E t
12,1
18,2
9,3
F c
13,1
16,1
14,3
p c
15,1
16,3
B t
0,2
S t
4,3
b is begin
e is~
If the third optimization is applied, the first and last
of the tenus in this sum can be reduced. Of course, the
coefficient of the first term cannot be less than one a~d
the second and third terms cannot be reduced. Clearly,
the algorithm with optimizations generates a practical
parser for this special case.
(cOlllbination)
r
t
12,3
Generatil1g Parsers for BNF Grammars
CONCLUSION
Hand simulation of the algorithm for grammars of up
to eighty-five productions indicates that results comparable to the above can be expected for typical programming languages. For instance, gramm.ars which
are "mostly" simple or operator-precedence produce
parsers which operate in times comparable to the above
and whose sizes are proportional to the size of the grammar (about two to four tL-rnes as !p~ny FPL statements
as BNF productions).
A modified version of the algorithm has been implemented as part of a translator writing system for the
ILLIAC IV computer at the University of Illinois. The
system and the modifications to the algorithm are described in detail in Beals.9 A preliminary result is a
recognizer generated for an ALGOL-like language about
one quarter the size of ALGOL which processes 850
cards per minute. This device goes through the motions
of lexical analysis and parsing, but it drives only enough
semantic routines to check scopes of variables, types,
etc.
Although a proof has not been given, it seems intuitively reasonable that the algorithm generates correct parsers. The author believes that the methods of
Evans could, without extreme difficulty, be utilized to
provide such a proof.
also due Dr. R. S. :x orthcote for suggested lIDprovements in the paper itself.
REFERENCES
J EARLEY
2
:3
4
5
6
7
8
ACKNOWLEDGMENT
The author would like to thank Alan J. Beals for his help
in evaluating and debugging the algorithm. Thanks are
i99
9
Generating a recognizer for a BNF agrmmar
Carnegie-Mellon Institute of Technology 1965 upnublished
A EVANS
Synt.ax analyS'is by produ.ction langu.age
Doctoral Thesis Carnegie-Mellon Institute of Technology
1965
J FELDMAX
A formal semantics for computer-oriented languages
Doctoral Thesis Carnegie Mellon Institute of Technology
1964
R FLOYD
A descriptive language for symbol manipulation
J A C M Vol 8 No 4 579-584 1961
R FLOYD
Bounded context syntactic analysis
C A C M Vol 7 No 2 62-67 1964
T STANDISH
Generating productions from a restricted class of BNF
grammars
Carnegie-Mellon Institute of Technology Computation
Center unpublished
D KNUTH
On the translation of languages from left to right
Information and Control Vol 8 607-639 1965
T CHEATHAM
The theory and construction of compilers
Massachusetts Computers Associates Inc 1967
A BEALS
The generation of a deterministic parsing algorithm
ILLIAC IV Document No 304 University of Illinois 1969
An extended BNF for specifying
the syntax of declarations
by GORDON WHITNEY
Weatern Electric Engineering Research Center
Princeton, New Jersey
"1 recammend the use of suitable special metalanguages as a part of the defining
repurts. The Backus rwtation is probably as good as anything we have at present, but it
stiU leaves a great deal to be desired ... many syntactic rules cannot be expressed in it.
The language reporter should ... invent and U8e such tools wherever the special metalanguage i8 easier to work with than natural language." Peter Naur,l 1963.
INTRODUCTION
The syntax of ALGOL is specified in its defining report2
by a grammars whose rules are given in Backus-Naur
Form (BNF). Because of the need for precision in the
specification of complex systems, BNF has been used to
record the syntax of many other programming languages. The rules of BNF are equivalent to context-free"
production rules. However, due to its declarations,
ALGOL is context· dependent, and its syntax cannot be
fully specified by a grammar limited to context-free
rules. 6 Other grammars for ALGOL6,7.8 are more compact than the BNF of the defining report, but they are
generatively no more powerful. Because of this contextdependency of declarations, even an assembly language
cannot be fully specified in BNF.
This paper defines an extension to BNF which permits
the specification of the syntax of declarations, while
retaining the definitional power of BNF as a subset.
PL/I has been formally defined9 by specifying a model
which will execute programs written in the language.
This model specifies the semantics of the language but
does not include a grammar for the syntax of declarations. Recent paperslO.1l.12,18 define systems capable of
specifying the syntax of declarations. This paper is an
extension and exposition of one of these models* (called
• The table-grammar presented here is similar but not identical
to a previous model.!1 The differences are as follows:
1. The table-functions using Greek letters as function names
have been changed to expression format using operators
"table-grammar") in the hope that language reporters
and implementors will be able to utilize the model in
practical work with programming languages. Consistent
with this purpose, a system of notation has been adopted
(with an attendant loss of compactness) which is both
compatible with BNF and oriented for the human
reader of the syntax.
Table-language generation
A grammar defines a language by specifying the
means by which legal strings in the language can be
generated starting from some fixed initial configuration.
For each class of language there exists a corresponding
class of processors which can carry out the generative
process. Such a processor is called a generator. This
section will define the form of a table-grammar and the
means by which they generate strings.
with English names. Thus the T-function is' replaced by
the use of create, retrieve or recreates. The p-function becomes replaces. The II-function becomes illegal.
2. The use of two auxiliary storage tapes rather than one
gives the new model increased generative power. This
also allows BNF grammars to remain nearly intact when
table operations are added to the grammar. The table
operations copyl4hle and erasetahle are new and are necessary to allow multiple tables in a two-tape system.
3. The definition of the generation operators to perform
recognition is new, as is the operator copy and both the
definitions and the properties of "Regular Table Expressions. "
------------------------------------801----------------------------------
802
Spring Joint Computer Conference, 1969
Notation
c. The dyadic expressions are:
( . i· )recreates ( . r· ) and (. i· )replaces ( . r· ) .
Certain definitions will be used throughout. They will
not be given further local definition. These definitions
are:
a, b, c, '"
E
x,y, Z
+
Table expressions, when evaluated, have the following characteristics:
d. Successful evaluation may be subject to certain
restrictions.
e. A terminal-string is returned as the value of the
expression.
f. Side-effects may be produced in the active-table.
(The concept of active-table will be defined
below.)
terminals symbols.
a terminal-string of length zero.
terminal-strings, having an arbitrary
value, or a range of values.
this post-fix operator denotes e-free closure
for catenation, i.e., (X)+ = { ~ Xi where
i=1
Xl = X and X~+l = XiX}.
this post-fix operator denotes full closure
for catenation, i.e., (X)* = {(X)+ U E}.
this symbol denotes a string of either
letters or blanks and is called a letterstring.
*
"
1\
Definition of a table-grammar
A table-grammar is a 4-tuple:
G = (categories, terminals, static-rules,
sentence-symbol)
where:
1. The set of categories and the set of terminals are
finite and disjoint.
2. The set of categories has two disjoint subsets:
grammar-categories and table-categories.
3. The set of static-rules is finite. Each rule has the
form: (>..) :: = (grammar-category U terminal U
table-expression) * where:
a. The leftside of a rule is a grammar-category.
b. The rightside is called an arbitrary-string.
4. A table-expression consists of a generation-operator
with its respective operands. A generation-operator
has either zero, one or two operands, and is respectively referred to as a niladic, monadic or dyadic
operator. The operands for table-expressions are
table-categories whose form is <. A'), For the
presentation of table-expression schema it will be
convenient to use (. i· ) to represent an incident
table-category (i.e., one entering the table) and (. r· )
to represent a resident table-category (i.e., one
already present in the table). The following are the
schemas for the seven different forms of tableexpressions:
a. The niladic expressions are: copy table and erasetable.
b. The monadic expressions are: create ( . i· )
retrieve( . r· ) and illegal <. r· ).
,~.
The sentence-symbol is a unique grammar-category.
Concerning the evaluation of table-expressions, if the
specified conditions are not satisfied, the current
generation step is blocked and an alternate sequence of
steps must be utilized. Thus invalid programs are
eliminated at the point in the generation sequence where
an incorrect construction would have appeared.
String processing devices
A string processing device is a machine with a finite
control, with a system of one or more auxiliary tapes
providing potentially infinite storage, and with either
an input-tape or with an output-tape or with both. The
device is called deterministic if in every possible configuration it has only one possible ·move to its next
configuration. If the device has more than one possible
move, it is called nondeterministic. A device with an
input-tape is called a recognizer. A device with an input
and output tape is called a transducer. A device with
only an output-tape is called a generator. The sets
defined by a context-free grammar are exactly the sets
generated by some nondeterministic generator whose
auxiliary storage is a pushdown and whose output-tape
is one way.
If an input (or output) tape of a device is one-way
(usually this is left to right) then the device is called
on-line and its input (or output) need not be written on
a tape at all but need only be received (or transmitted)
one character at a time without the use of any local
storage.
A table-language generator
Figure 1 shows the type of device necessary to generate table-languages. The output is one way and the
output-string is not counted as a tape. In a one pass
processor, as declarations of identifiers are encountered,
they must be recorded in some form of auxiliary storage
to allow for subsequent retrieval. The table-tape stores
a sequence of declaration tables as a pushdown list of
An Extended BNF
803
be limited to those generations in which only one
table copy is present on the table-tape. A generation
sequence is a finite list of transitive steps. Each step
has the form:
f1 n1 te set of
production rules
tal;1~
pushdown-tape for
unreduced portions
of r1ghts1des of
rules
for
declarations
Figure I-A nondeterministic two-tape generator for a.
language defined by a. table-grammar
tables. The top most table is designated as the activetable. When a block structure is not required, only the
active-table will appear on the table-tape. The operation
of the table is subject to four restrictions:
1. Entries must be dynamic-rules of the form:
( ( • A' ) --+ identifier).
2.
( . A' ) is a table-category. A simple set of tablecategories would be
{ (·integer-), (-real-) (-Boolean - )l.
3. An identifier is an element from a regular set. This
means that an identifier can be recognized by a
finite automaton. A simple set would be .(letter)
( (digit» * where a3 and j49 would be identifiers.
4. The identifiers within the active-table must be
unique. The same identifier may not appear twice.
Note by way of contrast that the same tablecategory may appear many times. Thus:
«·real· )
--+
a56)( (·real· )
--+
--+
(terminal-string, arbitrary-string,
table-configuration)
where arbitrary-string represents the catenation of
unreduced rightsides of static-rules and where a tableconfiguration is one distinct arrangement of declarations out of a potentially infinite number of such
configurations designated To, T 1, T 2, • • • • In actual
sequences, the parentheses and commas may be omitted
with no loss of meaning by the use of disjoint alphabets.
The active-table is erased on the last step of a generation
sequence.
The evaluation algorithm for a step has three parts:
1. If IDI = (x, a"Y, T,), then ID2 = (xa, "Y, T,).
2. If IDI = (x, (a)"Y, T ,) and (a) :: = {3 is a static-rule
of G, then one possible value is ID2 = (x, (3"Y, T ,).
3. If IDl = (x, table-expression "Y, T i) and the tableexpression is such that given an active-table T i, the
expression returns as its value y and as a' side-effect
changes T, to T;, then IDli = (xy, "Y,'Tj).
It is now possible to give a precise definition of a
table-language.
Definition of a table-language
j4)
is a valid table; while
( ( . real· ) --+ a56) ( ( . integer' )
where ID stands for instantaneous description and
where ==> indicates the rewriting of IDl in accordance
with an evaluation algorithm to produce (Le., generate)
ID2• An instantaneous description is a triple of the form:
a56)
is not a valid table.
An identifier is said to be declared if it appears in the
active-table, otherwise it is undeclared. Each new
declaration which is added to the active-table must
contain an identifier which is undeclared.
Table-grammar generation sequences
The operator copytable is explained in the section
"Table operators for embedded blocks". When this
operator is not used in a grammar, only a single table
copy will appear on the table-tape. The description of
generation sequences for this portion of the paper will
A table-language is a set of strings generated by a
function L having two arguments:
L(G, R)
= {x where G is a table-grammar and R is
a regular set, and where (E, sentencesymbol, To) ~ x, using the staticrules of G and using R as an
identifier set, and where ~ is the
transitive closure of ==> }.
Formal properties
Table-languages can be defined by means of a number
of alternative models. The formal properties listed below
pertain only to the model defined above with a unified
identifier set and where the identifiers in the table are
isomorphic to the terminal identifiers:
804
Spring Joint Computer Conference, 1969
1. The languages are properly contained in the contextsensitive languages.
2. The languages properly contain the context-free
languages.
3. The languages are closed under *, homomorphism,
and intersection with a regular set.
4. The languages are not closed under union, catenation, or inverse homomorphism.
Compound rules
The static-rule schemas given above can be called
simple. BNF uses a rule schema which will be called
compuund. If (a) :: = fJ and (a) :: = 'Yare rules in a
grammar then they can be replaced by the single
compound rule (a) :: = fJ\-r. Compound rules will be
used where convenient. They are generatively no more
powerful than simple rules.
1. The evaluation is blocked if the specified resident
category (. r· ) does not appear in the active-table.
2. The identifier in the selected dynamic rule is returned
as the value.
3. There are no side-effects in the active-table.
In summary, the expression retrieve ( . r· ) when evaluated
selects a dynamic rule whose leftside is (. r· ) and places
in the output-string the identifier appearing on the
rightside of the selected rule.
Examples of context-sensitive table-1anguages
The context-sensitive set with strings of the form
wIdwlI where WI = W2 and where WI and W2 are in the set
(0 U 1)+ can be generated by the table-grammar:
(a) :: = create (. b· ) (c)
(c) :: = d retrieve (. b· )
Table entry and access
Two basic table operations are the recording and the
retrieval of a declaration. These operations are achieved
by the expressions create ( . i·) and retrieve ( . r· )
respectively, where (. i· ) stands for an incident tablecategory (Le., one entering the table) and (·r· ) stands
for a resident table-category (Le., one already present in
the table).
Table-entry
The operator create is employed to specify the syntax
of the declaration of an identifier. The expression create
<. i· ), when evaluated, has the following characteristics:
1. The evaluation cannot be blocked if any additional
undeclared identifiers exist.
2. The selected-identifier must be undeclared and is
returned as the value which replaces the invoking
expression within the intermediate-string of the
generation sequence. (This will· be made more
explicit in the sequel by examples.)
3. The dynamic rule, (. i· ) ~ selected-identifier, is
added to the top of the active-table.
In summary, the expression create ( . i· ) when evaluated
selects an undeclared identifier, places it in the outputstring and adds to the active-table the indicated
declaration.
Table-aeeess
The operator retrieve is used to specify the syntax of
an identifier which can appear only if it has been
previously declared. The expression retrie1Je ( . r· ). when
evaluated, has the following characteristics:
where the identifier set is (0 U 1)+. A typical sequence is:
(a) To => 01101 (c) TI => OnOldOnOI
where TI = «. b· ) --+ 01101).
The context-sensitive set with strings of the form
WI W2 ••• Wn where Wi ¢ Wj for all i ;:C j and where w, is
in the set (0 U l)+d is generated by the table-grammar:
(a) :: = create ( . b· ) (c) I create ( . b· ) (a)
(c) :: =
E
where the identifier set is (0 U l)+d. A typical sequence
is:
(a) To => OlOd (a) TI => OlOdlOnd (a) T2
=> OlOdlOndlld (c) Ta => OlOdlOndlld
where Tl = «. b· ) --+ OlOd),
T2 = «·b·) --+ 1011d)«·b·) --+OlOd), and
T 8 = «. b· ) --+ nd) ( (. b· ) --+ 10nd) ( (. b· ) --+
OlOd).
Table operators for contextual declarations
Programming languages utilize three different methods of associating table-categories with identifiers:
explicit declaration, implicit declaration and contextual
declaration. Explicit declaration of variables is used in
Algol to assure that the declaration of a variable precedes
its use. Syntax for expU.cit declaration preceding use
can be specified by the operator sequence:
create {·a· ) ... retrieve (·a· }.
An Extended
An instance of contextual declaration, is the association of the category "label" with an identifier by means
of the context in which the identifier appears. Two
distinct contexts are used to cause such a declaration and
these can be meanfully distinguished by the use of the
table-categories ( . proper label·) and ( . improper
label· ). For example, if the integer "25" appears in
columns 1 to 5 of a Fortran statement, then the integer
"25" has been contextually declared to be a (·proper
label· ). On the other hand, if the integer "25" appears
in a GO TO statement prior to its declaration as a
( . proper label· ), then the integer "25" will initially be
declared as an ( . improper label·). Two additional
operators, recreates and illegal, are provided to handle
the table activity associated with this kind of declaration.
1. The evaluation is blocked if the specified resident
category (. r· ) does not appear in the active-table.
2. The identifier in the selected dynamic-rule is
returned as the value.
3. In the selected dynamic-rule, the incident category
(·i· ) replaces the resident category (·r· ).
In summary, the expression (. i· )recreates ( ; r· ) when
evaluated selects a dynamic-rule whose leftside is (·r· ),
changes (. r· ) to (. i· ), and places in the output-string
the identifier appearing on the rightside of the selected
rule.
Scan for an invalid category
The operator illegal is used to specify a scan for an
illegal table-category. The expression illegal ( . r· ), when
evaluated, has the following characteristics:
1. The evaluation is blocked if the sgecified resident
category (. r· ) is present in the active-table.
2. The value returned is' the empty-string, €.
3. There are no side-effects in the active-table.
In summary, the expression illegal ( . r· ) when evaluated
is blocked if (. r· ) is in the active-table, otherwise it
returns € and has no side-effects.
Example of a micro-assembly language (MAL)
An example in the form of a micro-assembly language
(abbreviated ~IAL) will be used to illustrate the
definitional power of the four operators given above. It
Q(\~
uvu
will further show how a BXF grammar can be altered to
become a table-grammar while preserving most of the
original grammar-categories. The resulting table-grammar is only slightly larger than the original BNF
grammar. ~1AL is not intended to be useful as a
programming language. A free-form syntax has been
chosen to permit a definition which is not sensitive to
blanks or lines. l\IIAL has "dc" for "define constant" and
"ds" for "define storage." Statements are terminated by
semicolons, labels have a colon suffix, and the period is
used as a separator.
Sample program in l\1icro-Assembly Language (J\1AL)
a: dc. 12;
b: ds;
c: load. a;
store. b;
goto . c;
end;
Altering a table-entry
The operator recreates is used to alter a table-category
as a side-effect of generating a declared identifier. The
expression (·i· )recreates (-r·), when evaluated, has
the following characteristics:
B~~
BNF grammar for MAL
The syntax of BNF can be defined by the following
BNF rules:
(program) :: = (body) end;
(body) :: = (statement); I (statement); (body)
(statement) :: = (declarative statement)
(imperative statement)
(declarative statement) :: =
(data label) : dc. (integer) I
(data label): ds
(imperative statement) :: =
(imperative label) : (unlabeled imperative) I
(unlabeled imperative)
(unlabeled imperative) :: =
goto . (imperative label) I
(operation) . (data label)
(operation) :: = load add \ store
(imperative label) :: = (name)
(data label) :: = (name)
(name) :: = (letter) \ (name) (digit) I
(name) (letter)
(integer) :: = (digit) \ (digit) (integer)
(letter) :: = a\b\z
(digit) :: =
I
I
0\1\9
Semantic restraints on MAL programs
Certain restraints on ::.vIAL programs have in the past
been classed as "semantics." However their formalization by a table-grammar shows them to be syntactic
though not context-free. These restraints are:
1. All labels must be unique.
806
Spring Joint COmputer Conference, 1969
2.
(data label) must be declared by a dc or ds statement before it is used in an (imperative statement).
The op-codes "load," "add" and "store" must
reference a (data label) not an (imperative label),
3. A "goto" op-code must reference an (imperative
label), not a (data label) or an improper label (i.e.,
one for which there is no proper label declaration).
Unrestrained BNF generations
The following generations of illegal programs are
possible using the BKF grammar for JIAL when these
so called "semantic" restraints are not observed:
Generation
(program ) ~ a :ds; a :ds;
end;
(program ) ~ goto .a;
end;
(program ) ~ a :ds;
goto.a; end;
(program ) ~ a :ds;
load.b; end;
Error
Labels are not unique.
Label "a" is not properly
declared.
The goto references a
(data label).
(data label) "b" not
declared.
The table-grammar for MAL
The following table-grammar for l\IAL is a revision of
the BNF grammar given .above. Rules preceded by a *
have been altered. Unmarked rules are retained
unchanged. Rules which do not appear have been
omitted.
* (program)
:: =
(body) illegal ( . improper label· ) end;
(body> :: = (statement>; I (statement> ; (body>
(statement) :: = (declarative statement) I
(imperative statement>
* (declarative statement> :: =
create ( . data label· ) : dc . (integer) I
create ( . data label· ) : ds
* (imperative statement) :: = (unlabeled imperative)
create ( . imperative label· ) : (unlabeled imperative)
( . imperative label· )recreates ( . improper label· ) :
(unlabeled imperative)
* (unlabeled imperative> :: = goto . create <. improper
label· ) I
goto . retrieve ( . improper label· > I
goto . retrieve <.imperative label· > I
(operation> . retrieve ( . data label· >
(operation> :: = load I add I store
(integer) :: = (digit) I (digit) (integer)
(digit) :: =
I
0\1\9
The categories (name) and the following
cases are handled:
a. create ( . improper label· > allows a label to enter
the table before it is properly declared.
b.retrieve ( . improper label· ) allows a label which
was the argument of a prior goto, to be retrieved
as a reference by another goto, still prior to its
proper declaration.
c. retrieve ( . imperative label· ) allows a label which
has been previously properly declared to be used
as the argument of a goto.
In the rule for (imperative statement) two additional cases a.re ha.ndled:
d. create ( . imperative label· ) allows the contextual
declaration of a label to precede its use in a goto.
e. ( . imperative label· )recreates ( . improper label· )
allows a label previously referred to by a goto to
be redeclared as a proper label.
In the rule for (program) one final case is handled:
f. illegal (. improper label· ) blocks the generation
sequence in a case when goto references have not
been redeclared as a proper label.
Table operators for embedded blocks
Certain programming languages allow a block structure in which declarations outside of a block have a scope
which extends inward, while declarations within a block
are local to the block. An identifier already declared
outside a block may be redeclared within the block to
An Extended BNF
refer to a new address which will not agree with the one
assigned to the same identifier when used outside the
block. These requirements indicate that the table- tape
must be able to operate as a pushdown store in which
tables are handled as units of information. The top most
table is designated the "active-table." All operators
access only this table, while lower copies are inaccessible
to the operators.
3. As a side~effect, each instance of the specified
resident category (. r· ), within the active-table, is
changed to the specified incident-category (. i· ).
Returning to the example given at the beginning of this
section, if the expression (. nonlocal real· ) replaces
( . real· ) were evaluated following copytable , then the
table-tape contains TgTl and
T3 =
Tabie-iape pushdown operations
The niladic operators copytable and erasetable are used
to control the table-tape as a pushdown store whose unit
of information is a table. When evaluated, these
operators have the following characteristics:
1. They cannot be blocked.
2. They return as a value the ~mpty-string, E.
3. copytaiJle has the side-effect of placing a duplicate
copy of the active-table on the top of the table-tape.
4. erasetable has the side-effect of erasing the activetable from the top of the table-tape.
Control of local and nonlocal identifiers
The need for a special operator to provide initialization for nonlocal identifiers is best explained by an
example. Consider a table-grammar having only the
table-category ( . real·), and whose identifiers are
alphameric strings beginning with a letter. Let a
generation sequence proceed until a new inner block has
just been initialized, a copytable has just been executed,
and the table-tape contains Tl T 1 • Horizontal snapshots
of the table-tape are oriented so that the active-table is
on the left.
T1 =
T4 =
«. real· ) ~ k9)
«·real· ) ~ a5)
«·real·) ~ cd).
Within the active-table there is no information which
indicates that k9 is local and that both a5 and cd are
nonlocal to the current block. In order that such a
distinction could be achieved, a new expression must be
defined. This expression is (·i· )replaces (·r· ), which
when evaluated has the following characteristics:
1. The evaluation cannot be blocked.
2. The value returned is the empty-string,
E.
«. real· ) ~ k9)
( ( . nonlocal real· )
( ( . nonlocal real· )
~
~
a5)
cd).
In T 4, the desired distinction between local and nonlocal
identifiers has been obtained.
Examples of embedded blocks
The BNF grammar
I [(c) (a)]
(d) I (d), (c)
(a) :: = [(c)]
(1)
(c) :: =
(2)
(d) :: = 0
11 11 (d) I 0 (d )
(3)
generates the strings:
« ·real· ) ~ cd).
T2 =
«. nonlocal real· ) -7 a5)\
( ( . nonlocal real· ) ~ cd).
A subsequent evaluation of create ( . real· ) would give
a table-tape of T 4T 1
«. real· ) ~ a5)
Let the active-table T 1 be updated via create (. real· ) so
that the table-tape contains T2Tl and
SOi
(a )TO ~ [0, 1, 101 [1, 010, 0]]
(4)
(a )TO ~ [0, 1, 101 [101, 101]] .
(5)
Now add the restraint that values for (d) appearing in
the rule for (c) may appear only once at each level of
self-embedding. This is equivalent to the restriction that
an identifier be declared only once on each level and
t.hat identifiers declared on an outer level may be
redeclared on an inner level. Given this restraint,
generation (4) is well formed but generation (5) is not,
because 101 is repeated on the lowest level. The
following table-grammar generates (4) but will not
generate (5) thus satisfying the restraint stated above.
(a) :: = [copy table (b) erasetable] I
[copytable (b) (a) erasetable]
(b)
( . nonlocal· )replaces (·local· ) (c)
(*1)
(6)
808
Spring Joint Computer Conference, 1969
(c) :: = (d)
I (d),
(c)
(2)
(d) :: = create (·local· ) I
{·local· )recreates ( . non local· )
(*3)
Note that (*1) and (*3) are revisions for the tablegrammar of (1) and (3) respectively, and that the
table-category (. nonlocal· ) enters the active-table in
the rule for (b) and is utilized in the rule for (d).
The following is the table-grammar generation sequence for the string given in (4) above.
* Lr (b \I ,a
I) erase"a
l
b1leJ1
(a-)T0 =}
rp
.L
0 rp
.L 0
(7)
~ [0, 1, 101 (a) erasetable] Tl To
=?
=?
(8)
[0, 1, 101 [ (b ) era.setable] erasetable]
Tl Tl To
(9)
[0, 1, 101 [ (c ) erasetabZe] erasetable]
T2 Tl To
the context will make clear which type of operator is
intended. An additional recognition-operator, copy, is
also provided to allow a limited form of deterministic
recognition, The recognition-operators have access to a
wo-rkspace which is placed on the top of the table-tape.
The recognition-operators are defined as follows:
copy:
This monadic operator has as its operand a
terminal character from a set of checkout-characters.
The set of checkout-characters is fixed for a
particular grammar. "copy c" reads characters from
the input and places then in the workspace until
one of the checkout-characters is reached. The
operation succeeds if this character is "c" otherwise
it fails. If the operation succeeds, the control is
passed along this path with the workspace initialized
for use by a subsequent table-operation. If the
operation fails the workspace is erased and
recognition must proceed along an alternate path.
(10)
create, retrieve, recreate:
~ [0, 1, 101 [1, 010, 0 erasetable]
erasetable] Ta Tl To
(11)
~ [0, 1, 101 [1, 010, On
(12)
where:
To =
E
Tl = « ..t.)
~
101)( (·t·)
T2 = «·n·)
~
101)( (·n·)
Ta= «.(.)
~
~
1)( (.(.)
~
010)«·n·)
~O)
1)( (·n·)
~
~
0)
101)«·(·)
These recognizer-operators utilize the workspace as
their identifier input. If these operators succeed,
they erase the workspace in addition to their usual
side effects in the active-table. Since these three
rocognition-operators require that the identifier be
already present in the workspace, they must be
preceded by the execution of copy which initializes
the workspace.
illegal, replaces, copytable, erasetable:
~
1)
« .(. ) ~ 0)
and where (.(. ) stands for (·local· ) and (. n· ) stands
for (. nonlocal· ).
Recognizers for table-languages
I\1uch work has been done on the problem of designing
syntax-directed recognizers14 for languages defined by
BNF grammars. This section will indicate that existing
syntax-directed techniques for BNF can be extended to
table-languages.
Recognition-operators
A syntax-directed recognizer needs a means of
carrying out each event in the recognition sequence
which corresponds to its dual in the generation sequence.
For a table grammar this requires that a recognitionoperator be defined for each grammar-operator. While
the same names ",-ill be used for both types of operators,
These four recognition-operators are identical to
their duals in a grammar. They neither utilize nor
a.ffect the contents of the workspa.ce.
A summary of the definitions for the seven operators
for a grammar and the eight operators for a recognizer
are given in Appendices 1 and 2 respectively.
A recognizer for MAL programs
The table-grammar for MAL can be revised to place
it in right-linear form since self-embedding recursion is
not employed. In this form a recognizer or generator
would not use the pushdown store and would only need
the finite control and the table-tape. A deterministic
recognizer for MAL programs is shown in Figure 2.
A copy with reference to the respective delimiter has
been inserted preceding each instance of create, recreate
and retrieve. In two cases table-operations provide
alternative paths from a node. However in each
situation only one of the possible alternatives can
succeed.
An Extended BNF
809
catenation and closure. Limited regular expressions,
when embe~ded within a context-free grammar, have
been shownI5 to be useful both in the representation of
the syntax of programming languages and in the
construction of processors which automatically create
efficient recognizers. This section will indicate that the
use of regular expressions within a rule of a grammar can
be extended to the domain of regular table expressions.
Union, catenation, closure & distribution
A regular table expression is defined recursively as
follows:
Let "a" be ~ny terminal, E the empty-string, and q, the
null-set, then:
E, q" create ( . i· ), retrieve
(·r·), illegal (·r· ), (·i· )recreates(·r·), (·i·)
replaces (. r· )} is a regular table expression.
2. If p is a regular table expression, then so are:
copytable P erasetable and (p) *.
3. If PI and P2 are regu~ar table expressions defined for
the same set of identifiers and having the sam e
table-categories, then so are: P1P2 and PI U P2.
4. No string is a regular table expression unless its
being so follows from 1 to 3 above.
1. Any element in the set {a,
Key:
o
Sillple .tate.
~
~
ri~l state.
~ =i~i: ~ ~ ~P~~;
011
Stands for
011 ••• 19.
tlDlabele4 link
=
input strlna.
...!!!!.L Default
trauaitiODi
follC11fe4 if all other
transitions faU.
Figure 2-A deterministic table recognizer for MAL programs
Consider the three alternatives which occur following
the path for goto:
create ( . improper label· )
(1)
retrieve ( . improper label· )
(2)
retrieve ( . imperative label· )
(3)
If the identifier in the workspace is not in the table
then (1) will succeed, and (2) and (3)' will fail. If the
identifier in the workspace is in the table, (2) will succeed
if the selected table-category is (. improper label· ),
while (3) succeeds if the selected table-category is
(·imperative label· ). In each case there is only one
path from the node which can succeed. If none succeed
the device is blocked and the input-string is rejected.
Languages with self-embedding recursion cannot be
placed in right-linear form and would require the use
of the pushdown store as part of the recognition scheme.
Also not all table-languages will be deterministically
recognizable using the copy operator with its checkoutcharacter set and workspace.
It is claimed without giving the proof that regular table
expressions are closed under union, catenation and
Kleene closure. However it is necessary to distinguish
between the form of an expression and the set it defines.
If LI is the language defined by PI and ~ by P2 aDd
L3 = LIL2 it does not follow that L3 = PlP2. If L is the
language defined by p, then it does not follow that
L* = (p)*. This is due to the fact that various table·,
operators record information in the active-table so that
generations to the right of a table-operator may not
generate the same strings as they would if they were on
its left. The definition of (p) * is ~ pi where pO = E and
fJ i+1
=
ppi.
i=O
The laws of distribution are obtained by definition.
Let p, PI, ... , p", be regular table expressions, then:
p(pi U P2 U ... U Pn)
=
PPI U PP2 U ... U PP" ,
and
(PI U
P2
U ... Up",) P = PIP U P2P U ... U PnP .
Replacing recursion by the closure operator
Regular table expressions
A regular table expression is an extension of those
regular expressions where operators are limited to union,
In clause 1 of the definition of a regular table expression
(given above), if the domain of "a" is extended to
include grammar-categories, then two important identi-
810
Spring Joint Computer Conference, 1969
ties can be shown to preserve the generative power of'
table-grammars (the proof itself is not given).
Let PI, P2 be regular table expressions that have no
instance of (a) within them; further let "(" and ");' be
grouping brackets for expressions and let them be
disjoint from the set of terminals, then:
1. The
(a)
2. The
(a)
rule
:: =
rule
:: =
- Pl
.,(a) "
({J2)*Pl'
"(a) ..
- PI
Pl({J2)*.
(1'2) (a) can be written
(a )(P2) can be written
In both cases, (a) is now defined without the use of
explicit recursion. By the use of a uniform substitution
for (a), it can be eliminated from the set of rules of a
table-grammar.
Extensions and limitations
The following extensions of table-grammars can be
readily achieved within the framework given here. Some
limitations are cited which lie outside the present model.
Additional extensions which can overcome these funitations may be possible.
A partitioned identifier set
For some languages, the identifier set is partitioned
by the definitions of the language. In ASA Fortran,
if an identifier has no explicit declaration the type is
implied by the rule: "names beginning with letters I to
N are type integer, all others are type real." This rule
partitions the undeclared identifiers into two disjoint
subsets. To handle this case create would be replaced by
two operators create-integer and create-real. For a
particular grammar these new operators would· be
defined to select undeclared identifiers from their
respective disjoint partition of the total set of identifiers.
Use of an implicit retrieve operator
In a very large grammar, it may be desirable to omit
the operator retrieve and let the table-category itself,
appearing alone in the grammar, be in effect an implicit
call, in which the effective presence of retrieve is to be
understood. The generative power of the notation with
retrieve omitted would be identitical to that where
retrieve is explicitly used.
Limitations
A table-grammar, as defined here, is able to specify
the declarations of scalar variables and labels. It is
unable to specify all the restraints required for subscripted variables and for procedure calls when argument
lists are used. In addition, table-grammars are limit.ed t.o
declarat ions where the identifier set is static. The
IlVIPLICIT statement of Fortran sets up dynamic
partitions of the identifier set. Even the extension of
create given above is able to handle only static partitions
of the identifier set.
ACKNOWLEDGMENTS
The author wishes to thank R, A. Stone ot Western
Electric, Princeton, C. B. Jones of I.B.M. Vienna,
C. N.lVlooers of Rockford Research, Cambridge, Mass.,
and M. A. Harrison of the University of California,
Berkeley, each of whom contributed constructive suggestions which have been included in the paper.
REFERENCES
~
P ~AUR
Documentation problems: ALGOL 60
Communications of the ACM Vol 6 No 3 March 1963 p 78
2 P NAUR
Revised report on the algorithmiC language ALGOL 60
Communications of the ACM Vol 6 No 1 January 1963
pp 1-17
3 N CHOMSKY
On certain formal properties of grammars
Information and Control Vol 2 1959 pp 137-167
4 S GINSBURG
The m 'Jthernatical theory of context-free languages
McGraw-Hill 1966
5 R W FLOYD
On the nonexistence of a phrase structure grammar for
ALGOL-60
Communications of the ACM Vol 5 No 9 September 1962
pp 483-484
6 K IVERSON
A method of syntax specification
Communications of the ACM Vol 7 No 10 October 1964
pp 588-589
7 J W CARR J WEILAND
A nonrecursive method of syntax specification
Communications of the ACM Vol 9 No 4 April 1966
pp 267-269
8 F G DUNCAN
Notational abbreviations applied to the syntax of Algol
SICPLAN Notices ACM Vol 2 No 11 November 1967
pp 28-43
9 K
BAl~DAT
On the formal definition of PL/ I
Proc S J C C Vol 32 1968 pp 363-374
10 S GINSBURG S A GREIBACH M A HARRISON
Stack automata and compiling
Journal of the ACM Vol 14 No 1 January .1967 pp 172-201
11 G WHITNEY
The generation and recognition properties of table languages
IFIP Congress Software I August 1968 pp B18-B22
12 G WHITNEY
The position of table languages within the hierarchy of
nondeterministic on-line tape bounded during machine
languages
IEEE Conference Record Ninth Annual Symposium on
Switching and Automata Theory October 1968 pp 120-130
An Extended BNY
13 R E STERNS P M LEWIS
Property languages and table machines
Ibid pp 106-119
14 J FELDMAN D GRIES
Translator writing systems
Communications of the ACM Vol 11 No 2 February 1968
8li
pp 77-113
15 V TIXIER
Recursive junctions oj regular expressions in language
analysis
Stanford University Computer Science Dept Report CS58
March 1967
APPENDIX I
Table-expression
Side-effects
Value-returned
Selected-identifier must
be undeclared
Selected-identifier
Add to the active-table the
rule:
( . i· ) ~ selected-identifier
retrieve ( . r· )
There must exist within
the active-table a rule:
( . r· ) ~ identifier
Selected-identifier
None
( . i· ) recreates ( . r· )
There must exist within
the active-table a rule:
( . r· ) ~ identifier
Selected-identifier
The selected rule is
changed to:
( . i· ) ~ identifier
( . i· ) replaces ( . r· )
None
create (·i· )
illegal <. r· )
Note:
Conditions
The operation is blocked if
( . r· ) is present in the
active-table
E
E
copy table
None
E
erasetable
None
E
Within the active..:table
each (. r· ) is replaced
by (·i· )
None
A duplicate copy of the
active-table is placed on
the top of the table-tape
The active-table is erased
(·i·) stands for an incident table-category and (·r·) for a resident table-category.
E
SUMMARY OF DEFINITIONS FOR GENERATION-OPERATORS
is the empty-string.
812
Spring Joint COmputer Conference, 1969
APPENDIX II
Side-effects if operation succeeds:
In active-table
I
In worksDace
Table-exoression
Conditions
copy c
Succeeds if the next checkout character is c
None
Characters up to care
copied into the workspace
create ( . i· )
Identifier in the
workspace must be
undeclared
Add the rule:
( . i· ) ~ identifier
Erased
retrieve ( . r· )
I There must exist within
.L
II
( . i· )recreates ( . r· )
~
None
the active-table a rule:
( . r· ) ~ identifier
such that identifier =
contents of workspace
Same as for retrieve (. r·)
The selected rule is
changed to:
( . i· ) ~ identifier
Erased
Note: a. the execution of copy must precede evaluation of expressions containing create, retrieve, or recreate.
b. the definitions for illegal, replaces, copytable and erasetable are the same as given in Appendix 1.
SU::vIlVIARY OF DEFINITIONS FOR RECOGNITION-OPERATORS
A hierarchical graph model of the
QDoYnO'W'1ll"'~~Q
O'-'.&A.a..... .a.a ......""'o
flro.f ........ flroO'-..OTnlQ
" ...
1'''' v~ ... «
.......0
by TERRENCE W. PRATT
The University of Texas
Austin, Texas
INTRODUCTION
The problem of developing an adequate formal model
for the semantics of programming languages has been
under intensive study in recent years. Unlike the area
of syntax specification, where adequate models have
existed for some time, the area of semantic specification
is still in the formative stages. Development of formal
semantic models has proceeded along two main lines,
lambda-calculus models (e.g., Landin,! Strachey2) and
directed graph models (e.g., Narasimhan,3 Floyd4).
This paper describes a model for the semantics of
programs based on hierarchies of directed graphs.
A formal model or theory of the semantics of programming languages must provide descriptions on a
number af different levels, much as the theory of
context-free grammars provides descriptions of the
syntax of programming languages on a number of
different levels. At the most general level a semantic
theory provides a framework for describing a class of
programming languages and investigating the mathematical properties of their formal representations in the
model. At this general level the context-free grammar
model of syntax has been particularly successful, giving
rise to an extensive mathematical theory as well as
providing characterizations of specialized syntacticallysimilar classes of languages. One would hope that
adequate models of semantics would lead to the same
sort of mathematical development and to the classification of semantically-similar programming languages.
At a more specific level, a semantic model must
provide descriptions of the semantics of particular
programming languages, much as a particular contextfree grammar may be used to describe the syntax of a
particular programming language. One· would expect
the formal specification of the semantics of a programming language to allow conciseness and unambiguity in
813
definition and also to lead to definition of new languages
which are more "regular" semantically.
At a still more specific level, a semantic model must
provide descriptions of particular programs, and these
descriptions must be constructable from the representation of the program (the syntax) in a straightforward
manner. Thus it should be possible to construct a
"compiler" which will translate a program in its written
representation into its equivalent in the semantic model.
From this representation the formal properties of the
model may be used to guide further processing, by
producing, for example, a more efficient program which
is semantically equivalent or by translating the program
into another representation, such as a semantically
equivalent program in another language.
At the level of complete specification, a semantic
model must provide a representation of the data used
by a program and allow execution of the program on
the particular data. Thus it should be possible to
construct an "interpreter" which will execute a program-data pair in its representation in the model.
The importance of the development of adequate
models of semantics stems from the probable gains to be
realized by their use, both in the area of definition of
programming languages, where the formal definition of
semantics should lead to semantically unambiguous as
well as more easily intelligible languages, and in the
area of processor construction, where it is likely that a
better understanding of the semantic features of
languages will lead to more powerful and efficient
processing techniques for those features.
The model for semantics described in the following
sections is based on the use of hierarchies of directed
graphs to represent both programs and data. The
hierarchical graph or H-graph concept which is basic to
the model is defined in the next section, along with the
814
Spring Joint Computer Conference, 1969
concepts of "level" and "path" which serve as important
structural concepts in the application of H-graphs to
the description of programming languages. In a later
section the basic semantic rnodei is introduced by
structuring further the "atomic units" which lie at the
lowest level of the hierarchy in H -graphs. Basic
programming concepts such as "program," "data," and
"execution of a program" are defined also. In the last
section examples are given to illustrate informally how a
number of semantic features of actual programming
languages may be represented in a natural way in the
model. Included are complete models of the semantics
of particular Tlli~.u""lg machine, Lisp, and Fortran
programs. Finally, a concluding section attempts to
evaluate the model and view possible applications and
extensions.
Hierarchical graphs (H-graphs)
In this section a generalization of the mathematical
concept of "finite directed graph" is presented which
forms the basis for the model of semantics presented in
the next section.
Basically, a directed graph (sometimes called a
"network") is composed of a finite set of "nodes," and a
finite set of "edges" connecting pairs of nodes in a
"one-way" manner. Commonly, nodes are represented
as circles or boxes and edges as arrows connecting nodes.
Examples of the use of directed graphs in computer
science include flow charts, automata transition diagrams, PERT networks, and representations of list
structures and trees.
Three extensions of the basic concept of directed
graph are of interest here. The first two lead to a
definition of "extended directed graph," and the third
to a defin.ition of ((hierarchical directed graph."
Extended directed graphs
Informally, an extended directed graph is a directed
graph with a designated node (called the "entry point")
and with the edges leaving each node uniquely labeled.
Formally:
Defn: An extended directed graph is an ordered
quadruple (N, L, S, E) where N is a finite non-empty
set (of nodes),
L is a finite set (of labels),
S is an element of N (called the entry point), and
E is a partial function from N x L into N, defining
the edges. If E(n, p) = q, then there is said to be an
edge from node n to node q with label p. Note that
there may not be two edges leaving a node with the
same label, but two edges leaving a node with
different labels may end at the same node; thus
"parallel" edges are allowed. Ignoring the contents
of the nodes, every flow chart may be considered as
an extended directed graph.
H-graphs
A hierarchy is introduced into a set of extended
directed graphs (hereafter called simply "graphs") in
the following manner. A universe U of atomic units
(distinct symbols) is assumed. A hierarchical graph or
H-graph over U is (informally) a graph in which the
nodes are considered to be "containers," each of whose
contents is either an atomic unit from U or an H-graph
over U. Thus in flow -chart terms, the analogue of an
H -graph is a flow chart in which each box contains
either an "atom" or another flow chart, whose boxes
may in turn contain atoms or flow charts, and so forth,
to any depth. Formally:
Defn: If U is a set (of atomic units or atoms), then
an H-graph over U is an ~rdered pair (N, V) where:
1. N is a finite set (of nodes or containers).
2. V (the contents or value function) is a function
mapping N into U U {x:x is a graph with nodes
from N and labels from U}. If c E N, then V(c)
is called the cun.tenl8 or value of c.
Levels
The hierarchical structure of an H -graph is brought
out by considering the levels of its nodes.
Defn: The level of a node c is defined recursively as:
a. 1 if V(c) E U (i.e., if c contains an atomic unit).
b. n if V(c) is a graph (N, L, S, E), the level
of each node in N is in the set {I, 2, ... ,
n - I}, and at least one node in N has level
n-1.
If a node is not of level n for any n~ then it is termed
a recursive node.
Defn: The node set of a node c in an H -graph is
defined to be:
a. if c has levell, then A, the empty set,
or
h. if c contains a graph (N, L, S, E), then N U
[ U {node set of x}].
xEN
Thus the node set of a node is composed of all the nodes
"reachable" in the hierarchy starting from that node.
Hierarchical Graph ·Model of Semantics of Program..8
Defn: An H-graph (N, V) is relJUrsive if N contains
a recursive node.
Defn: The atom set of a node c is the set of values
of all level 1 nodes of the node set of c. Thus the atom
set of a node is the set of atomic units "reachable" in
the hierarchy starting from that node.
Level 1
Cl:
I
ABC
C3:
I
QED
I
C4: I
C2:
Paths
Along with the concept of level, the idea of a "path"
in an H-graph is important in the development of the
model of the next section. The concept of path will be
defined first for graphs and then extended to H -graphs.
Informally, a path in a graph from one node to another
is just a set of edges which may be traversed in going
from the first node to the second, passing from node to
node along connecting edges. Formally,
Defn: If G = (~, L, S, E) is a graph, then a path
from node x to node y of G is an ordered sequence
(x, ko, kl' ... , k m) where each k i is a label such that
E(x, k o) = nl, E(nl, k 1) = n2, ... , and E(nm, k m) = y.
In general, certain nodes of a graph will have no ~dges
leaving them. Of particular importance here are the
paths which begin at the entry point of a graph and
terminate at such nodes.
81.5
27
10
Level 2
C5:
..
0
*Cl
C2
~to
C4
C6:
~
1
C3
O. Cl
*C2
Level 3
C7:
o
*C6-.....-
o
C5 ----.- Cl
Figure I-Three level H-graph
Defn: A path beginning at node x is a path from
node x to a node y such that y has no edges leaving it,
i.e., such that E(y, k) is not defined for any k E L.
Defn: A path in a graph G is any path beginning
at s, where s is the entry point of G.
Extending this concept to H -graphs, if C is a node of
an H-graph, then (informally) a path through C is
composed by taking a path through the graph contained
in C, a path through each of the graphs contained in the
nodes encountered in that path, and so forth down the
hierarchy until level 1 nodes are reached. Formally,
Defn: If G is an H -graph and C is a node of G,
then a path Pc through node C is represented by:
1. if C contains an atomic unit A, then (C, A)
or
2. if C contains a graph, then (C, P) where
P = (P B , eo, pno, el, ... , em, Pn m) and (s, eo,
... , em) is a path in G passing through nodes
s, no, ... , lim and each Pn, is a path through
node n,.
Defn: The atom sequence of a path is simply the
sequence of atomic units encountered in following the
path. In the representation given above, the atom
sequence is simply the sequence of atomic units (not
including edge labels) obtained in scanning the
representation of a path from left-to-right ignoring
everything except atomic units.
For example, Figure 1 represents an H-graph, where
Cl, C2, ... , C7 are nodes each of whose contents is
given by the contents of the correspondingly labeled
box. One path through node C7 is represented by:
(C7, ((C6, ((C2, 27), 0, (Cl, ABC))), 0, (C5, ((Cl,
ABC), 0, (C2, 27), 0, (C3, QED), 1, (C4, 10))), 0,
(Cl, ABC))).
The atom sequence for this path is: (27, ABC, ABC,
27, QED, 10, ABC).
Further development of the theory of H-graphs is
outside the scope of this paper. This brief introduction
will suffice for the purposes here.
The basi8 semantic model
On the basis of the H-graph concept, an elementary
model of semantics is developed in this section, including
definitions of program, data, and execution of a
program.
Program and data H-graphs
The semantic model is based on H-graphs with a
more highly structured universe of atomic units. For
816
Spring Joint Computer Conference, 1969
the semantic model, the universe U of atomic units is
assumed to have the following structure:
U = D U (j> (D and (j> not necessarily disjoint)
where D is a set of data units and (j> is a set
of operator instances.
D = Dl U D2 U ... U DlI (the D/s not necessarily disjoint) where each D i is a set of data
units forming a data type class.
(D, = e.g., integers, reals, bits, characters, strings)
Similarly:
4> = 4>1, U 4>2 U ... U 4>m (4)/s not necessarily
disjoint) where each 4>i is a set of operator
instances forming an operator type class.
(4), = e.g., "add," "multiply," "popupt
"differentiate")
Definitions:
1. An atomic unit a E U is said to be of type T
(where T is a data or operator type class) if a
E T. Since type classes are not necessarily
dis-joint, the type of an atomic unit is not
necessarily unique.
2. A node n of an H-graph over U is said to be
of type T if the atom set of n is a subset of type
class T.
3. An H -graph is of type T if each of its nodes is
of type T.
4. A data node is a node whose atom set is a
subset of D.
5. A data H -graph is an H -graph whose nodes are
all data nodes.
6. A program node is a node whose atom set is a
subset of 4>.
7. A program H -graph is an H -graph whose nodes
are all program nodes.
Operator instances
Although the concept of data type class is familiar
from actual programming languages, that of operator
instance is not as common.
Defn: An operator instance Q is an ordered triple
= (I, 0, f), usually written f(I; 0), where I is a
finite set of (input) nodes, 0 is a finite set of (output)
nodes, and f (the operator) is a function from X into Y 1
where X and Yare sets of H -graphs, each H -graph in
X and Y containing the nodes in I and O.
A typical example would be the operator instance
Q
"( {A, B}, {C}, add)" or "add (A, B; C)"
with input nodes A and B, output node C, and operator
"add" which maps any H-graph containing the nodes
A, B, and C, and in which A and B have numerical
values, into the H-graph identical to the original except
with C containing the sum of the values of A and B.
Execution of an operator instance is a primitive concept
by which is meant the application of the operator to its
arguments found in its input nodes, producing values
found in its output nodes. When an operator instance is
executed, it is understood that the H-graphs defined by
its input nodes completely define its arguments, in the
sense that given the same input H-graphs, the same
values will be produced as output. Similarly, the effect
of an operator is assumed to be localized in the H-graphs
produced as the values of its output nodes, in the sense
that if the value of a node is changed by the operator
then that node must be in the node set of one of the
output nodes. Thus the set of input nodes of an operator
instance in a sense specifies the maximum set of data
structures which may influence the effect of that
operator instance, and similarly, the output nodes
specify the maximum extent of the effects produced.
Note that only the input and output nodes of an
operator instance are fixed, not the contents of these
nodes, so that different executions of the same operator
instance will, in general, produce different results, even
though the input and output nodes are the same. Only
if the H-graphs defined by the input nodes are identical
will execution necessarily produce the same results in
the output nodes.
Execution of a program H-graph
Any program node of an H -graph defines a set of
possible execution sequences of operator instances as
follows:
Defn: If c is a program node, then the sequence
PI, P2, ... , Pll of operator instances is an execution
sequence of c if (PI, P2, ... , P1l) is the atom sequence
of some path through c.
Every path through a program node defines a
possible execution sequence of operator instances.
Execution of a program node involves the choice of a
path through that node and execution of the operator
instances in order from the execution sequence defined
by that path. Corresponding to actual execution of
programs in a programming language, the process of
choosing a path may be represented as a process which
in a sense actually traces out a path step by step,
executing operator instances as they are encountered in
the path, and choosing the next step of the path as a
dynamic function of the results of execution of the
previous operator instances encountered. Thus the
Hierarchical Graph Model of Semantics of Programs
choice of execution sequence is determined by the
"data," that is by the H-graphs in the input node set
of the operator instance being executed. The process of
execution of a program node c of an H -graph (N, V)
may be defined precisely as follows by use of a designated
level 1 node P of type "label:"
1. If c is a level 1 node, then execute the operator
instance contained in c.
2. If c is not a level 1 node and contains the graph
(N, L, S, E), then:
a. Set the current node· = S.
b. Execute the current node (saving the name
of the node being executed in a stack until
execution is complete).
c. If there is no edge leaving the current node,
then stop (returning to the next higher level
to continue execution if necessary).
d. If there is exactly one edge (labeled k)
leaving the current node, then set current
node = E(current node, k} and go to (b).
e. If there is more than one edge leaving the
current node, then set the current node =
E(current node, Yep)) and go to (b).
Note that at a branch in a program graph the choice
of which branch to follow is determined by the label
contained in the designated node P. Since P may be one
of the output nodes of an operator instance, execution
of an operator instance may change the value of P,
and thus the "flow of control" is determined dYnamically
by the operator instances and the "data." Clearly, a
path through node c is determined by this process if the
process terminates.
paper, an attempt is made in this section to develop in
a general way a correspondence between features of
actual programming languages and properties of the
model.
Particular features of actual programming languages
may commonly be represented in more than one way in
the model. The examples given below indicate only one
possible way that particular constructs may be repre"0:...
+0,..1
.......
0"1,,,..1; ........ +1-.0
.........
",,;1-,.;l;+n +1-.,,+
'-.&., u,;+1-.",,,+
,Y.LlI.I...I.VU.V
P.&.\,..rV.L\A.l.A..L.LL
UJ..L'-'
PVOQ,LU.LL.1.UJ
UJ...LQV
o
O\..l..L.Lu ......
",+1-,.1>:..
VIJJ..L\:I.1.
representations may be possible and even desirable in
certain models of an entire language.
In the examples, nodes are represented by ovals or
polygons and edges by arrows. All nodes and edges are
labeled. The contents of a node will ordinarily be
written inside the oval or rectangle representing it. The
entry point node of a graph is indicated by an * next to
the node. Thus, for example, Figure 2 represents a node
C whose value is a graph on nodes Cl, C2, and C3, with
entry point Cl and E(Cl, k) = C2, E(C2, k) =
C3, E(C3, k) = C1. The nodes Cl, C2, and C3 have as
values the atoms A, B, and C, respectively.
In cases where node names· and/or edge labels are not
significant, they will ordinarily be omitted. Thus the
same graph might be written alternatively as in
Figure 3. Operator instances will be represented in the
form:
c:
*Cl
k, C2
\;
C3
Correspondence between the model and actual
programming languages
The general model of the previous section serves as a
framework for the description, comparison, and classification of the semantics of different programming
languages. A model of the semantics of a particular
programming language is formed by specification of a
particular universe of atomic units together with a set
of restrictions or constraints on the types of data and
program H -graphs which may be constructed on this
universe. A model of a program or a data structure in
the language then is a program or data H-graph on the
given universe which satisfies the constraints of the
language. The classification and comparison of the
semantics of languages is based on the classification and
comparison of the properties of the universes of atomic
units and of the properties of the constraints on
H -graphs. Although detailed descriptions of actual
programming languages are outside the scope of this
817
Cl:0
Figure 2
C:
Figure 3
818
Spring Joint Computer Conference, 1969
where each h is the name of an input node and each Ok is
the name of an output node.
Three complete models of programs and data are
given in this section, for Turing machines, LISP, and
Fortran. Although no attempt is made to provide
complete descriptions of the languages, the models of
the particular programs used are constructed so as to
indicate how a general model might be constructed.
Turing machine semantics. Consider first the representation of the semantics of a particular Turing
machine. Intuitively, a Turing machine is very simple
semantically. Both the program (the functional matrix)
and the data (the tape) are of simple structure. This
makes a model of the semantics of Turing machines a
useful test case for a semantic theory. The general class
of Turing machines that will be modeled have a single
tape and read head, and at each move they will (1) read
the spubol in the square being scanned, (2) change
state, (3) write a symbol, and (4) move left or right one
square.
a. Atomic units. The universe of atomic units U for
Turing machines over a particular alphabet A is
composed of:
U = A' U
b. Data structures.
Levell nodes. Except for the special node P and
the nodes containing the alphabet symbols, all
level 1 nodes correspond to tape squares
containing a symbol from the alphabet A.
P is the node mentioned in the execution
algorithm for program H -graphs, and for each
alphabet symbol a node is required containing
that symbol (for the WRITE operator).
Level 2 nodes. Only two nodes are needed,
TAPE and HEAD. TAPE contains a two-way
list (of level 1 nodes) with edges labeled "left"
and (iright." HEAD contains a single level 1
node which corresponds to the tape square
being scanned.
~. Program structures.
Levell nodes. Contain single operator instanc~s.
Level 2 nodes. Only one node PROG is needed,
which contains a graph representing the
functional matrix of the Turing machine.
d. Operator type classes. See Table I. (H =
HEAD, T = TAPE, V is the function which,
given a node, returns the value of that node.)
e. Example. For the 2-state 3-symbol Turing
machine given in Figure 4 an H -graph representation is given in Figure 5.
cJ>
where A' and cJ> are disjoint, A' = A U {left,
right}, A is the alphabet of the Turing machine,
{left, right} are labels, and cJ> = READ U
WRITE U l\IOVELEFT U l\IOVERIGHT U
NO-OP where REAL, WRITE, MOVELEFT,
MOVERIGHT, and NO-OP are the names of
disjoint operator type classes defined below.
Execution of the program H -graph PR~G simulates
the operation of the Turing machine. Execution of
PR~G involves simply following a path from the entry
point (node P9) of the graph in PROG to the (unique)
node P5 of the graph which has no exiting edges. This
path is chosen according to the algorithm of the
Table I -Turing machine operator instances
Class
Form of Operator
Instances
READ
READ(H; P)
WRITE
MOVELEFT
WRITE(a, H; H)
MOVELEFT(H, T; H, T)
MOVERIGHT
lVI0VERIGHT(H, T; H, T)
NO-OP
NO-OPO
Function
Trap.sfers V(V(H» to P (i.e., copies the symbol
being scanned into P)
Sets the value of the node V(H) = yea)
Let a = V(H), set V(H) = E(a, left) where E is
the edge function of the graph in T. If E(a, left)
is not defined, create a new node with a unique
name (3. Set V(H) = (3. Define E(a, left) = (3
and E({3, right) = a and set V({3) = ~ (empty
tape square symbol of A)
Same definition as MOVELEFT, replacing "left"
by "right" and "right" by "left."
The identity operation (does nothing)
Hierarchical Graph Model of Semantics of Programs
MATRIX
Symbol
0
1
#
So
1 ,R, So
O,R,SO
#,L,Sl
Sl
1,L,8
0,L,8
Halt
State ' \
1
1
INPUT TAPE
7'
Initial
head
position
Figure 4-Turing machine initial configuration
preceding section. Thus beginning at P9, the operator
instance in P9 is executed (corresponding to reading the
tape square under the read head and storing the symbol
read in node P). Then the edge leaving pg is chosen
which is labeled with the symbol contained in P (in this
case 0). This edge leads to PO, which becomes the
current node. The operator instance in PO is executed
(writing a 1 on the tape square under the read head).
The single edge leaving PO is followed to P3, the
operator instance contained in P3 is executed, etc.
Execution continues in this manner until node P5 is
reached.
In the Turing machine representation both program
and data have only two levels, giving a hierarchically
simple structure. The given representation readily
extends to arbitrary Turing machines and initial
configurations.
Lisp semantics. As a second example, consider the
problem of representing the semantics of the following
Lisp function with its argument:
(LABEL(LAST(LAMBDA(X) (CPND
((NULL(CDR X)) (CAR X))
,(T (LAST (CDR X))))))) ((A (B C) DE))
An H-graph model may be constructed for this function
in such a way that extension of the model to the
remainder of the Lisp language is possible.
In representing the Lisp function two major problems
arise:
819
1. The sequence of operations specified implicitly
through function composition and the order of
evaluation conventions of Lisp must be made
explicit in the H-graph representation.
2. The pairing of formal parameters and actual
parameters, and the transmission of evaluated
arguments to the functions using them must be
handled by explicit use of versions of the
standard Lisp interpreter A-list and pushdown
list.5 This is due to the fact that the H -graph
model contains no built-in provision for argument
transmission to subprograms.
A representation of the semantics of the above Lisp
function may be constructed as follows:
a. Atomic units.
units be:
Let the universe U of atomic
U = A U {T,
~IL}
U P
where A is the set of Lisp atoms and P = CAR
U CDR U NU;LL U PAIR U VALUE U
PPPUP where these data type classes are defined
below.
b. Data structures. Lisp list structures are represented as hierarchical data graphs, where sublists
are represented by lower levels in the hierarchy.
A list of n elements is represented by a graph of n
nodes, connected in sequence. If a list element is
an atom, its corresponding graph node contains
that atom as its value. If a list element is a
sublist of m elements, its corresponding graph
node contains a graph of m nodes representing
the sublist. Thus the list:
(A, (B, C, D), ((E, F), G))
is represented by the H-graph in Figure 6. To
handle argument transmission, certain auxiliary
data structures will be necessary:
1. OP, a node which contains a list, used as a
stack to hold operands;
2. ALIST, a node which conta:ins a list, used as
a stack to hold paired formal parameters
and their values.
c. Program structures. Like all Lisp program
structures not using PROG, the program graph
for the above function is a tree. Since the function
contains a recursive function call, the program
graph is recursive.
d. Operator type classes. See Table II. (V is the
820
Spring Joint Computer Conference, 1969
PR0G:
II
Tape(T):
*P9:
I I
co:
I
I
t
I
o
po:
right
WRITE(N1,H;H)
Cl:
right
C2:
right
C3:
P2:
MOVELEFT(H,T;H,T)
right
C4:
right
C5:
Head(H):
e
NO:G)
MOVELEFT(H,T;H,T)
Figure 5-Turing machine H-graph representation
function which, given a node, returns the value
of that node.)
e. Example. The Lisp function:
(LABEL (LAST (LAlVIBDA(X) (C~ND
«NULL(CDR X)) (CAR X))
(T (LAST (CDR X))))))) «A (B C) DE))
is represented by the H-graph of Figure 7.'
Note that the sequence of operations performed
during execution of the node LAST corresponds closely
to the sequence executed by an ordinary Lisp interpreter: first the formal parameter, X, and the actual
parameter, the list in C1, are paired on the ALIST,
then X is evaluated, CDR of its value is taken, and
Hierarchical Graph lYlodei of Semantics of Programs
821
Table II-LISP operator instances
Class
Name
Function
Operator Instance Form
CAR
CAR(0P; 0P)
CDR
CDR(0P; 0P)
NULL
NULL(0P; 0P, P)
PAIR
PAIR('Y, 0P; ALIST,J?)P)
VALUE
VALUE('Y, ALIST; 0P)
POPUP
POPUP(a; a)
01 *&00H*1 *&0f-0!
Figure 6-List structure H-graph representation
Let a = entry point of V(0P). Let (3 = entry
point of yea). Set yea) = V((j).
Let a = entry point of V(0P). Let (3 = entry
point of Veal. Set yea) = a graph obtained from
yea) by setting the entry point to E((j, t) and
deleting node (3. If E((j, t) is not defined, set
yea) = NIL.
Let a = entry point of V(OP). Set yea) =
Yep) = TifV(a)' = NILand = NIL otherwise.
Let a = entry point of V (0P) and (3 = entry
point of V (ALIST).
(1) Pushdown V (ALIST), let C = new entry
point (i.e., replace the graph in ALIST by
*C ~ (3 ~ ... where C is a new node and
*(3 ~ ... was the old graph).
(2) Set V(C) = the graph *1' ~ a.
(3) Popup 0P (i.e., replace V(0P) = the graph
*a ~ a' ~ ... by the graph *a' ~ ...
(1 ) Find first node Q on list V (ALIST) such
that l' = entry point of V(Q). Then V(Q) is
a graph *1' ~ a. Let C be a new node.
(2) Pushdown C onto list V(0P) (i.e., replace
*(3 ~ . ".. by *C ~ (3 ~ ... ).
(3) Set V(C) = V(a).
Popup list yea) (i.e., replace *(3 ~ l' ... by
*1' ~ ... ).
node 0P, where E is the value of the function LAST for
the given argument.
Fortran semantics. As a final example, consider the
problem of representing the semantics of the following
Fortran program:
PR0GRAl\1 EXAl\1PLE
NULL of that value is taken. The value of NULL, T or
NIL, is then used to control a branch. If T, the execution
ends after the CAR of the value of X is taken. If NIL,
then the CDR of the value of X is taken and execution
descends a level at the recursive node N, which contains
a graph of the single node LAST. The stack OP is used
throughout to communicate results between operator
instances. Execution of the above program H -graph
LAST will result in the node 0P containing a graph
whose entry point node contains the value of the
function; thus 0P: 1* E ~ NIL lis the final state of the
DIMENSI0N M(2, 5)
D02 I = 1,5
:.vI(l, I) = I
2 M(2, I) = IFACT(I)
END
FUNCTION IFACT(N)
K
=
1
822
Spring Joint Computer Conference, 1969
D0 2 J = 1, N
2 K = K*J
OP:
ALIST:
I
*XCI
IFACT = K
[:E:J
RETURN
END
Program:
LAST:/.
~
('
*IPAIR(X,0P;ALIST,0P)
As with Lisp, it is necessary to provide explicitly a
mechanism for argument transmission to subprograms
in the model of Fortran.
The H-graph representation may be constructed as
follows:
a. Atomic units.
u
= I U {=, ¢} U 0
where I = set of integers
{¢, ¢}
=
set of labels
and
o = the
union of the operator type classes
defined below.
i
IpOPUP(ALIST;ALIST)
Figure 7-Lisp function H-graph representation
b. Data structures. Simple variables are represented
as level 1 data nodes. Two-dimensional arrays
are represented by a graph (of levell nodes) with
edges labeled land 2 indicating rows and
columns, respectively, as M in Figure 8.
c. p.rog'i'U'ln structures. The program structures
correspond roughly to flow charts of the Fortran
programs. Subprograms are represented by sepa·
rate levels in the hierarchy of program graphs.
d. Operator type classes. See Table III. (V =
function which, given a node, returns the value
of that node.)
e. Example. The program may be represented as
the H-graph of Figure 8. Note that the loops
implied by the two D0 statements are made
explicit in the H-graph representation, and the
operations of array referencing and argument
transmission which are implicit in the Fortran
program become explicit in the model as the
operations REF2 and SETADDR-SET, respectively. Execution of the H -graph EXk"\1PLE
results in the first row of the array M being filled
with the integers 1-S and the second row with
the integers 1 !-S!.
Hierarchical Graph ~,fodel of Semantics of Programs
Data:
.~----------------------------~
M:
N:0 Nl{~ N2:(0 N5{~
I:
ARGl:
C0
C0
0 K:0 0
T:G) P:
J:
Program:
Figure 8-Fortran program H-graph representation
823
824
Spring Joint Computer Conference, 1969
Table III-Fortran operator instances
Class
l\T ___ _
.1.'1 <:LUlt:::
Opera Lor Instance Form.
ADD
MULTIPLY
ASSIGN
IASSIGN
MULTIPLY(a, (3; 'Y)
ASSIGN(a; (3)
IASSIGN (a; (3)
SETADDR
SET
SETADDR(a; (3)
SET(a; (3)
ISEQ
ISEQ(a, (3; P)
REF2
REF2(a, (3, 'Y; 5)
NO-OP
NO-OP(
ADD(a, (3; 'Y)
Sets V( 'Y) = yea) + V«(3)
Sets V( 'Y) = yea) *V«(3)
Sets V«(3) = yea)
Sets V (V «(3) ) = V(a) (where V«(3) is a single
node graph)
Sets V «(3) = the single node graph: *a
Sets V({3) = V(a') where a! = entry point node
of the graph yea)
~
•
~ets
~? ,~,
V(.t')
(=
= i
t
)
CONCLUSION
In this paper the general outline of a hierarchical
directed graph model of the semantics of programs has
been sketched, and a number of examples of its use in
modeling particular features of programming languages
have been given. lVlany interesting questions remain
concerning such models. Preliminary indications are
that t~e ~~del provides both mathematical tractability
and mtUltlvely appealing characterizations of the
semantics of programming languages. It remains to be
shown that these indications will remain valid as more
~xtensive ?evelopment is undertaken. At present, work
IS proceedmg along
. two main lines. On the one hand ,
attempts are bemg made to exploit the formal nature
of the model. One would like to prove theorems concerning the model which would allow one to derive
properties of particular program-data pairs given their
representation in the model. On the other hand models
of various programming languages are bei~g constructed' and the problem of constructing processors
~ased on the model is being investigated. One would
like to be .able to translate from actual programming
languages mto the model and vice versa. Given such
processors, one could then manipulate the H-graph
representation of a particular program according to the
formal theory to produce semantically equivalent
programs having particularly desirable properties.
Any model of the semantics of programming languages emphasizes in its structure certain semantic
features at the expense of others. The model based on
if yea) = V«(3)
;;e if V(a) ;;e V «(3)
Sets V(5) = node corresponding to a«(3, 'Y)
2-dimensional array a
N o-operation
In
hierarchies of directed graphs presented here is no
exception. Other models of semantics have tended to
emphasize flow of control in programs and argument
transmission to subprograms. Landin's lambda-calculus
model of ALGOL,! for example, emphasizes argument
transmission, restricts flow ot control to function
composition with recursion, and does not consider data
structure. The directed-graph model of ::;arasimhan 3
emphasizes argument transmission and flow of control,
representing the latter in a manner somewhat similar to
that used here. The model of this paper emphasizes the
structure of data and the hierarchical aspects of fimv
of control. It subordinates argument transmission by
incorporating no built-in argument transmission
method.
It is clear that the development and study of formal
models of the syntax of programming languages has
helped greatly to clarify the basic concepts in that area
and also has led to the development of better methods
for syntactic analysis in processors. It may reasonably
be expected that similar benefits will be derived from
the development of adequate formal models of the
semantics of programming languages.
REFERENCES
1 P LANDIN
A. correspondence between A. LGO L 60 and
Church's lambda-notation
Communications of the Association for Computing
Machinery 1965 8 2 and 3
Hierarchical Graph Model of Semantics of Programs
2 T B STEEL (editor)
Formal language description languages for
computer programming
North-Holland 1966
;3 R NARASIMHAN
Programming languages and computers: A unified rfletatMory
Advances in Computers Vol 8 F L Alt editor 1967
4 R W FLOYD
Assigning rn,eanings to programs
American Mathematical Society Symposium in
Applied Mathematics Vol 19 1967
5 J McCARTHY et al.
Lisp 1.5 programm,ers manual
Massachusetts Institute of Technology 1962
82,1
A flexible standard programming
system for hybrid computation
by WOLFGANG GILOI, DIETER BECKERT and HANS C. LIEBIG
Technical University oj Berlin
Berlin, Germany
Hardware structure of hybrid computer systems
The combined operation of analog and digital computers in hybrid computer systems requires a special
hardware interface because of the different modes of
operation and the different ways of data representation
in both computers. Generally, in such a symbiosis all
the functions of the analog computer, which are normally under manual control by the user, here have to be
under control of the digital program, except for one
case: once the digital program has started an analog
computer run, the analog computer is on its own.
In the case of combined simulation, i.e., if both computers operate simultaneously, from the viewpoint of
the analog computer its digital partner now plays the
role of a single, but very complex, computing unit to
which some analog signals go and from which other
signals come back.
From the viewpoint of the digital computer (and in
the following we will always adopt this point of view),
the analog computer and the interface are an entity
representing an external process which has to be controlled. We aElSume that this process may include the
various procedures listed in Table I, which all have to
be managed by the digital program. (For notational
convenience the word 'program' will always stand for
the digital program, while we shall call the analog part
of the entire program a 'setup.')
Table I
List of Procedures Which are Provided by the Hardware Interface N on-Time-Critical Functions of the
Hardware Interface:
1. Control of the analog computer modes by the
program
2. 'Run Time' selection (of one or more analog
computer runs) by the program
3. Signalization of the actual start of an analog
computer run (change of the integrator mode)
to the program
4. Sensing of the current mode of the analog computer by the program
5. Signalization of the end of an analog computer
run ('run time elapsed') to the program
6. Setting of potentiometers and subsequent checking by the program
7. Setting of analog switches by the program
8. Readout of analog outputs and potentiometer
settings under control of the program and transfer of these data to the digital computer
9. Sensing of the state of Boolean variables occurring in the 'logic box' of the analog computer by
the program
Time-Critical Functions of the Hardware Interface:
10. lVlultiplexing and sampling of analog data and
conversion into digital form; transfer of these
data into the digital computer at an arbitrary
rate (serially)
11. Transfer of Digital data into the digital-toanalog converters (in parallel), conversion (and,
in certain circumstances, smoothing) of these
data
12. Transfer of overload messages and other error
messages to the program
13. Transfer of external interrupts (arbitrarily
programmable on the analog computer) to the
program
All the procedures of items one through nine have to
be executed while the analog computer is in the HOLD,
RESET, or STANDBY mode. Hence, they are not very
time critical. On 'the contrary, the procedures 10
through 13 take place while both computers are running,
827----------------------------------
828
Spring Joint Computer Conference, 1969
thus imposing on the program problems of real-time
process management.
All this requires a digital computer that has process
control computer capabilities such as a fast communication I/O-channel (preferably with direct memory
access or a cycle-stealing mode, respectively), a hierarchic interrupt system, and control and sense lines. In
addition to the real-time clock which is part of any
analog computer, either the interface or the digital
computer has to provide a second real-time clock (defining the 'frame time' yet to be explained).
In terms of harware only, the interface (plus analog
computer) appears to the digital computer like one
more peripheral device, yet much more complicated
than the customary peripheral equipment. A much
higher complexity of the data flow to and from that
device is mandatory, varying between single control
bits or sense bits and words or blocks of words to be
transferred at a very high rate. In terms of the system
programming, however, this particular peripheral: device represents a complicated process, occurring in
real-time and manageable only if a specially designed
software interface is provided, which is as powerful as
the hardware interface.
The requirements for a powerful software interface and
its structure
The machine languages of digital computers which
have the above-mentioned process control computer
capabilities include instructions that energize control
lines or check sense lines, handle interrupts, activate the
I/O-channel and prepare its interlace hardware so that
a block of data words can be put in or out, etc. However,
it is much too tedious to program a hybrid computer
that way (despite the fact that it has sometimes been
done). In the case of the hybrid computer system
about which this paper deals, a program written in
machine code would require 35 instructions just for
selecting an arbitrary analog computing element, and
25 more instructions to read the output of that element and transfer it into the digital computer. The
setting of one potentiometer-including a subsequent
check of the actual setting and the handling of possible
. error messages-takes about 150 instructions in machine code. ~1any of these assembly language instructions are not just simple, mnemonic words such as the
arithmetical operation-code, but I/O-instructions which
have to be specified, e.g., by a never-to-memorize six
digit octal number. However, it is even worse if one
leaves the subtle tasks of interrupt handling to the
programmer.
All these problems may occur in process control
applications too, but for such a special purpose, a pro-
gram has to be written only once. Hybrid computer
system programming, however, combines the short-term
aspects of pure digital programming with the crucial
difficulties of real-time data processing.
So, first of all, one has to eliminate coding by machine
instructions. A comfortable software package for a
hybrid computer system has to offer the possibility of
writing any program in one of the customary problemoriented languages that programmers are used to, for
example, FORTRAN or ALGOL. Of course, such a
language has to be augmented by a number of special
subroutines. These subroutines take care of all the
procedures listed in Table 1. Furthermore, a special
executive program is necessary which handles the
synchronous operation of both computers and all the
interrupts and error messages which may occur.
But that is not sufficient. Analog computer operators
d,re used to having control of the entire system at any
arbitrary time instant. They are able to interrupt the
execution of a program in order to change potentiometer
settings as well as the whole setup and restart or rerun
thereafter the program. A hybrid computer system
should provide the same possibilities, but this cannot
be done while the system is under control of the digital
program. Conversely, the program may sometimes
need the help of the human operator (at least as long as
the automatic patching problem has not been solved
yet). The first demand to hand over the control of the
system to a human operator or to receive it back at any
arbitrary moment is unique. If this is granted, there are
actually three parties involved alternating in the control of the system: the digital computer, the analog
computer, and the human operator. This gives us
additional reason for using the term 'software interface' as a supplement to the 'hardware interface,'
meaning that only the proper design of both can make
a hybrid computer system manageable. Additionally,
some special utility programs are very helpful which
perform an automatic checkout of the analog setup
and of the entire system, thus detecting, indicating,
and diagnosing errors and component failures.
Hence, a hybrid computer system 'housekeeping'
software package should at least consist of the following
programs (names have been assigned to the various
programs which we can refer to) :
1. HARTRAN
2.
3.
4.
5.
(hybrid-procedure augmented
real-time FORTRAN)
HYTROL
(hybrid system control)
ACID
(analog computer and inter··
face diagnosis)
STATEST
(static test of the analog setup)
HYBRID LIBRARY PROGRAl\fS
Flexible Standard Programming System
HARTRAK denotes the set of all hybrid subroutines
by which the problem-oriented language (in our case a
special FORTRAN version) has to be augmented. If
the software interface is organized the way it will be
subsequently described, HARTRAN includes also the
executive program.· HYTROL provides the required
man-machine-interaction. ACID is a necessary augmentation of the debugging programs which are already existing for the digital computer. STATEST
enables the digital computer to check-out the analog
setup and to detect and indicate set-up errors as well
as component inaccuracies or failures. The HYBRID
PROGRA]vI LIBRAR Y encompasses a number of
hybrid standard programs which usually cannot be
found in the standard program library supplied with
the digital computer.
It is common practice to compose a complex programming system of several subsystems, because it gives a
much better way to implement, improve, maintain,
and change such a system. Doing so, one has to take
care, of course, of all possible interconnections between
the various subsystems. In order to facilitate the realization and the use of the subsystems, we define first of
all a certain set of modules which are common components in all of them. The modules occur in three
different forms:
PROGRAMMED OPERATORS (POPs)
STANDARD HARTRAN SUBROUTINES
(SUBs)
SPECIAL HARTRAN FUNCTIONS (FUNCs).
A POP is a subroutine that has a mnemonic name,
like any other macroinstruction, combined with a parameter by which the execution is defined. The SUBs are
standard subroutines of the HARTRAN compiler,
i.e., they don't have to be declared and can be called
by a CALL statement together with their name and an
arbitrary array of parameters. The FUNCs designate
procedures by which the output of an analog component
or a Boolean variable is fetched from the analog computer. The actual variable receives the name of that
function, and under this identifier it can be a member of
any arbitrary arithmetic or Boolean expression (like
the standard functions in the usual FORTRAN language).
SUBs and FUNCs, for example, take care of all the
procedures listed in Table I and others. POPs are
first of all used within HYTROL and STATEST, and
the ACID complex of test programs rely on SUBs as well
as on FUNCs. The special library programs are written
in HARTRAN. We will talk about these modules in
more detail when we come to the description of the
various subsystems.
829
What problem-oriented programming language
should be used? The standard FORTRAN language
(especially FORTRAN II) has some shortcomings.
For example, it does not provide the possibilities of
recursive call of subroutines, instructions for bit manipulation, and handling of interrupts. Notwithstanding,
for two reasons, we selected FORTRAX. The first and
most important reason was that FORTRAN is the most
often used programming language. The intention of
this paper is, however, not to describe just one of many
possible implementations of a hybrid system software
interface, but to propose a standard type of software
interface which can be implemented on any system.
Therefore, it has to be independent of particular assembler languages and it has to be based on the problem-oriented language most in use.
The second reason was an individual op.e. For our
computer (SDS 930), a special FORTRAN version
exists, called REAL-TI~rE FORTRAN, which does
include all the above mentioned features, especially
the possibility of connecting subroutines which respond
to interrupts. Of course, this is no comfort to somebody who has to rely on the standard FORTRAN II
version, but, even then, the construction principles
outlined in this paper can be applied. HARTRAN
would in this case stand for 'hybrid -procedure augmented FORTRAN,' and this programming system
may lack some valuable conveniences, but it will still
be feasible.
The organization of the software interface; HARTRAN
and HYTROL
The two possible states of a hybrid system
From the discussion in the above section, the concept of organization of a hybrid computer software
interface becomes quite obvious: The system as an
entity (hardware and software) has two possible states,
namely:
(I) the CONTROL state
(II) the RUN state.
In the CONTROL state a number of standard subroutines can be called within the framework of HARTRAN. The subroutines execute the special hybrid
procedures which we have listed in Table I under items
onB through nine, and some more. Additionally, by
calling a special subroutine by the name HYTROL,
control is transferred to the console typewriter or any
other arbitrary input device, enabling the human operator to interrogate or control the system. HYTROL,
on the other hand, has to provide instructions by which
a return to the HARTRAN program is possible.
830
Spring Joint Computer Conference, 1969
Another most important HARTRAN subroutine
called OPERUN switches the system from the CONTROL state into the RUN state. By the CALL
OPERUN statement two different processes are started
simultaneously:
a. An analog computer run is initiated (switching
the analog computer from the STANDBY,
INITIAL CONDITION or HOLD mode, to
the OPERATE mode).
b. In the digital computer, a procedure called RUN
is started that initiates a continuous scanning,
sampling and converting of analog data, a
manipulation of those data, and transfer of the
digital results into the digital-to-analog converters.
At this point we have to comment about the two
different classes of hybrid computation and their consequences on the organization of the data transfer between both computers. In the first class of operation,
both computers operate alternatively, while in the
second class, both computers execute a hybrid program
simultaneously.
For operations of the first class, the programmer
should be given the flexibility of a random input or
output of analog data; i.e., each I/O procedure has to
be programmed individually, and every time the multiplexer or DAC addresses can be arbitrarily chosen.
Unlike the first case, the second case may be extremely time-critical, especially if a combined simulation of a system with high natural frequencies has to be
performed in real-time. Since in this class of operation
an input or output sequence of analog data may occur
hundreds or thousands of times during one computation run, it would be unnecessarily awkward and time
consuming to program this by a random access which
needs to declare for every input or output the multiplexer or DAC addresses. Therefore, a procedure
should be available which performs automatically and
periodically a certain I/O-sequence. The first address
and the length of the input and output sequences have
to be declared just once (in a program header). All the
time during the execution of that program, a fixed
sequence of multiplexer input lines are scanned and a
fixed sequence of DACs are loaded periodically. If the
channel has the capability to transfer data blocks autonomously to and from the memory in a cycle-stealing
mode bypassing the CPU (we call this the interlace
feature), this particular I/O-mode provides not only
a most efficient way of programming, but also the
fastest possible way of execution.
HARTRAN subroutines are available for both ways
of inputting and outputting' analog data. It has to be
emphasized that this way of programming can be used
for any computer, while the actual subroutines, of
Gourse, depend on its specific structure. In the following;
we shaH find some more SUBs which are a result of the
specific hardware structure of our hybrid computer
system. But this is not contradictory to our claim of
proposing in this paper a standard software interface.
The only thing we have to try is to assume a hardware
structure as general and flexible as could be. The SUBs
and the corresponding POPs which may then be required for a less flexible system are a subset of what we
shall define in the following. The particular subroutines
which can be called as SUBs or POPs have to be written for the individual system anyway. Following this
philosophy, for example, it does not matter whet.her
or not the multiplexer inputs are equipped with parallel track-and-hold circuits, or whether the DACs
have two buffer registers or only one. Of course, the
corresponding subroutines have to be written differently, but the structure of the software interface and
the programming language are not affected. The same
holds for some unique hardware features of our system.
The control state and HARTRAN
In the following we shall list all the standard procedures which can be executed by flo HARTRAN program. On the lett side we list the respective format,
and on the right side we give a short specification of
the procedure. Furthermore, the SUBs are classified
by their function and a comment is made on each class.
Analog Computer (AC) Mode Control
CALL CON
.. the next run will be 'continuous
operation' unlimited in time
CALL CON H .. the next run will be 'continuous
operation' until the selected time
has elapsed; after that the AC
goes in 'hold' and continues when
a new 'operate' instruction is received
CALL REP
.. the next run will be 'repetitive
operation'
CALL REPH
.. the next run will be 'repetitive
operation'; after the first run, the
AC goes in 'hold' and starts the
next repetition run only on receipt
of a new 'operate' instruction
CALL ITR
. . the next run will be 'iterative operation'
Flexible Standard Programming System
CALL ITRH
.. see REPH and replace 'repetitive'
by 'iterative'
CALL STY
.. if the AC was in 'hold' it is now
switched to 'reset' or 'standby:
(both are synonymous)
CALL SRTN ('rt', 'ot', 'ht') . . setting of the 'normal' run timer
CALL SRTC
(~rt', ~ot', ~llt')
.. setting of the ~com
plementary'
run
timer, 'rt' is reset
time; lot' is operate
time; 'ht' is hold
time (all declared in
milliseconds)
831
Comment: 'addr.' may be any combina.tion of letters
and figures, depending on the AC address system;
.value' is a 4-digit decimal number following the decimal point (e.g.: P 127, .0178). For the error messages
see a later section (HYTROL). FGSET, of course,
only makes sense if the AC has digitally settable function generators. (In our system, we developed these
units ourselves.)
Control Lines
CALL SET ('x', 'y', 'z', ... )
CALL CLR ('x', 'y', 'z', ... )
.0
00
The control lines listed
as parameters of the
expression are set to
TRUE.
The controllineslisted
Comment: A model of the AC mode control is a
as parameters of the
(virtual) manual control that has six push-buttons and
six thumbweels. The push-buttons are labeled: continuous operation (CON), repetitive operation (REP),
iterative operation (ITR) , operate (OP) , hold (H),
and reset or standby (STY). By pushing one of the
fin:;t three buttons the mode of the next computer run
is prepared, and by pushing the OP button this run is
actually started. If, in addition to REP or ITR, the
button H is s~itched on, we have the 'single run' mode.
The combination of CON and H interrupts the continuous operation after the selected run time has
elapsed; the AC goes in the HOLD position from where
it can be restarted in order to continue the operation.
By the (virtual) thumbweels, the (normal) 'run timer'
can be set, defining the three phases of a repetition cycle
individually. The 'complementary run timer' setting
is only required for the iterative operation. Though
this mode does not make much sense in a hybrid computer system, it is part of most analog computers and
shall thus be taken into account.
expression are set to
FALSE
(CLR =
'clear').
Setting of Potentiometers and Function Generators
CALL POTSET
('addr.u', 'value u', 'addr.v', 'value
v', ... ) :: setting of an (unlimited)
number of potentiometers
CALL POTSETL
('addr.u', 'value u', 'addr.v', 'value
v', . . .) : : setting of potentiometers with a printout of the actual addresses and settings
CALL FGSET
('value 1', 'value 2', ... ) :: setting of function generators; 'value
1', 'value 2',. are the (fixed)
breakpoint values of the function
given as a decimal fraction of the
reference (e.g.: + .4875).
0
0
Comment: The control lines are used to set or reset
flip flops in the AC logic box.
Selection of Analog Components and Senselines;
Functions
POT ('addr.')
Al\1P ('OOdr.')
SL ('x', 'y', ... )
00
00
o.
The potentiometer with a named
address is selected, and its output
is a variable of the program identified by POT ('addr.')
The amplifier (multiplier, function generator, etc.) with the
named address is selected, and is a
variable of the program identified by AMP ('addr.').
The logical values of the sense
lines 'x', 'y', ... , are composed by
'and' and the result becomes the
logical value of the function.
Comment: As mentioned above, functions can be variables of arithmetical or Boolean expressions. One can
write, for example, a FORTRAN IF statement as
follows (x being another variable):
IF (AMP (47) - .5800 * X) 10, 10,20
If 'x', 'y', 'z', are addresses of sense lines, one can write,
for example, (without having to declare 'x', 'y', and
'z' as LOGICAL)
If (SL(I) . OR .. NOT. SL(2, 3) 1, 1,2
832
Spring Joint Ccmlputer Conference, 1969
where the expression of the IF statement is
SLI V SL2 ASL3!
Eniry io H YTROL
CALL HYTROL
.. The control and test program
HYTROL is called and the
system control is handed over
to the human operator
Frame Time Selection
CALL FTS('time') :: In preparing the run state, the
time of a digital computation
frame (see next section) is
selected by setting a special
real-time clock (' tillIe' = 3
place decimal number giving
the time in milliseconds).
DAC Mode Selection
CALL MODC
.. Simple conversion (the AC reference is also the reference
for the digital-to-analog converters (DACs).
CALL MODM
.. The DAC reference voltage can
be an arbitrary analog variable,
hence, conversion is combined
with an (analog) multiplication.
CALL MODI
.. The DACs combine the conversion with a straight-line segment interpolation (or extrapolation).
Comment: It is another special hardware feature of
our system that the digital-to-analog converters (DACs)
can operate in three different modes (we designed them
ourselves tor that particular purposel). The first mode
is just simple conversion. In the second mode the converters may be used as 'multiplying DACs' providing
the multiplication of the converted digital output with
any arbitrary analog variable. A considerable number
of analog multipliers may be saved, and the errors
may be reduced (since the lVIDACs are more accurate
than analog multipliers).
The output time fllllction of a usual DAC is a 'staircase' function, i.e., the output voltage is constant as
long as the digital input stored in the DAC register is
not replaced by a new one. In the third mode, our
interpolating (extrapolating) DACs replace the staircase function by a straight-line segment interpolation
(or extrapolation) between the data points, resulting
in a better (and smoother) approximation of a continuous signal of which the data points are samples. For an
interpolation, the program has to calculate the increments between a current output and its sucCessor. If
the successor is not available to the program, the inter·
polation must be replaced by an extrapolation based on
the current output and its predecessor. A variation of
the time interval between two data points (= frame
time) is automatically taken into account. If the digitalto-analog converters have only the DAC and MDAC
modes, the l\10DI subroutine is immaterial; if there is
only the normal DAC mode, all the SUBs of this sec·
tion are immaterial. The mode specification holds for
all DACs. If only part of them shall multiply, the
others have to be patched to the reference. If only
part of them shall interpolate, the mode is J\IODI, a..'1d
the ones which have not to interpolate receive simply
the increment zero. In our case, this is particularly
simple, as we have a 24-bit word format where the
first 16 bits are the value, and the last eight bits are the
increment .
Asynchronous Data Transje:r
CALL AD
('x', 'addr.x', 'y',
'addr.y'7' .. ) :: transfer of dat.a blocks from the
AC to the DC. 'x', 'y', ... are
variables or expressions of the
HARTRAN program identified
by the numbers of the multiplexer
input lines by which the variables
are fetched.
CALLDAC
('x', 'dest.x', 'y',
'dest.y', ... ) :: transfer of data blocks from the
DC to the AC. 'x', 'y', ... are variables or expressions of the HARTRAN program; 'dest.x', 'dest.y',
... are the destination addresses.
CALLDAI
('x', 'INCx',
'dest.x', ... ) .. transfer of data blocks from the
DC to the AC. 'INCx', 'INCy',
. . . are the increments of the
variables 'x' , ' y' , . . . between
two data points; for the other parameters see CALL DAC.
Comment: DAC has to be used in connection with
MODC or MODM; DAI is only used in connection
with MODI.
F'lexible Standard Programming System
Switch from the Control State to the Run State
CALL OPERUN :: The system is switched into the
run state, either for starting an
analog computer run only (with
no simultaneous digital operations) or for a combined operation of both computers.
- - - + - - - - - - one
dala inpul, AlOconversion a
li ..d painllflaolin9
paint transform
frame
833
----------40fo-----
dalo input;"
dolo
manipulation
idle
"'Iime
dolo autpuI
8 DlA
conv.rlion
---.time
~~I~.
output.
On?~o.9.
input.
o~~I.oll
outpull
..
"'!o!.,.
input.
frome time T , - - - - - 1
t-~- - - -
Comment: Most analog computers have the possibility to change all the -integr~tor time constants simultaneously by a factor 10 (e.g., by a' 10 times faster'
or a '10 times slower' switch). If this should be done
under control of the program, the OPE operator (respectively the OPERUN SUB) may include a parameter which specifies the respective integration rate.
This has the advantage, that nothing else in the program has to be changed. We suggest this as a possibility
but we don't feel that it makes much sense to have
this parameter under control of the program.
The run state
Figure 1 illustrates the general scheme of the RUN
procedure executed by the OPERUN subroutine.
Right after the start of the procedure by a CALL
OPE RUN statement, the subroutine sends (after
having executed some preliminary instructions) an
OPE instruction to the AC, hence starting an analog
computer run. When the AC integrators really start,
the AC sends a "start" interrupt to the DC causing the
begginning of the first computation frame. By these
means we obtain well-defined timing of computers.
Simultaneously, both real-time clocks (the 'run time'
and the' frame time' clock) are started.
Every time the selected frame time has elapsed, the
'frame time' clock sends an 'end ot frame' interrupt
(EFI) to the DC, indicating the end of a frame and the
beginning of the next one. Each EFI starts a combined
input/output of analog data blocks as illustrated in
Figure 2. Length and formation of the respective
Figure I-General scheme of the R U~ proceduce
frometimeTf _ _ _ _--!
~f------~ ~--~U~ itv:~-------
Figure 2-0rganization of a computation frame
block have been specified together with the various
source and object addresses by calling the DADC or
DADI subroutines to be explained in the following.
Eventually, the selected run time of the analog com~ .
puter will have elapsed. The AC goes at that moment
in the HOLD mode and sends an 'end of run' interrupt
to the DC causing the program to switch back to the
control state. The' start' and the' end of frame' interrupt are of the same priority (higher than the' end of
run'interrupt).
Some additional comments should be given on the
organization of a computation frame. Each frame starts
with an output procedure, whereas the outputs are the
results of the computations in the preceding frame
(in the case of the first frame they are initial values).
This happens as fast as the digital computer can put
out these data (in our system it takes two memory
cycles = 3.5J,ts for each DAC). The DAC settling time
(which in our case2 is about 0.5J,ts) is not relevant in this
context, as in fact the DACs could be loaded simultaneously if the DC could do that.
Right after the output sequence follows the input
sequence (for the current frame). Depending on the
throughput rate of the multiplexer/converter the ADC
may feed-in data at a lower rate than the DC could
handle. In such a case, one can use the idle time between two inputs for performing the necessary fixedpoint/floating-point transformation on the current
input. While we started with this approach, we have
now an ultra-fast multiplexer converter in our system
that has a higher maximum throughput rate than the
DC can handle. (This multiplexer/converter is at present the fastest commercially available device of its
kind and was developed by ourselves.2 It has a 15-bit
accuracy at a maximum throughput rate of 500,000
per second.) Therewith, we put in data at the maximum
possible speed of the DC channel and perform the
fixed-point/floating-point transformation later on.
Though the total execution time is not reduced, the
skewing errors become negligible, though parallel
8:34
Spring Joint Computer Conference, 1969
track-and-hold circuits (which "vould, in turn, introduce some other inaccuracies) are not used.
After the outputjinput sequence and the associated
fixed-point,ifloating-point transformations ha"'le been
finished, the execution of the computation frame begins. Depending on the chosen frame time, a time
interval follows during which the DC is idle until the
EFI occurs. It is at least very difficult, if not impossible,
to estimate the exact execution time a priori in order
to choose the frame time so that any considerable idle
time is avoided. If the computation frame, for example,
includes branching instructions or external interrupt,
the execution ti.--ne of a frame may not even be constant.
This dilemma is solved by a special procedure within
the RUN subroutine which measures the idle time,
(t.he DC is not actually idle, but counting clock impulses). The minimum idle time of a computer run is
stored and may be printed on request. Thus, after one
test run the programmer can determine the right frame
time. If a negative idle time occurs (i.e., if the frame
time chosen was too short) an error message is printed
in any case.
The part of the program which follows the OPERUN
statement and which constitues what we call the 'computation frame' may include any regular FORTRAN
expression as well as some particular SUBS. SUBs
which can be called within this program are listed as
follows:
Comment: CALL DADC and CALL DAD I can only
be called at; part of the RUX suhroutine. XAD = 0:
only transfer D-to-A; NDA = 0: only transfer A-to-D.
Error messages are given if illegal addresses or numbers
of data words are specified.
External Interrupts, Sense Lines and Control Lines
CONNECT SUB 'no'
(FINT('no') ... ) :: SUB 'no' is the name of a subroutine written by the programmer which is sensitive
to 'free' external interrupts
(FINT), i.e., the subroutine
is executed when the interrupt
occurs. Notice that SUB 'no'
is not a standard HARTRA~
subroutine.
CALL SET ( ),
CALL CLEAR ( ), SL ( ): See previous section
Comment: The sense line and control line SUBs are
used as in the control state. To write particular subroutines which are sensitive to external interrupts and
to connect them to the program by a simple CALL or
CONNECT statement is only feasible in special FORTRAN versions.
Return Into the Control State
CALL HOLD
Synchronous Data Transfer to andfrom the AC
CALL DADC
('DA', 'NDA',
'AD', 'NAD') : : data transfer in both directions
syncP..Ionized by the EFI according to Figure 2.
DA : first memory address of the
output data block
NDA : length of the output data
block
AD : first memory address of the
input data block
NAD : length of the input data
block
The DACs have to be preset
either to l\10DC or l\10DlVl.
CALLDADI
('DA', 'INC.',
'AD', 'NAD') .. like CALL DADC but with the
DACs in l\10DI.
'INC' : first memory address of
the block of increments
.. The analog computer is switched
from the OPERATE to the
HOLD mode and the system
goes into the control state.
CALL HYTROL .. HYTROL can also be entered
from the rU.I1. state, switching the
system necessarily to the control state.
Comment: If an overload or a channel error (erroneous multiplexer or DAC addresses or ADC overload)
occurs, an interrupt with highest priority is sent to the
DC, causing the system to return into the control
state. Either OVERLOAD or CHANNEL ERROR
is printed, and after that HYTROL is automatically
called giving the user an opportunity to check for the
error reasons or to restart the program execution.
Software error compensation
Intrinsic error sources of a combined computer
system are:
(i) the necessary sampling of analog values transferred to the DC and a subsequent imperfect
Flexible Standard Programming System
smoothing of the digital results which go to the
AC (the DACs approximate the theoretically
required ideal low-pass filter very poorly)
(ii) time delay between corresponding input and
output vectors because of the execution time
of the digital computation frame
(iii) time shift between the various components of
input and output vectors because of the serial
;n-nl1t /l"\l1t-nl1t
.&,..LI,.1'''''''1 Vu.VPu.u.
We call the respective errors' caused by these three
sources the 'sampling errors,' the 'delay errors' and the
'skewing errors.' The skewing errors can only be
avoided by appropriate hardware measures such as parallel track-and-hold circuits at the multiplexer inputs
and double-register DACs, or-as in our case-by an
I/O transfer rate that is so high that no appreciable
errors occur. Some authors have suggested reducing
sampling and delay errors by utilizing additional hardware in the analog computer, however, these methods
are tedious and too expensive to be of practical use.
Giloi has shown in an earlier papers that a much better
error compensation can be obtained by a digital filtering algorithm which is part of the computation frame.
This method reduces sampling and delay errors simultaneously by an arbitrary high degree and is very easy
to implement.
It has been shown in the quoted papers that the
error compensation is almost as good when using nonrecursive filter functions as in the case of recursive
functions, yet nonrecursive functions do not cause
stability problems. Therefore, HARTRAN includes
a 'filter' algorithm of the kind
G(z) = ao
+ alz-1 + 3.2Z-2 + asz-s
+ a.z-4 + 3.gZ-5 + aaz- 6
which may be executed in the context of the RUN subroutine by the statement
CALLECF
('ao', 'aI', 'at', 'as', 'ai, 'ai, 'as') :: digital error compensa tion filter
passed by all the
output-bound data
The maximum order of the filter is six, but by setting
some of the coefficients to zero any lower order may be
obtained. One important parameter of the filter does
not have to be declared, as it is the 'sampling interval'
which is equal to the frame time and, hence, is known
to the filter algorithm by the CALL FRA statement.
If the frame time is changed, the filter subroutine takes
835
this automatically into account. (For the values of the
coefficients 3.0, al, ... , a6 see Giloi's paper.) 3
The control state and HYTROL
By calling HYTROL the system is put into the control state (no matter in which state it was) and the
system control can be performed by the human operator in a conversational mode. The program begins the
dialogue by typing HYBRID CONTROL and in the
next line a C. That means that the user is asked to
speGify the control medium, i.e., the device by which
he wants to communicate with the system. If he types
TYI, he continues using the console typewriter. In the
case of a spacious installation or, even more, if the
digital and the analog part of the system are located in
different rooms (as in our case), it is very convenient,
if not inevitable, to have next to the analog computer
console a second typewriter which is selected by typing TY2. Card readers (CR) and paper tape readers
(PR) may also be used, but only in the case when the
system returns eventually to the HARTRAN program
(i.e., the last statement has to be either RET or BEG).
If an L is added to CR or PR, the instructions are
printed. Any other statement than one of the set {TYI,
TY2, CR, CRL, PR, PRL} typed after the C causes
a SYNTAX ERROR message as well as any other
violation of the HYTROL syntax.
Mter that, the user can start any controllable function of the system. For this purpose he has a set of
l\1ACROs at hand.
For the analog computer mode selection we have
the following set of yIACROs
{CON, REP, ITR, CONH, REPH, ITRH, STY}
corresponding with the SUBs of an earlier section. An
analog computer run in the selected mode is actually
started by typing OPE. This is in correspondence to
what the OPERUN subroutine is doing.
For the setting of a potentiometer, one has to type
POT 'name' 'value'
(blanks are arbitrary). The reader may notice that the
potentiometer address is now part of the name, as the
POPs allow only to specify one parameter (the value,
defined as in the POTSET SUB).
The same feature holds when the AC readout system
is activated by a MACRO. Here we write
SEL'name'
whereas, again, 'name' is the analog component which
836
Spring Joint Computer Conference, 1969
has to be selected (for example P 137, A 72). The output of the selected unit is converted and printed as a
i-place decimal number plus sign (e.g., + .dddd).
Sense lines and control lines can be checked (eRR)
or activated (SET/eLR), respectiveiy, by the fonowing set of MACROs
common but no individual overload indication
Diagnosing error messages are
OVERLOAD 'name'
.. if the AC has an individual overload indication,
'name' means the name
of the overloaded component
ADDRESS ERROR
.. this message follows a
POT, SEL, CHK, SET,
or CRL if the name
in this statement is none
of the legal names of all
the analog components,
sense lines, and control
lines.
{CHK 'name', SET 'name', CLR 'name'}
For the setting of the 'normal' and the 'complementary' run timers and. the 'frame time,' we have the
MACROs RTN'ddd',
OTN'ddd', HTN'ddd' .. (reset time normal, operate time normal and
hold tinlO normal)
RTC'ddd',k
OTC'ddd', HTC'ddd' .. (reset time, operate time
and hold time of the complementa phase)
FTS'ddd'
. . (frame time selection)
'ddd' stands in all cases for a decimal number which
specifies the time in milliseconds.
Finally, we have two l\IACROs which provide a return
into the HARTRAN program (which we may have
left by a CALL HYTROL statement). When typing
BEG :: begin
the HARTRAN program is started anew at the beginning, while by typing
SELECTION
I:vIPOSSIBLE
SERVO SETTING
IMPOSSIBLE
TRIED THREE
TIMES, DIFFERENCE ± .dddd
RET :: return
the HARTRAN program continues by executing the
SUB which follows the CALL HYTROL statement
(the point at which the program was left).
The execution of a procedure is actually started by
the subsequent carriage return. If a comma is typed,
the procedure represented by the l\IACRO in the preceding line is once more executed. HYTROL provides
some error messages and some diagnoses. Possible error
messages are
SYSTEM NOT READY"
if the analog computer
and/ or the linkage is not
switched on
SYNT AX ERROR
. . in case of any violation
of the HYTROL syntax
OVERLOAD
.. if the AU has only a
· . in this case the name in
the preceding MACRO
was legal but the associated component is not existing in this particular
installation.
· . follows a POT operator
if the servo does not work
· . the servo works, but
after three trials the dif,;,
ference between the nominal value and the actual
setting is still more than
0.04 percent (this threshold is arbitrary). The
maximum deviation is
printed.
The reader may notice that by the above listed
MACROs, any parameter of a HARTRAN program can
be arbitrarily changed, and thus, all control and possibilities of on -line debugging are provided. If the user
should decide to terminate the hybrid computation
(because he found a mistake in the program or a
component failure which cannot be repaired immediately, or for any other reason) he types.
.M
Flexible Standard Progranlming System
Hence, the monitor system of the digital computer is
called. The DC may start to execute any arbitrary program (or a batch of programs) under control of the
monitor. This program batch may have nothing to do
with the hybrid program, or it may contain standard
I/O programs which are used in order to process the
results of the hybrid computation (e.g., printer, plotter,
or display routines). If the HARTRAN program ends
with the last two statements
CALL HYTROL
:\1
the system returns automatically into the monitor
mode.
Time-sharing of the digital computer
With respect to digital computer utilization, hybrid
computation is extremely inefficient and, thus, expensive. The setting of a servo potentiometer for example requires some seconds, the setting of some tens
of potentiometers adds up to minutes, during which the
DC is idle. If the user is in the process of debugging his
hybrid program on-line, it is even worse. In the case of
an undebugged digital program, on the occurrence of
an error, this program is dumped out, and the programmer may think about his mistakes without locking the
computer. The hybrid programmer, however, will start
to use HYTROL (since he has this wonderful tool available) in ofder to find out what is wrong. During the
many seconds or minutes of meditation, he will hardly
release the system. The worst of all cases occurs when
he must halt to change his analog setup (as analog computer users are very likely to do).
If the monitor is loaded together with a 'background'
batch of programs, the user can at least immediately
restart the execution of the background batch (by the
~I operator) when he realizes that for some reason he
cannot continue with his hybrid computation. But there
are two problems: Once he has lost the access to the
digital computer it will become difficult for him to get it
back. The second problem is that in a so-called balanced
system, the DC has hardly core memory enough to
accommodate the resident part of the monitor, at least
one background program, possibly a compiler, and in
addition the HARTRAN program and HYTROL.
(OPERUN and HYTROL alone take about 2.7 K of
core memory.)
If the installation includes a rapid access disc or drum,
the second problem could be solved by swapping the
hybrid program for the backgorund process and vice
versa. From there it is only a minor step to time-share
the digital computer all the time the hybrid program
837
is in"the HYTROL mode. Since there are only two processes competing for CPU time, a relatively large time
slice can be allotted to the background program without causing discomfort to the user of the hybrid system.
The simplest way to implement such a system is to
modify HYTROL so that when HYTROL is called it
sends the C message and calls the monitor right after
that to start executing the background batch. After a
certain time (e.g., one second) given by a real-time
clock (e.g., that of the AC run-timer), the background
process is interrupted and HYTROL asks whether the
hybrid system operator has in the meantime completed
a HYTROL statement. If the answer is yes, this statement is executed and the system returns to the background process, as it does directly if there was no
HYTROL statement completed. If the statement is
RET or BEG, the background process is swapped out
and the entire hybrid program is swapped in from the
disc. Therefore, the digital computer is only exclusively
assigned to the hybrid process when the latter is in its
real production phase. :Notice that for the implementation of such a system only a small part of the entire
program package-namely HYTROL-has to be
modified, one of the advantages of the modular structure of our software interface.
STATEST
STATEST is a special program which executes automatically a static check of the analog setup, hence
detecting patching errors as well as failures or poor
performance of components. By virtue of a built-in
optimization strategy, the best suited test values are
automatically evaluated by STATEST. Everybody
who is familiar with the static check procedure on an
analog computer knows that this is a most crucial
point. In the case of STATEST, however, all that has
to be done is to give the program a description of the
analog setup (the analog part of the hybrid program in
treatment). As far as we know, these features are
unique.
The setup description consists of a list of connection
statements, one for each component, which are written
in the form of pseudo-equations. On the left side of
such an equation the name of the 'object' is listed the
output of which has to be checked. On the right side,
the names of all source elements are listed which contribute to the input of that particular unit, combined
by the arithmetic expression which this unit is performing. The names of the various units correspond
with the addresses of the analog readout system. VariabIes (represented by the name of theu source) which
are fed to inputs with gain factors different from one
Spring Joint Computer Conference, 1969
838
have to be multiplied in the equation by the respective gain.
In the case of a multiplier, for example, which may
have the name 1'.1[19 and which may multiply the outputs of summer 846 and of function generator F3; we
write
lV119 = 846
r
P2
* F3
(spanks are arbitrary). If the function generator input
comes from integrator 17, we write
F3
=
117'
F3 (17)
Hence, F3 denotes both the name of a component
(on the left side of an expression) and the corresponding
function (on the right side of an expression) which has
to be specified by a table and which has the source
element as argument. Potentiometers and digital-toanalog converters (DACs) are not source elements, but
are listed as multiplicative coefficients of the associated
variables, represented by their name and not by the
value to which they are set. Thus the setting of potentiometers and DACs may be arbitrarily changed without
any change in the connection statement list. The current settings can be found in the POT8ET list which
has to be read-in or typed-in anyway. Figure 330 gives
an example for one particular branch of the setup. In
this case, we have to write
117
--0--..........
= 10 * 116' + P35 * NR + 10 * 117' + F3 + S23
that the notation may be recursive if there
. Notice
'
a feedback from the output of the object to its in-
IS
PR· positive ref.-nee
NR· M9Qtlve referencl
Figure 3(a)-Example of a particular setup branch represented
by one connection statement
the values of the POTSET list. After that, it focuses its
attention on the first pseudo-equation of the list. As a
first step, it measures the output Vo of the object of this
equation and checks whether it is in the range
.05
Yref
5
Yo
5
Vref (Vref
=
reference voltage). (*)
This may not be the case, and thus, STATEST has to
take steps in order to enforce the validity of this condition. For this purpose, a search procedure is started
which goes through all the branches of the tree which is
a graphical representation of the input/output relations
put, except in the case of integrators (as in our example).
In the static check mode, all integrators are changed into summers, the output of which yields the (negative)
sum of all inputs, while the proper integrator output
is substituted by a test value taken from the reference
directly or via a potentiometer, or even from other
components such as, for example, DACs. This is indicated in Figure 3a, and in this case we have to extend
the connection statement list by the following two
statements
116' = PI
* NR and 117' = P2 * PR
etc. (PR = positive reference, NR = negative reference).
When STATEST is activated (after the complete
setup description, including the POTSET and FUNCTIONS list, was put in), it s\vitches the AC mode to
'static check' and starts setting the potentiometers to
-t>- Primitive
---©-- Terminal
Figure 3(b)-Logical representation of the connection statement
given in the text (Associated with the setup of Figure 3 (a)
Flexible Standard Programming System
of the particular unit under consideration. (For the
given example, such a tree is shown in Figure 3b. The
nodes of the graph are denoted by the algebraic operations and the branches by the name of the variables.)
The program checks all the potentiometers in the respective equation (the potentiometers that specify the
test values included) to see which of them has maximum
influence on the tenninal node when being changed.
Thereafter, the setting of the potentiometer for which
the object output is most sensitive is changed until
condition (*) holds.
As STATEST has to traverse through several
branches in order to find such a potentiometer, the operations of the intermediate nodes indicate the direction
of the change (e.g., in the case of a divider a coefficient
of the nominator would have to be increased in order
to increase the output of the unit while a coefficient of
the denominator would have to be decreased, and vice
versa).
In any branch of the tree, the search procedure ends
at the first potentiometer or a 'primitive' like the reference. In any branch, up to three components can be
taken into account (this is a matter of the available
core memory). STATEST does not care if there are
overloads in parts of the setup other than the particular
one which is currently under consideration. Hence, the
convergence of the procedure is always guaranteed.
Once condition (*) holds for the current object the
outputs of all the source elements are measured too,
and the nominal results of the algebraic expression
represented by the connection statement is calculated
and compared with the actual (measured) result. Any
deviation exceeding a given boundary e* results in an
error message together with a printout of the error
magnitude. The parameter e* is individually evaluated
by the program for each one of the respective objects
as a multiple of a common error level' E. Hence, the
number and gain factors of inputs of the object are
taken into consideration (e.g., a gain of 10 leads to an
E* that is 10 times greater than E, etc.). The basic 'precision parameter' E depends, of course, on the particular
analog computer and has to be declared by the user.
Eventually, when the program has gone through all
the connection statements, all potentiometers are reset according to the POTSET list. Since that procedure
is double-checked by the POTSET SUB, it is made
sure that no new errors are introduced after the STATEST procedure has been finished. There are some more
important details of this very sophisticated program
which cannot all be mentioned in this paper. Our cur-.
rent STATEST version takes 10K of core memory for
the interpreter plus some additional memory space
for the connection statement list (approximately 1K
839
for a typical 100-amplifier-program). But it could
easily be shortened to run on an 8K configuration.
STATEST inbludes also a routine which searches for
hidden algebraic loops and gives a message if there is
one. Furthermore, it can be easily connected with a
program that calculates the setup (such as APACHElO).
Of course, STATEST is only loaded into core when
needed.
ACID and the PROGRA1itI LIBRARY
Most of the interface and analog computer functions
could be checked by using HYTROL, but not all of
them. Furthermore, if one wants to check out systematically the entire system and its reliability, it would
be much too tedious to do it that way. All these tasks
have to be automatically accomplished by special
test programs. Naturally, the number and kind of such
programs depend on the specific structure of the analog
computer and the hardware interface, so that it is not
possible to suggest a general concept as in the case of
the operating system. K otwithstanding, we will give in
the following a list of the ACID programs available and
a short description of theIr function in order to indicate
what these programs are about. It is almost needless to
say that these programs use the same modules (SUBs,
POPs, and FUNCs) as all the other parts of the software package.
SELEC :: Test of the AC selection system (ACSS).
Selects for a designated number of times
every AC component. Each time the actual
contents of the ACSS address register is
checked via a sense line feedback. In case
of a deviation, an error message is printed
together with the actual address and
number of iteration. It is also printed if
the selection of a component is impossible
e.g., if this component does not exist.
2\10DE
.. Test of the AC mode control. All possible
AC modes are activated, and the actual
mode is checked by sense lines.
CLOCK . . Test of the AC run timer and the frame
time clock. Both timers are set so that the
ratio of the run time with respect to the
frame time is an integer greater than one.
The number of end-of-frame interrupts
(EFIs) which fall between a 'start' and a
'end of run' interrupt is counted. If this
number does not correspond with the time
ratio, an error diagnosis is given. The procedure is executed for various run time
and frame time clock settings.
840
READ
POT
Spring Joint Computer Conference, 1969
.. Test of the AC readout system. Test
values are given via a DAC into the AC
readout system and read back via the
ADC into the DC (the AC readout system
has a special dummy address for this purpose). Deviations which exceed a designated level are printed together with the
DAC and multiplexer address used.
.. Repeated test of potentiometer settings.
Arbitrary parameters are the number of
repetitions, the increments of the pot settings and an error threshold. The program sets every pot to a certain sequence
of values starting with zero and increasing
by tHe chosen increment (until .9999).
This procedure is repeated for a selected
number of times. Eventually, a list is
printed listing the name of the pot and the
number of the iteration for each in which
the error threshold has been exceeded.
Additionally, the relative frequency, m~an
and variance of. all listed errors are
printed.
RUNI
.. Test of the system interrupts under different AC modes. The number of EFls is
counted which occur in a given time interval and the content of the interrupt cells
is checked. Errors are diagnosed.
LOGIC
.. Test of sense lines and control lines (via
closed loops which have to be patched on
the AC's logic box)
pared. Errors are listed, together with all
required information.
IDAC
.. Test of the interpolating DACs.
It is even less possible to give a general concept of the
required LIBRARY PROGRAl\1S as these depend
essentially on the requirements of the users. Programs
for parameter optimization routines, function storage
and reproduction (with and without delay), fast
FOURIER transform, statistical parameter estimation,
etc., etc., should be mentioned.
It should also be mentioned that writing the digital
part of a simulation program is in our case facilitated by
a block oriented digital simulation language which we
have developed and which we call SIESTA.8 SIESTA
is a superset of the SCi-CSSL Lariguage,9 and our
SIESTA compiler was one of the first implementations
of CSElL.
ACK~OWLEDGlVIENT
The authors would like to express their grateful appreciation to the :\1essrs W. Franke (who wrote OPERUK
and most of the SUBs), W. Woletz (who wrote HYTROL), and R. Siol (who wrote most of the ACID programs) for their very valuable contribution to the implementation of t.he system. They are also indebted to
Mr. 1\1. E. Connelly, NL!. T. Electronic Systems Laboratory, for his helpful and encouraging suggestions.
REFERENCES
\V GILOI
H ybl'ide Rechnersysterne
IOAR
.. Test of the I/O-address register in the
interface and the multiplexer and converter address decoding.
LOOP
.. Test of the data transfer to and from the
AC. The DAC outputs are connected
with the multiplexer inputs.. Various values
are given out via the DACs and received
back VIa the multiplexer-ADC. Any
difference between the original value and
its received echo which exceeds a preselected error threshold is printed wi th the
statistic::! of 9,11 t.he tri9Js as in POT,
Telefunken-Zeitung Jg 39H 1 1966 82-100
2 W GILOI H SOMMER
PHENO-A. new concept cJ hybrid computing elements
Proc F J C C 1967 23-31
3 W GILOI
Error-corrected operatio'NF of hybrid computer
Proc 5th International Conferenee of AICA Lausanne 1967
4: SCIE~TIFIC DATA SYSTEMS
Real-time FORTRAX II manual
5 W WOLETZ
HYTROL--ein Verkehrsprogramrn fur hybride
Rechenanlagen
Diploma Thesis Techn University of Berlin
Inst of Inf Proc 1968
6 W FRANKE
Ein Betriebssystern fur hybride Rechenanlagen
l\IULT
.. Test of pairs of IVIDACs, One ]VIDAC is
set in increments of .01 between 0 and 1.
Its output IS multiplied by a second
l\1DAC (which has a constant digital input). Kominal and actual results are com-
Diploma Thesis Techn University of Berlin
Inst of Inf Proc 1969
7 G BEKEY W KARPLUS
Hybrid Cornputation Chapter 7
J Wiley and Sons Inc New York 1968
H P HECREN BEHG
Flexible Standard
Sf ESTA. -A CSSL-implementalion
Internal Report Techn University of Berlin
Inst of Inf Proc 1968
9 The SCi continuous system simulation language (CSSL)
SIMTJLATIO~ Vol ~) Xo 6 December 1967
10 C GREEX H D'HOOP A DEBROlTX
A.PACHE- Breakthrough in A.nalog Computing
IRE Trans EC-ll ()ctober 1962 699-706
QAl
vcr.L
A real-time programming language and
its processor for digital control of
industrial processe;
by LIANG·LIANG
INTRODUCTION
The acceptance of digital control for large scale industrial processes, such as chemical, refining, power, and
material processing is a step towards total automation
and a further improvement in control system performance. Process control oriented programming languages provide a control engineer with means to learn
and hence set up, modify, and operate a control system
with ease. They eliminate the complication of involving
a programmer, who generally has little knowledge about
process control engineering. The result is a reduction in
time and dollars for digital control system generation.
Such a language and processor has been designed and
implemented. It has many desirable features: process
control engineering orientation, independence of machine, modular structure, convenience of capability
expansion, and conversational mode for on-line design
and modification. The basic concept to implement a
digital control system is borrowed from analog control.
The system is created by connecting elementary control modules together. The rationale is that most experienced process control engineers and field-proven
control schemes are still heavily analog control oriented.
On the other hand, the language can readily be used to
implem~nt highly interacting, nonlinear, feedforward,
self-tunmg types of control. Thus the language serves
an immediate need in the process control field while
awaiting the breakthrough of large scale multi-controlvariable manipulation at the regulatory control level
which seems still remote for actual field application.
Speci ficalian
Format
A control system is to be implemented modularly. The
basic elements are statements and functional blocks.
Each block may consist of a number of statements.
p
Prefix
OP
Operator
A
B
I
c
Operands
Comment
Figure 1---8tatement format
The basic format of a statement is a binary operation
with an operator and three operands. For example:
ADD,A,B,CmeansA + B = C.
The prefix could be the label of the last statement of
a loop or a transfer entry. Comments could be added
following the operand field. Such a statement format
simplifies the syntax of the language and hence the
source compilation. Although the format is simple, it is
wholly adequate for this application. A variety of operations can be implemented. These include: arithmetic,
control and logic functions, I/O handling, matrix, and
decision table manipulation. The resulting control system resembles an analog control system with statements replacing analog control modules and blocks of
statements replacing cabinets of control modules.
Program modularity has further advantages for pro~ramming and man-to-man communication, adaptabilIty to change and expansion. Beyond these convenience
aspects, this organization makes it possible to implement some important features, such as block execution
according to priority (handling emergencies), sequence
(process startup), sampling period (process normal
control), and time-sharing (to utilize computer free
time), on-line design and modification, and block execution time estimation.
Control system decomposition
It is left to the judgment of the control engineer as
to how a control system should be decomposed. Consider as an example, a control system is to be designed
843--------------------------------
844
Spring Joint Computer Conference, 1969
Consistency
Stock Total llire
Flow Head Speed
Headbox
Level
~1easurement
Net Stock
Flow
YT8
transmit
pulses (-3 V to 0 V to -3 V) when an ungated pulse input is
pulsed, or when a gated pulse input is pulsed with the level input
at 0 V. Pulse inputs P and Q are for automatic data-channel
operation (Figure 8)
Figure 7b-The X-buffer functions as a counter whose increment
size is controlled by S-register bits 12 and 13
pulses and subdevice bits corresponding to each instruction gate data into the. display registers. Note the
following special features:
1. Instructions with subdevice bit 12 = "0" will
move the display point without brightening. This
is useful for creating gaps in lines or curves
without any need to reload the intensity-controlling ~regjster.
2. Instructions clearing either X or Yare useful
= 8
Beam intensity
Spares
The large number of different instructions possible
with only two device selectors has also permitted us to
transfer data into two additional DACs CU and V
regjsters in Figure 6), which are intended for use with a
four-channel strip-chart recorder but could, in principle,
be employed to generate a different display on an additionaloscilloscope.
Automatic data-channel operation
While program-controlled display instructions can
conveniently alternate with other processor operations
(computations and data taking) through program
branching and interrupts, much more elegant and efficient display operation may be possible through direct
memory access with the automatic-data-channel hardware available with many modern small digital computers. Our display is, therefore, designed to work with
one of the cycle-stealing data channels built as a standard feature into the PDP-9. Only two processor instructions are needed to specify the starting address and word
count of a block of memory associated with a display
picture. The processor then steals memory cycles to
output an 18-bit word directly from memory whenever
an external data-request pulse is sensed. When a complete
Graphic Display/Plotter for Small Digital Computers
OIC/TAL
COMPVTER
STEAL
WR/TE
REt;PeST
~""TA-
CHA4/#EL
HAR.PWARE
.PRIORITY
CI{'ANT
(MEMORY
.tIOPRESS
CO/vTROL)
_$fi4RT//v~
""~~ReSS
/N
CEAlTRAL
'pA'tJCESSt?,f'
BiOC,K'
CPHPLETE
I" -
D..pA£-'P..4M
-
/#TERFACE
eye;"LE -
~AlTERRtlP.T
I
/NTER/"ACE
AS",,,,..
REt?PEST M~T/WIA'ATtM
PtliSES jl'AAlVSTABL E
iO~/C
~"pEt?uEM:r)
FOR
"
LJA?;4
C#AAlIVEL
(OEC W/tJ.¢
CARO)
-..
1-"
1
~
_
TtJ .£J/S.PLAY
PEJ4CE
SELECTOR
(ACT/YATES
__ • _____ .",)
\
I
"A~'
4LOot')
I/tJ ,oATA B/TS
BITtJ----I
/N~NT
/t:JT ,P//LSES
Ft7,p PAC LOA .o/~)
4R/G'#r£N'/N~ c/A'Cv/rJ'
ENABLE ItJT PULSE
Ft7' S-'F(;/ST£R
L()AP/#G'
RECt:JG'A'/17t:J#
CArE
locations corresponding to display points can be updated
at any time between data-channel outputs. While datachannel word transfer rates as high as 250,000 words
per second are possible, we usually set the transfer
rate (which is determined by a simple astable multivibrator clock, Figure 8a) at about 100,000 words per
secorid, both to give the computer a chance to compute
and to permit cleaner line-segment generation.
On the face of it, data-channel outputs involve only
rlnfn ~/'fl,.rlQ
(in AUI'
(l!:H:!t:>
n<;\{l"\z-",rl
VVVI
....,\...4.........
'"""'-' ....... l"'''''''
.........:a..''''''-4 15Lhit.
~'-NIV'-Af
_ _ _~, (RESTARTS ....._ _ _~
HR/O~/C PArA :"C#A#A£L
,fEtQVEST Pl/LSES FRoN
ItS rAII,-£" Nl/LT/8RATVR
TO PATACHANN'EL
FLAt;
ENtJCJF
BLOCK"
FRt:J,w
COMPUTER
,a-/c
POWER CLEAR
fOT /
Figure 8a-Automatic-data-channel operation. Processor instructions set the number of words and the starting-word
address in a display block and enable the display clock. From
then on, data words are transferred to the display on each displayclock request pulse without any need for processor instructions.
A data-channel- end-of-block signal is used to interrupt the
processor, which then restarts the sequence
Figure 8b-Recognition gate for data-channel S-register transfers
(see text), and end-of-block interrupt flag
block of, say, 2,000 data words is finished, an end-ofblock pulse can be used to interrupt the computer program and to reinitiate the block transfer (Figure 8a).
No other display instructions are required, and memory
855
\Af'O;J'
,
...........
..L'-J
...., ........
Y
~
.... ,
V
~
JoJ, Ant:>
.....,.L.........
UTAl'"rl",
'f'f " ' ..........
corresponding to each display point). Since the data
channel cannot transmit different display instructions,
it would seem that we have lost the ability to change
between the LINE and POINT display modes and to
vary display intensities. If one had more than 18 bits,
say with a 24-bit computer, one could use extra data
bits as control bits, but this is not possible with the
18-bit PDP-9 and similar small processors. A special
trick, however, permits the use of data-channel produced
data words for control purposes. We recall that, with the
2's-complement code generally employed with DACs,
the largest positive 9-bit excursion is 011111111, corresponding to + 9.98 volts, while the largest negative
excursion is 100000000 or - 10 volts. This maximum
negative excursion, thus, has no positive counterpart
and is, in a sense, redundant. We will, then, employ the
last 9 bits of an 18-bit data word of the form 100000000sssssssss (Y = - 10 volts) to set our 9S-bit register bits,
rather than for positioning the CRT beam. Referring to
Figure 8b, a simple recognition gate detects the fact
that the first 9 bits are 10000000(1 and gates the remaining bits into the S-register to control the beam intensity
and the POINT or LINE mode of subsequent display
points.
A second mode of data-channel operation employs
the X-buffer/counter to plot anyone-dimensional array
automatically against its index, without 'Word packing.
Operation with external oscilloscopes
To permit the use of our display interface with external cathode-ray oscilloscopes and recorders, the X and
Y deflection voltages, an intensity-control voltage, and
one of the S-register bits are brought out to front-panel
terminals (Figure 2a). In particular, the display can
thus operate with a standard five-inch oscilloscope
equipped with a Polaroid Land camera to produce
quick hard copy. For class demonstrations and visiting
admirals, the display also operates with a large 24-inch
display oscilloscope at reduced plotting rates. Depending on the external oscilloscope used, the beam-intensifying signal can be amplified and/or inverted.
856
Spring Joint Computer Conference, 1969
Operation with xy recorders
To obtain hard copy directly at low cost, one can
simply apply the X and Y deflection voltages to an
xy recorder (servo table) at a suitably low word rate. For
more flexible recorder operation, however, we added
two additional digital-to-analog-converter channels
(U-and V -DACs and registers, Figure 6) .
For servo-table recording, one of the S-register bits
is brought out to control the recorder pen-lift solenoid,
with the pen DOWN whenever the display instructions
call for the LINE mode (Figure 230). The instruction
DUVL produces lOT 2A (Figure 730) to feed the 9-bit
U and V registers with "packed 18-bit words for xy
recorder operation. Since the relatively slow servo
recorder cannot plot more than 5 points per second, the
instructions must be tied to a suitably slow real-time. clock interrupt routine; slow data-channel operation
in the manner of Figure 8 is also possible. For the same
reason, the 160 pF delay capacitors shown with the X and
Y DACs in Figure 230 are replaced with 5 JLF plug-in
capacitors in the U and V channels, so that line segments are drawn with a time constant of 0.1 sec.
Figure 10 shows a permanent record prepared with
the new display unit.
Operation with stripchart recorders
For simultaneous ploUing of up to four time-history
records on a multichannel strip-chart recorder, the X;
Y channels * and the U, V channels are alternately fed
packed 18-bit words at a clock-controlled combined
maximum rate of 200 words/second. Such multiple
time records are especially valuable for recording
variables in digital simulation of dynamical systems.
Figure 9-Cathode-ray-tube displays using the PDP-Y data
channel at 125,000 points/second: POINT mode (a), --LI~E
mode (b), and mixed POI~T and LI~E mode (c)
Discussion and follow-on program
Figures 9 and 10 show examples of display operation.
As noted earlier, our display was originally intended
mainly to produce solution curves and phase-plane
diagrams for on-line simulation of dynamical systems.
As it turned out: the display is very useful for producing much more general pictures (Figure 9), so that we
are planning the addition of a light pen and protractor
dial, plus SKETCHPAD-type software6 for computeraided drawing operations with the PDP-9.
The most useful feature of our simple display is the
possibility of refreshing the display with packed 18-bit
words from the standard automatic data channel of the
18-bit PDP-9. Since these 18-bit words fully utilize
* The small capacitors in the X and Y channels (Figure 2a) have
essentially no effect at the 50 to 200 Hz word rates used for stripchart recording.
Figure lO-Hard copy produced on a Moseley xy recorder
(servo table) in the LINE mode
Graphic Display/Plotter for Small Digital Computers
their PDP-9 registers, we can afford to eliminate the
hardware and programming complication of a displayrefreshing core or delay-line buffer. With processor and
display sharing a common memory, our automatic
data channel can do much more than refresh a single
display. The channel can also transmit and mix several
displays or parts of displays (curves, figures, characters),
each corresponding to a memory block with a programselected starting address and block length. 3 Indeed, a
block or blocks can be displayed with the automatic
data channel while the processor modifies another
portion of the display.
The Dertouzos line-segment-generating technique,
as modified by our intensity-compensating circuit, was
thought to be especially suitable for curve interpolation and stroke-implemented characters. In our actual
operating experience, though, most users have employed
the LINE mode mainly for servorecorder plots; they
seem to prefer the simpler programming possible when
using only the POINT mode for CRT display. If
we need not alternate LINE and POINT modes it is,
for instance, simpler to obtain "incremental" display
operation, with successive packed words
(HI
X,
HI
Y) = (k X
857
transfers. This is mandatory with 12-bit computers
(like the popular PDP-8 series), and even speeds up
some PDP-9' programs, since no word-packing is
needed (see Appendix A for explicit programmed-datatransfer routines). It is only fair to state, though, that
all our users to date have preferred packed-word
operation with the PDP-9, so that we could have
omitted the entire X-buffer logic (including our extra
device selector).
ACKNOWLEDGMENTS
The display system described in this paper is part of a
continuing study of digital-, analog-, and hybridcomputer simulation at the University of Arizona.
For their support of this study, we are very grateful to
the National Aeronautics and Space Administration
(Grant N sG-646 and Institutional Grant to the University of Arizona), the National Science Foundation
(Grant GK-1860 and Institutional Grant), and to
Drs. G. W. Howard, R. H. Mattson, D. L. Patrick,
A. B. Weaver, and E. N. Wise of the University of
Arizona for allocating institutional-grant funds and
University resources.
+ kAX, ky + kaY)
2's-complement-accumulated in the PDP-9 accumulator before transmission to the display or to a datachannel block.
In view of the popularity of small I6-bit digital
computers, we have also tried the display with our
9-bit DACs restricted to 8-bit operation. A display
thus obtained with packed I6-bit words has, of course,
less resolution than the I8-bit display, but still appears
to be acceptable for many purposes. This opens the
interesting possibility of combining our display system
permanently with a small I6-bit processor as a moderately sophisticated stand -alone display unit
The provision of the X-buffer/counter in our display
permits display ope:ration with separate X and Y data
REFERENCES
1 M L DERTOUZOS
PHASEPLOT: An on-line graphical display technique
IEEETEC April 1967
2 G A KORN
Digilal-computerinterface systems
Simulation December 1968
3 P DP-9 user handbook
Digital Equipment Corporation Maynard Mass 1967
4 Logic handbook
Digital Equipment Corp Maynard Mass 1968
5 Small Computer Handbook
Digital Equipment Corp Maynard Mass 1968
6 I E SUTHERLAND
SKETCHPAD, a man-machine graphical communication
system
Proc S J C C 1963
APPENDIX A: BASIC PDP-9 DISPLAY ROUTINES
LAC X
DXB
LAC Y
DYST
LACY
DYSI
/load accumulator with X
/load X -buffer with X
/load accumulator with Y
/transfer X-buffer and Y, and display
/load accumulator with Y
/increment X-buffer, transfer
IX-buffer and Y, and display
2 ~sec
4
~sec
2 ~sec
-
4
~sec
12
~sec
2
4
~sec
~sec
() ",sec
Spring Joint Computer Conference, 1969
sriS
LAW 170008
AND Y
DAC TElVIP
T
A~
.1..Ul..V
v
~
CLL
LRS 9
ADD TE:NIP
DXYS
/load accumulator with mask
/mask last 9 bits of Y out
and sa.ve result.
/
/load acclli'1lulator with X
/ clear the link *
/ shift 9 places *
/ combine with Y
/transfer X, Y, and display
1 J.lSec
2,usec
2 ~sec
2 #Lsec
1 #Lsec
6 #LSeC
2 #Lsec
4 #Lsec
---20 #Lsec
LAC XY
DXYS
/ deposit X, Y in accumulator
/transfer X, Y, and display
2 p,sec
4 #Lsec
6
* not needed if X
was scaled previously
~sec
Stability contours for the analysis of
analogi digital hybrid simulation loops
by R.VICHNEVETSKY
Electronic Associates, Inc.
Princeton, New Jersey
INTRODUCTION
The use of hybrid computers for the simulation of
dynamic systems has focused interest on the ill-effects
of sampling and digital execution time upon solution
accuracy. Techniques have been proposed for the compensation of these effects by various authors.l,a ,7 However, there has been a noted lack of common denominator available to compare the relative merits of these
methods of compensation. As a rule, one may observe
that quality criteria used to evaluate different compensation methods have been local rather than global,
and the resulting compensation algorithms are therefore largely tuned to whatever quality criteria has been
selected a priori.
As an example, a recent paper by Mitche1l6 shows
that compensation techniques that provide an improvement for slightly damped or undamped systems are
indeed detrimental when applied to the simulation of
highly damped systems. But, at just about the same
time, a paper by Deiters and N omural evaluates the
quality of compensation methods on the only merits
of their performance in the simulation of completely
undamped systems (the circle test).
The preceding remarks indicate that more meaningful criteria should be developed to describe the quality
of the compensation over the whole complex plane of
natural modes of the system being simulated. Such a
criterion is, at least partly, provided by the Stability
Contours method which is developed in the sequel of
this paper. In essence, this method provides regions
in the complex plane where the roots or normal modes
of the simulated system must lie to ensure stability of
the simulation.
An interesting conclusion is reached by consideration
of these stability contours; namely, that compensation
methods based on Taylor Series extrapolation fonnulae
improve stability for the simulation of undamped or
-------------------------------------------
slightly damped systems, but decrease stability for
systems which are heavily damped (i.e., have roots
which lie closer to the real negative axis than to the
imaginary axis).
Reference has been made by previous authors to
problems encountered in the simulation of helicopters
and STOL aircraft. 6 In that instance, one is faced with
a system which is very lightly damped in one regime
(during hover or low speed) and becomes heavily damped
in another regi;me (when speed induced aerodynamic
forces come into play). From the standpoint of a global
analysis such as that provided by the stability contours
method developed in this paper, it would seem that
none of the compensation methods suggested by previous authors are adequate for the whole range of
behavior of the aircraft (unless, of course, the sampling
rate is kept high enough to satisfy worst-case stability
conditions of the simulation). To the contrary, it seems
appropriate to utilize" adaptive .. compensation schemes
that will correct by extrapolation when the simulated system is lightly damped, and return to nonextrapolation (or some other algorithm) during flight
regimes inducing heavily damped modes of behavior.
A model of hybrid loops
A typical situation encountered in simulation is
that in which the differential equations of a dynamic
system are integrated on the analog section of a hybrid
computer, and part of the non-linear operations involved in the implementation of the right-hand side of
these equations is implemented in the digital section
of that computer. In particular, this situation is found
in the simulation of aircraft where the non-linear aerodynamic forces and moments are computed digitally,
and the corresponding integration of the equations of
motion is implemented on the analog (see Reference 10).
The sampling and digital delay occurring in the hy859~-------------------~------------------
860
Spring Joint Computer Conference, 1969
nlNPUTS
II
ANALOG
COMPUTER
dx
dt
=w
n OUTPUTS
,
I
where regime or geometry change relatively slowly is
well accounted for by the model of Figure 1.
Stability (the uncompensated case)
In an idealized implementation of the hybrid simulation of the system described by equations (2.1), we
assume that all algebraic computations are perlonned
on the digital computer, while all integrations with
respect to time are taking place on the analog.
We also a§sume that a constant sampling rate at is
used, and that all analog-to-digital, and digital-toanalog, conversion operations are sL.llultaneous at
sampling time (which corresponds to the use of sample/
hold integrators in the A/D direction, and doubleregiS+ueI'S in the D/A direction). We denote by Xi t.he
value of the vector of variables x(t) at time t = t i =
w(t)
DIGITAL
COMPUTER
a CONVERTERS
w= ax
Figure I-A simplified model of a hybrid simulation loop
brid loop are conducive to instability in the simulation.
Although simplified, a model which pennits a detailed
analysis of this phenomenon is that represented in
Figure l.
This configuration corresponds to the simulation of
a system whose set of differential equations is:
iat.
Using zero-order hold, the output of the digital-toanalog converters are step-1ike functions. These functions remain constant over one sampling period, and
can be expressed by (in the uncompensated case):
where x i-k is the value of x at time t i-e.
Thus, kL\t is the explicit value of the total sampling
and digital execution time.
In view of the previous assumptions, k shall always
be an integer, and will often be equal to unity.
During the time interval (t i , ti+l) , the output of the n
integrators of the analog computer are linear, and the
following expression can be derived:
(3.2)
or, in simple matrix notations:
dx
dt = ax
The solution x i thus satisfies the finite differences
equation:
(2.1)
This set of equations may either describe the whole
problem at hand, or describe the behavior of error
propagations in a more general, non-linear hybrid
problem.
In the latter case, a is the jacobian matrix of the
problem and is in general time dependent.9 However,
stability of the hybrid loop may be analyzed assuming
that a is a constant matrix. This restricts fonnally
the validity of the analysis to the cases where the
sampling period at is short in comparison to the rate
of variation of the coefficients of a. In particular, simulation of VTOL, STOL and variable geometry aircraft
(3.3)
We apply the z-transformation to equation (3.3) and
obtain (I is the unity matrix.) :
(z - I - ataz-k )
Xi
= 0
(3.4)
(We use the same notation for Xi and its z-transform;
the operator z in expression (3.4) is to 'be interpreted as
that which results in the relation: zi Xi = X'+i)
Normal solutions Uj of (3.4) are those which satisfy
t.he equations:
(3.5)
Stability Contours
U~+l
J
=
Z· U~
1
(3.6)
J
The matrix v has the property to diagonalize a, i.e.,
o
Zj is now a constant scalar, whereas Z in (3.4) is a
formal operator whose explicit expression need not be
defined.
Substitution of (3.6) into (3.5) yields:
vav-1 = A =
(Zj
Thus
Zj
I - I - at·a·zr") ul = 0
Oro ..
001
(4.3)
(3.7)
must satisfy the characteristic equation:
I
10
The values of Zj which are solution of (3.8) and the
corresponding Ul, correspond to normal. modes of behavior of the simulation. It is well known that, since
(3.3) is linear, any Xi can be expanded into a sum of
normal. modes u}, and that stability of Xi requires that
each of these modes be stable.
Thus, the condition of stability of the simulation is
that all the normal modes Uj be stable, which in view
of (3.6), is satisfied if all Zj satisfy the relation
U;+11
u~ =
1
FOIDl ally ,
IzA
<
(3.9)
1
(3.9) ensures tha~
=
ti}+l
Zj
u}
(3.10)-
Relation to the simulated system's roots
We observe that (3.8) is an algebraic equation of
order n(k + 1) in z, and finding all the roots may be
a complex task. But the search for the characteristic
values Zj can be considerably simplified if a change of
coordinates is made so as to diagonalize the matrix 8.,
which corresponds to reducing the original system (2.1)
to its normal modes. This is obtained by applying a
linear transformation:
y = vx
=
g
Ag
v
v(Z -
I - Llt az-k)
det(a T - AgI) = det(a - AgI) = 0
g = 1,2, ·····n
VT = (VI v2 • •• v g • • • vn )
I
(4.2)
V-I
yi = 0
(4.4)
yields
(Z - I - atAz-k ) yi = 0
(4.5)
Since A is a diagonal matrix, it follows that (4 ..1) can
be rewritten, line by line, as n independent equations:
Zg-k) yg
g = 1,2, ....... n
= 0 )
I
(4.6)
The significant difference between (3.4) and (4.6) is
that the latter is a scalar equation, whereas (3.4) is an
n -dimensional equation.
We now look for the normal modes of (4.6), for each
Ag independently, which is a considerably easier task
than the original solution of (3.8).
Normal solution of equation (4.6) will be of the fonn:
(4.7)
where z; is one of the (k
acteristic equation:
+
1) solutions of the char-
(4.8)
(4.1)
to equation (3.4), where the lines of v are the eigenvectors of aE; i.e.,
g
Writing
(Zg - 1 - Llt Ag
constitutes a contraction mapping,4 ensuring convergence of (3.5).
aT v
( . )'r stands for the transpose of (.)
Stability of the hybrid simulation is expressed by the
condition that all z~ corresponding to the (k + 1)
solutions of (4.8) for each of the n values of Ag , be in
absolute value smaller than unity.
The multiplication of roots
Since equation (4.8) is of the order (k + 1), and has
862
Spring Joint Computer Conference, 1969
(k + 1) roots, the total number of nonnal modes of
the hybrid simulation is n· (k
1). Of these, of course,
only n are meant .to represent the original system;
the n· k additional modes are spurious, and their relative
a...--nplitude should remain SIP..ail relative to the original
modes to ensure a realistic simulation.
Stability, however, requires that all modes, original
or spurious, satisfy the stability criterion:
+
\z;\ < 1
(5.1)
We assume here, ot course, that the simulated
system is itself stable; i.e., that
g = 1,2, ..... n
In the next section, we express condition (5.1) graphically by the definition of stability contours in the
Ag complex plane, or plane of the characteristic roots
of the simulated system.
Stability contours
In the z complex plane, the condition of stability
is that all z~ He inside' of the unit circle.
For instance, for k
equation reduces to:
o (no
computing delay), this
(6.4)
which is the equation of a circle of unit radius and
center (-1,0) (Figure 2).
For values of k different from zero, the curve expressed by equation (6.4) presents (k + 1) loops: only
that region which is in the inside of all (k + 1) loops
corresponds to the stability region. These stability
contours, for k = 0, 1, 2,3 and 4, are shown in Figure 3.
For each value of k, the stability domain is that inside
of each of the stability contours shown.
It is to be noticed that the stability domain is, as one
might expect, decreasing in size for increasing computing
delay kAt.
One may also observe that the crossing point of the
stability contour lines with the real negative axis is at
distances proportional to 1/ (k + 1) from the origin.
We now proceed to evaluate some compensation
methods by means of an analysis of their effect upon
Im~
If we transpose this condition into the A plane, the
resulting domain win be that corresponding to systems
whose hybrid simulation will be stable. The complex
transfonnation from Z plane to the A plane can be
obtained directly from (4.8), which can be rewritten:
(6.1)
A normalization to Ag •At furthermore provides a
dimensionless representation.
We call Stability Contour the line, in the Ag ' At plane,
which surrounds the domain in which the stability
condition (5.1) is satisfied. Along this line, we have:
Izl
= 1 or z = e illl ; (j =
v=--i )
}
IIIE( -
(6.2)
00, 00)
Thus, the equation of the stability contour, obtained
by the substitution of (6.2) into (6.1) is:
A·At
=
(e illl
-
1) e iklll
(6.3)
(For simplicity, we use A here to denote any of the
roots Ag),
Figure 2-8tability Contours for the uncompensated case with
no computing delay: The simulation will be stable only if all
roots >. of the simulated system lie within the circle of
center (- 1/At, 0) and radius 1/At. (Or, all
normalized roots (>., At) of the simulated
system must lie within the circle of center
(-1, 0) and unit radius.)
Stability Contours
863
The characteristic equation (4.8) becomes now:
k...-o
(z - 1) - LltA [(1
+ 6)Z-k
-
6Z-k - 1] = 0 (7.5)
The equation defining the stability contour in the
A'Llt plane is:
·5
ALlt =
(z - l)zk
(1
Izl
~O
-1·
Figure 3-Stability Contours for the uncompensated case-for
various computing delays ~t
stability contours. The compensation methods which
we shall analyze are:
1. Compensation by first order digital prediction;
2. Compensation by second order digital prediction;
3 .. The method of analog compensation.
Compensation by first order digital compensation
The effect of the sampling and digital delay can be
alleviated by using digital prediction based on the
present and past values of the computed digital
computer output Wi. First order prediction is obtained
when one past value of w is used in addition to the
present value Wi. This allows a linear prediction form to
be used. In essence, extrapolating w by 6Llt is given by:
= (1
+ 6) Wi
6w i -
-
=
+
1 (or
6) - 6z-1
z = eiCrJ)
1
(7.6)
J
Stability contours for k = 1; 6 = 0, .5, 1, 1..5 and 2
are shown Figure 4.
These contours show clearly that while prediction is
somewhat improving the correspondence between the
stability contour and the axis Re(ALlt) = 0, the domain
of stability along the real negative axis decreases in
some inverse proportion of 6. For the uncompensated
case, the stability limit is at Re(ALlt) = -1 or one
sample per time constant. For the optimum prediction
time (6 = 1.5), this stability limit is reduced to
Re(ALlt) = - .483, or 2.07 samples per time constant.
In the imaginary direction, however, the maximum
value of Im(ALlt) on the contour is seen to remain close
to .37, in the uncompensated as well as the optimal
compensated case (6 = 1.5)1 which corresponds to 17
samples per pseudo-cycle, although undamped systems
(Re(ALlt) = 0) always yield unstable hybrid simulations. It will be seen in the next section that second
order prediction yields stable hybrid simulations of
undamped systems.
Note, however, that a similar effect might be obtained
(7.1)
1
Bearing in mind that w' = axi-k, this expression
becomes:
w·+9 = (1
+ 6) ax i-
6ax i -k-l
k -
(7.2)
W H9
is substituted for Wi as the output of the digital
computer. Thus, the equation for the computer solution
corresponding to the uncompensated case (3.2) is, for
this method of compensation:
Xi+l -
Xi
= Llt wi+9
= Llt.a·[(1
+ 6)X i -
k -
6x i-k-l]
(7.3)
or, using the z-operator:
{z - I - Llt·a[(1
+ 6)Z-k
-
6Z-k-lJ}
Xi
= 0 (7.4)
Figure 4-The effect of first order digital compensation upon
Stability Contours for k = 1. (The optimum compensation;
in the Taylor Series sense, is provided for 0 = k + 1/2 = 1.5)
Spring Joint Computer Conference, 1969
864
by first order-over prediction. For instance, k = 1,
8 = 2 yields, in first order extrapolation, to stable
solutions along the imaginary axis up to 22 samples per
cycle (lower sampling rates are unstable.)
Compensation by second order digital prediction
Compensation by second order prediction is obtained
when two past values of ware used to predict w i + 9 :
The coefficients b o, b i and b2 are obtained by expressing wet) as a second order polYnomial passing exactly
through the three points (t i , Wi); (t i - I , Wi-I); (t i - 2, W i - 2)
This yields:
b o = 1 + 1.58 + .582
bi = - 28 - 82
b, = .5 (8 + fP)
\j
Figure 5-The effect of second order digital compensation upon
Stability Contours for k = 1. (The optimum compensation,
in the Taylor Series sense, is provided for (1 = k + 1/2 = 1.5)
(8.2)
5
k::2
or
W i +9
= (1
- (28
+
+ .58 )·a·x i ·a·xi-k-I + .5(8 + 8
2
1.j58
+8
2)
k
2)
ax i -
k -?
(8.3)
Substituting this expression in replacement of w \ in
(3.2), yields
X HI -
Xi
- (28
= At'a [(1
+ fP)
+ 1.58 + .582)X i- k
+ .5 (8 + fP) i-
X i- k - 1
X
Re( A·C.t)
k
-2]
(8.4)
-·5
o
Figure 6-The effect of second order digital compenastion upon
Stability Contours for k = 2. The optimum compensation,
in the Taylor Series sense, is provided for (1 = k + 1/2 = 2.5)
which, upon making use of the z-operator and the
diagonalization of a, yields the equation for the stability
contour:
XAt=
(1
+ 1.58 + .582)
(z -
- (28
1) Zk
+ 82)z-1 + .5(8 + 82)z-2
I
w(t)
x(t)
.
z = e illl
(8.5)
Results are shown in Figure 5, for k = 1,8= 0, .5, 1,
1.5 and 2.
For ,the optimum value of 8, i.e., 8 = 1.5, the crossing
point of the stability contour with the real negative
axis occurs at AAt = - .22, i.e., at 4.5 samples per time
constant.
On the other hand, the stability contour for second
order extrapolation and 8 = 1.5 now crosses the
Figure 7-The method of analog compensation of Miura
and Iwata
Stability Contours
865
imaginary axis. This occurs for a sampling rate of about
17 samples per cycle.
Figure 6 shows stability contours for second order
extrapolation for k = 2, 0 = 0, .5, 1, 1.5, 2, 2.5 (the
ideal extrapolation) and 3.
A nalog compensation
A method of analog compensation proposed by
l\1iura and Iwata7 consists in adding to the output of
each integrator O·Llt times its input (Figure 7). This
method and variations thereof were also suggested and
analyzed by Karplus. 3
It can easily be shown that the step equation
corresponding to the application of this method is:
Re(.~·At)
Figure 8-A comparison of different methods of compensation
for a computing delay of one samPling period (k = 1) and
optimal extrapolation (in the Taylor Series sense) 0 = 1.5
or, for the stability contour:
(z - 1) Zk
XLlt = Oz + (1 - 0)
z
=
eiCll
o
-·5
-1·
)
(9.2)
·5
For
O=k+~,
k=2
we obtain:
(z - 1)
XLlt = (k
+ ~) z -
(z - 1)
(k
+ %)
Zk
(k -
%)
Zk-l
- (k - %)Z-l
(9.3)
By comparison with (7.6), we observe that this
method of analog compensation results in identical
stability contours (and indeed, overall behavior) as those
corresponding to cases where k is reduced by 1, and first
order ideal (0 = k + %) digital extrapolation is
applied.
As a means of comparison among the three methods
of compensation analyzed, stability contours corresponding to k = 1 and k = 2 are superimposed in
Figure 8 and Figure 9, respectively.
CONCLUSIONS
The method of Stability Contours developed in this
paper offers a means for analyzing "in the large" the
effect of sampling and delay in hybrid loops, as well as a
meaningful tool to compare the merits of different
-·5
-·25
o
Figure 9-A comparison of different methods of compensation
for a computing delay of two sampling periods (k = 2) and
optimal extrapolation (in the Taylor Series sense) 0 = 2.5
methods of digital and analog compensation. It has
been applied here to analyze stability properties of
compensation methods proposed by previous authors,
namely first order digital prediction, second order digital
prediction and analog prediction (as well as the uncompensated case).
A general conclusion that appears from such an
analysis is that compensation methods based on Taylor
Series type of extrapolation algorithms improve· the
stability properties in the simulation of undamped or
slightly damped systems, but are detrimental to
866
Spring Joint Computer Conference, 1969
stability properties in the simulation of heavily damped
systems. This would suggest that, in the simulation of
time-varying systems, such as STOL, VTOL and
variable geometry airplanes, best results may be
obtained by the use of adaptive compensation methods,
where the degree of time extrapolation is made inversely
proportional to the degree of damping of the simulated
system.
Pulsed prediction filters applied to digital and hybrid
simulation
Simulation March 1966
6 EEL MITCHELL
The effect of digital compensation for computation delay in
a hybrid loop on the roots of a simulated system
Proc F J C C 1967 Vol 31 103
7 T MIURA J IWATA
Effect of digital execution time in a hybrid computer
REFERENCES
1 R M DEITERS
Vol I (English translation) Graylock Press Rochester N Y
1957
5 D L MATLOCK
T NOMURA
Circle test evaluation of a method of compen!~ating hybrid
computing errOrs by predicted integral
Simulation January 1967 33
2 R GELMAN
Corrected -inputs-A ';netrwd jor improved hybr"d simulation
Proc F J C C Vol 24 1963
3 W J KARPLUS
Error analysis of hybrid computer systems
Simulation Vol 6 No 2 February 1966 121
4 A N KOLMOGOROV S V FOMIN
Elements of the theory of functions and functional analysis
Proc F J C C Vol 24 1963
8 A J MONROE
Digital processes for sampled data systems
J Wiley and Sons New York 1962
9 R VICHNEVETSKY
Error analysis in the computer simulation of dynamic systems
ITar-;,ational aspects of the problem
IEEE Transactions on Electronic Computers Vol EC-16
No 4 August 1967 403-411
10 EEL MITCHELL J B MAWSON J BULGER
A generalized hybrid simulation for an aerospace vehicle
IEEE Transactions on Electronic Computers Vol EC-I5
No 3 June 1966304-313
REVIEWERS, PANELISTS, AND SESSION CHAIRMEN
REVIEWERS
E. Alexander
Jonathan Allen
Ramon Alonso
Joel D. Aron
William Atchinson
Algirdaz Aviaienis
Philip R. Bagley
Robert M. Barnett
Frank Bates
Max ben-Aaron
Roger H. Bender
Robert Benenati
Mort Bernstein
Frank F. Bevacqua
Christopher Billings
W. W. Bledsoe
James A. Bloomfield
Jacques Bouvard
Franklin H. Branin
D. B. Brick
J. Reese Brown, J r.
Roderick R. Brown
Thomas Burke
Peter Calingaert
Duane B. Call
Richard G. Canning
Roy B. Carlson
John J. Carr
John W. Carr, III
William C. Carter
Paul Castleman
T. E. Cheatham, J r.
J. Chernak
C. K. Chow
W. F. Chow
Carl Christinsen
Yaohan Chu
A. Ben Clymer
Edmund U. Cabler
Martin Cohn
S. F. Condon
Richard W. Conway
F. J. Corbato
W. A. Cornell
Frederick C. Cowburn
Richard Crandall
Robert Daley
L. C. Darden
Fred R. Decker
Richard DeNeufville
Peter J. Denning
Donald L. Dietmeyer
George G. Dodd
R. J. Dowe
Robert Dunn
Joseph Eachus
Jay Early
Murray Eden
Douglas Englebart
William English
Kathryn Erat
Z. W. Esper
Robert Fano
Nick A. Farmer
David J. Farrell
George Fedde
Julian Feldman
Wallace Feurzeig
Tudor Finch
Thomas Fitzgerald
Donald F orina
Franklin H. Fowler, Jr.
M. R. Fox
R. A. Freedman
E. R. Gabrielli
William Gear
E. G. Gilbert
M. E. Gilfix
Russell L. Gilstad
D. E. Goldstein
Joseph W. Goodman
William L. Gordon
A. G. Grace, Jr.
J. N. Gray
Martin Greenfield
Gabriel F. Groner
Thomas G. Hagan
Murray J. Haims
D. Hammel
Patrick J. Hanratty
William Harden
D. R. Haring
George H. Harmon
Frank Heart
Madeline M. Henderson
Gardner C. Hendrie
Robert Hengen
Robert A. Henle
Ernest G. Henrichon, Jr.
Bertram Herzog
Richard H. Hill
D. A. Hodges
Gary Hornbuckle
Austin S. Householder
S. Husson
R. E. Hux
G. T. Jacobi
William J essiman
Barry J. Karafin
Clarence A. Kemper
Allen Kent
B. Kessel
Charles R. Kime
R. E. King
Arnold L. Knoll
Kenneth Knowlton
Manfred Kochen
Eldo C. Koenig
Walter Koetke
Zvi Kohavi
Jerome M. Kurtzberg
Victor LaBolle
F. W. Lancaster
Eugene L. Lawler
R. W. Lawrence
Donald C. Lit;tcicome
Richard Little
Arthur W. Lo
Jerome Lobel
Eli Lodgenstein
Joseph T. Lundy
D. H. Mack
Richard L. Mandell
Dewey F. Manzer
Michael Marcotty
Harry Martell
E. J. McCluskey
L. P. Meissner
R. Meyers
James C. Miller
Tate Minckler
R. A. Miner
Darrell B. Miskell
E. E. L. Mitchell
Gordon S. Mitchell
George Nagy
Edward A. Nelson
F. William Nesline, Jr.
Nils J. Nilson
Kenneth Olsen
S. Ornstein
Dale Osborn
Jock J. Pariser
Robert W. Parker
F. Pel piglia
H. Philip Peterson
Harold Pickering
A. Pietissanto
Joseph Pistrang
W. R. Plugge
M. Ross Quillin
C. V. Ramamoorthy
Bertram Raphael
Robert Rappaport
William H. Rawlins
Stanley G. Reed
Lawrence C. Roberts
C. A. Rosen
Jack Rosen
Arthur M. Rosenberg
Robert F. Rosin
F. J. Sansom
H. M. Sassenfeld
Harry Scheuer
Max Scholz
Elizabeth Schumacker
Paul Seckendorf
Sally Yeates Sede10w
Oliver G. Selfridge
Herbert SemQn
Warren Semon
Peter W. Shantz
Alan C. Shaw
Paul N. Sholtz
R. L. Shuey
John Sidney
R. Silver
Warner Slack
Sanford Smith
F. J. Sparacio
Jason Speyer
Edward P. Stabler
Thomas A. Standish
Thomas B. Steel, Jr.
E. A. Steeves
Einartt Steffend
Mary E. Stevens
Thomas G. Stockham, Jr.
Warren Teitleman
Rankin N. Thompson, Jr.
W. P. Timlake
Larry Travis
Gene A. Vacca
Herbert F. Van Brink
Thomas H. Van Vleck
Robert J. Vamey
Robert Vichnevetsky
John V. Wait
Sigurd Wasken
l\t1aria \Veller
Frank Westervelt
Charles H. Whelen
Robert R. White
Ronald L. Wigington
James E. Wolle
John H. Worthington
John M. Wright
Kendall R. Wright
Richard K. Yamamoto
PANELISTS
Henriette D. Avram
Milton Bauman
Robert W. Berner
Edward Bennett
Richard Berman
Adam Block
William F. Brown
James M. Brownlow
G. Edward Bryan
Charles T. Casale
Thomas E .. Cheatham, Jr.
Fernando Corbato
John E. Cox
Frank Coyne
John Dearden
Jack B. Dennis
M. L. Dertouzos
D. L. Dietmeyer
Howard W. Dillon
John J. Donovan
Raymond L. Dujack
Kathryn Erat
Alvan R. Feinstein
Wallace Feurzeig
George E. Forsythe
E. R. Gabrielli
Bernard A. Galler
Edward Goldstein
W. L. Gordon
John A. Gosden
Martin Greenberger
Martin Greenfield
T. G. Hagan
Duncan Hansen
William Harden
John A. Harr
James F. Holmes
Grace rv1urray Hopper
Frank J. Jasinski
W. Jessiman
T. Kallner
Felix Kaufman
Barry Kessler
Eldo C. Koenig
William L. Konigsford
Butler Lambson
William B. Lewis
Andrew J. Lipinski
Milton A. Lipton
W. N. Locke
D. F. Manzer
J. W. Meyer
Tate Minckler
Edward Morenoff
Allen L. Morton, Jr.
Christopher B. Newport
Thomas E. Osborne
Seymour A. Papert
T. G. Paterson
A. J. Pennington
Alan J. Perlis
Owen R. Pinkerman
J. Pistrang
Stanley H. Pitkowsky
Frederick Plugge
O. \,V. Rechard
Nathaniel Rochester
Robert F. Rosin
Jerome D. Sable
Hal Sackman
Jean E. Sammet
Kirk Sattley
Elizabeth Schumacker
Dan W. Scott
Joseph Seiler
Warner V. Slack
A. R. Solomon
Paul Strassmann
Stuart G. Tucker
John Wright
Lofti Zadeh
William M. Zani
Kenneth L. Zearfoss
SESSION CHAIRMEN
Bruce W. Arden
Moses M. Berlin
James H. Burrows
Robert N. Davis
John J. Donovan
David Evans
Donald H. Gibson
John T. Gilmore, Jr.
John A. Gosden
Martin Graham
Robert M. Graham
Michael A. Harrison
Robert M. Howe
Charles A. Huebner
Malcolm M. Jones
Thomas E. Kurtz
Harry T. Larson
Robert Leonard
George H. Mealy
Henry S. McDonald
James L. McKenney
Richard E. Merwin
Richard G. Mills
Calvin N. Mooers
Richard M. Moroney
William H. Ninke
Elliott I. Organick
George W. Patterson
Fred H. Scaife
Robert H. Stotz
Patrick Suppes
Joseph Sussman
Leonard Uhr
James A. Ward
AFIPS PRIZE PAPER AWARD COMMIITEE
C. W. Rosenthal, Chairman
G. E. Bryan
J. A. Githens
D. R. Heebner
C. A. R. Kagan
M. D. McIlroy
R. J. Preiss
1969 SJCC LIST OF EXHIBITORS
Access Systems Inc.
Adage, Inc.
Addison-Wesley Publishing Company, Inc.
Addressograph Corporation
Advanced Computer Techniques Corporation
Allen-Babcock Computing Inc.
American Telephone & Telegraph Co.
AMP, Incorporated
Ampex Corporation
Anderson Jacobson Inc.
Applied Data· Research, Inc.
Applied Dynamics, Inc.
Applied :Magnetics Corporation
Association for Computing Machinery
Astrodata, Inc.
Auerbach Corporation
Auto-trol Corporation
Datamark, Inc.
DataMate Computers, Div. of Gameo Industries
Datamation
Data Pathing Incorporated
Data Processing Magazine
Data Products Corporation
Datascan
Data Technology Corporation
Datel Corporation
Delta Data
Dil An Controls, Inc.
Digi-Data Corporation
Digital Development Corporation
Digital Equipment Corporation
Digitronics Corporation
Dura. Division Intercontinental Systems, Inc.
Dynamic System Electronics
BASF Computron Inc.
Bolt Beranek and Newman Inc.
Boole & Babbage, Inc.
Brogan Associates, Inc.
Bryant Computer Products
Business Information Technology, Inc.
Eastman Kodak Company
Edwin Industries
Elbit Computers Ltd.
Electronic Associates Inc.
Electronic Design Magazine
Electronic News, a Fairchild Publication
EMR Computer
California Computer Products, Inc.
Calma Company
Clevite Corporation, Brush Instruments Div.
Collins Radio Company
Communitype Corporation
Compumatics, Inc.
Computer Applications Incorporated
Computer Automation Inc.
Computer Communications, Inc.
Computer Design Publishing Corp.
Computer Displays Inc.
Computer Methods Corporation
Computer Peripherals Corporation
Computer Products, Inc.
Computer Sciences Corporation
Computer Signal Processors, Inc.
Computer Terminal Corporation
Computer Transceiver Systems, Inc.
Computer Usage Company, Inc.
Computers and Automation
Computerworld
Control Data Corporation
Datacraft Corporation
Data Disc, Inc., Display Division
Data General
Fabri-Tek Incorporated
Factsystem Inc.
Ferroxcube Corporation
General Automation Inc.
General Computers, Inc.
General Design Inc.
General Electric Company,
Information Systems
Information Devices Department
Process Computer Department
Specialty Control Department
Geo Space Corporation
The Gerber Scientific Instrument Co.
Hendrix Electronics
Hewlett-Packard
HF Image Systems, Inc.
Honeywell, Computer Control Division
Honeywell, EDP
Houston Instrument, Div. of Bausch & Lomb
Hybrid Systems, Inc.
IBM Corporation
IEEE
Indiana General Corporation
Industry Reports, Inc.
Inforex Inc.
Information Control Corporation
Information Displays, Inc.
Information Technology, Inc.
Infotechnics
Interdata Inc.
Jonker Corporation
Kennedy Company
Keydata and Adams Associates Inc.
Kleinschmidt, Division of SCM Corp.
Link Group/Singer-General Precision Inc.
Litton Automated Business Systems
Litton Datalog Division
Lockheed Electronics Co., Data Products Div.
McGraw-Hill Book Company
MAl Equipment Corporation
Magne-Head Div., General Instrument Corp.
Mandate Systems Incorporated
Memory Technology Inc.
Micro Switch, a Division of Honeywell
Milgo Electronic Corporation
3M Company
Modem Data
Mohawk Data Sciences Corp.
Monitor Systems, Inc.
Motorola Instrumentation & Control Inc.
The National Cash Register Company
The National Cash Register Company,
Industrial Products
Nissei Sangyo Co., Ltd.
Olivetti Underwood Corporation
Omnitec Corp., Div. of Nytronics
Peripheral Equipment Corporation
Photon, Inc.
Potter Instrument Company, Inc.
Prentice-Hall Inc ..
RCA Information Systems
RCA Electronic Components
Raytheon Company
Raytheon Computer
Redcor Corporation
Remex Electronics
Rixon Electronics, Inc.
Sanders Associates, Inc.
Sangamo Electric Company
Scientific Control Corporation
Scientific Data Systems
Spartan Books
Stromberg Datagraphics, Inc.
Sycor, Inc.
Sykes Datatronics, Inc.
Systems Engineering Laboratories
Tally Corporation
Tektronix Inc.
Teletype Corporation
Telex, Computer Products DiviSion
Texas Instruments Incorporated
Transistor Electronics Corporation
Tri-Data Corporation
Tyco, Digital Devices Division
Tymshare, Inc.
Ultronic Systems Corp.
Lenkurt Electric
General Telephone & Electronics
Sylvania Electric Products
United Computing Systems, Inc.
UTE (United Telecontrol)
UNIVAC, Division of Sperry Rand Corp.
URS Systems Corporation
Vanguard Data Systems
Varian Data Machines
Vermont Research Corporation
Viatron
Wang Laboratories, Inc.
John Wiley & Sons, Inc.
Xerox Corporation
AUTHOR INDEX
Abel, N. E., 57
Aiexander, E. R.,373
Alsop, J., II, 1
Altman, S. M., 587
Amsterdam, R.,513
Anderson, G. B.,173
Avram, H. D., 42
Baecker, R., 273
Balzer, R. M., 567
Barnett, M. P., 75
Battersby, E. J.,'"'03
Bauman, M., 35
Beckert, D., 827
Berner, R. W.,606
Bennett, W. L., 709
Boehm, B. W.,321
Bowyer, A. F., 637
Budnik, P. P.,57
Burner, H:' B., 775
Caplan, R.,505
Carroll, A. B.,221
Casale, C. T., 30
Cioffi, G., 139
Cody, W. J., Jr., 759
Cohen, D., 297
Cotten, L. W., 581
Crandall, N. R., 241
Danver, J. H., 681
Dayton, F. A., 241
DeLine, J. R., 257
Dennis, J. B., i);{7
DeRemer, F. L., 793
Dillon, H. \V., 44
Donovan, J. J. o 86
Duffy, G. F., 339
Dunn, L. A., 187
Entwisle, D. R., 623
Estrin, G., 723
Feinstein, A. R., 715
Fenichel, R. R.,717
Feurzeig, W., 613
Field, J. A;, 597
Fiorillo, E., 139
Fischler, M., 381
Forgie, J. W., 629
Forsythe, G. E., 538
Gartner, F. P.,339
Gilmone, J. T., 29
Giloi; W., 827
Goyal, L. N.,187
Glueck, B. C., Jr., 709
Gosden, J. A., 607
Gott, A. H., 637
Gotterer, M. M.,419
Greenberger, .M., 32
Gross, P. F., 691
Grossman, A. J.,717
Hansen, D. N., 614
Happ, W. W., 229
Hargraves, R. F., Jr., 657
Haring, D. R.,483
Hillman, D. J. 447
Hodges, J. D., Jr., ,529
Hopper, G. M.,608
Horovitz, R. S., :159
Huang, T. S.,173
Huggins, W. H., 623
Jackson, P. E., 491
Johnstone, J. L., 15
Just, L., 751
Kasarda, A. J.,447
Kato, M.,221
Katzan, H., Jr., 47
Kay, R. H., 425
Kennedy, A., 751
Knudson, D. R.,475
Koenig, E. C., 614
Koga, Y., 221
Korn, G. A., 849
Kuck, D. J., 57
Kubert, B. R., 637
Kurtz, T. E., 6~9
Lamb, V. R.,321
Lambert, H. R.o 4:02
Lang, C. A.,543
Leaf, G., 751
Lee, T. M. P.,297
Lesk, M. E., 425
Lewis, G. B., 37
Liang, L.,843
Licklider, J. C. R.,617
Liebig, H. C., 827
Lipner, S. B.,523
Lo, A. W.,587
Locke, W. N.,41
McCormick, B. H., 187
McGeachie, J. S.,665
McIntosh, F. J.,229
Madnick, S. E., 1
Marcus, R. S., 331
Matula, D. W., 765
l\1aupin, J. T., 149
Maurer, W. D.,89
Meeker, J. W.,241
Melkanoff, M. A., 732
Mesko, E. S., 351
Metzger, R. A., 161
Meyers, E. D., Jr., 673
Million, R., 775
Mobley, R. L.,321
Morello, M. V., 629
MorenoiI, E., 60~
Morton, A. L., j-r., 2 i
Murako, Y.,57
Naemura, K.,221
Naylor, W. C.,95
Nevatt, G. W., 6..~7
Nevison, J. M.,681
Newport, C. B., 773
Northcote, R. S., 57
O'Neill, L. A., 207
Opp~nheimer, G., 249
Pamas, D. L., 739
Pearlman, J. M., 505
Perlis, A. J., 540
Pratt, T. W.,813
Presser, L., 733
Rago, A., 751
Ravi, C. V., 393
Reintjes, J. F., 331
Richard, O. W.,775
Richards, M., 557
Rieber, J. E., 321
Reiter, A., 381
Roberge, J. K., 483
Rose, G., 241
Ruhsam, W. M., .75
Russell, E. C., 723
Sable, J. D., 611
Salton, G., 435
Schneider, V., 777
Schwetman, H. D., 257
Seiler, J., 38
Shrader, W. W.,745
Simons, S., M9
Snyder, R., 505
Sobolewski, J. S., 775
Steinbach, R., 849
Stephenson, A., 657
Stroebel, C. F., 709
Stubbs, C. D., 491
Sutherland, W. R., 629
Sutro, L. L., 113
Tareski, V. G., 187
Teicher, S. N., 475
Theiss, C. M., 289
Trapnell, F. M.,411
Van Tassel, D., 367
Vichnevetsky, R., 859
Vorthmann, E. A., 139
Walker, P., 751
Ward, J. A.,605
Weizer, N., 249
Whitehead, D. W.,529
Whitney, G. E., 801
Wiatrowski, C., 849
Wilhelmson, R. B.,57
Wilkes, M. V., 265
Yen, Y. T.,215
Zadeh, L., 539
Zani, W. M.,.32
Zobrist, A. L., 103
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:17 23:57:49-08:00 Create Date : 2008:11:17 23:57:49-08:00 Metadata Date : 2008:11:17 23:57:49-08:00 Format : application/pdf Document ID : uuid:7100f534-3318-4d1f-b5eb-0b542c9c87b3 Instance ID : uuid:73ccf176-c02b-43ca-bd04-d21087dbe0bb Page Layout : SinglePage Page Mode : UseOutlines Page Count : 887EXIF Metadata provided by EXIF.tools