1970 11_#37 11 #37
1970-11_#37 1970-11_%2337
User Manual: 1970-11_#37
Open the PDF directly: View PDF 
.
Page Count: 683
| Download | |
| Open PDF In Browser | View PDF |
AFIPS
CONFERENCE
PROCEEDINGS
VOLUME 37
1970
FALL JOINT
COMPUTER
CONFERENCE
AFIPS
CONFERENCE
PROCEEDI NGS
VOLUME 37
1970
FALL JOINT
COMPUTER
CONFERENCE
November 17 -19, 1970
Houston, Texas
The ideas and opinions expressed herein are solely those of the authors and are not
necessarily representative of or endorsed by the 1970 Fall Joint Computer Conference Committee or the American .. Federation of Information Processing
Societies.
Library of Congress Catalog Card Number 55-44701
AFIPS PRESS
210 Summit Avenue
lVlontvale, New Jersey 07645
©1970 by the American Federation of Information Processing Societies, IVlontvale,
New Jersey 07645. All rights reserved. This book, or parts thereof, may not be
reproduced in any form without permission of the publisher.
Printed in the United States of America
CONTENTS
A SPECTRU1VI OF PROGRAM]\1ING LANGUAGES
The macro assembler, SWAP-A general purpose interpretive
processor .................................................. .
Definition mechanisms in extensible programming languages ....... .
1
9
1\1. E. Barton
S. A. Schuman
P. Jorrand
VULCAN-A string handling language with dynamic storage
control .................................................... .
21
E. F. Storm
R. H. Vaughan
On memory system design ..................................... .
Design of a very large storage system ........................... .
33
45
Design of a megabit semiconductor memory system ...........
.I... .
53
R. l\1. 1\1eade
S. J. Penny
R. Fink
1\1. Alston-Garnjost
D. Lund
C. A. Allen
S. R. Andersen
G.K.Tu
Optimum test patterns for parity networks ...................... .
63
A method of test generation for fault location in combinatorial logic ..
69
The application of parity checks to arithmetic control ............. .
79
MODERN l\1El\10RY SYSTEl\1S
DESIGN FOR RELIABILITY
D. C. Bossen
D. L. Ostapko
A. 1\1. Patel
Y. Yoga
C. Chen
K. Naemura
C. P. Disparte
OPERATING SYSTE1\1S AND SCHEDULES
Scheduling in a general purpose operating system ................. .
89
Scheduling TSS/360 for responsiveness .......................... .
Timesharing for OS ........................................... .
97
113
SPY-A program to monitor OS/360 ........................... .
119
V. A. Abell
S. Rosen
R. E. Wagner
W. J. Doherty
A. L. Scherr
D. C. Larkin
R. Sedgewick
R. Stone
J. W. l\1cDonald
AEROSPACE APPLICATIONS
An efficient algorithm for optimum trajectory computation ........ .
Hybrid computer solutions for optimal control of time varying
systems with parameter uncertainties ......................... .
129
K. S. Day
135
W. Trautwein
C. L. Conner
143
159
R. N. Freed
1\1. E. Stevens
COl\1PUTER PROCUREMENT REQUIREMENTS IN RESEARCH
AND DEVELOPMENT
The role of computer specialists in contracting for computers-An
interdisciplinary effort ...................................... .
Selected R&D requirements in the computer and information sciences
l\1ULTI-ACCESS OPERATING SYSTEl\1S
Development of the Logicon 2+2 system ........................ .
System ten-A new approach to multiprogramming ............... .
169
181
A. L. Dean, Jr.
R. V. Dickinson
W. K. Orr
ANALYSIS OF RETRIEVAL SYSTEl\1S
On automatic design of data organization ........................ .
Analysis of retrieval performance for selected file organization
techniques ... '.' ............................................ .
187
W. A. l\1cCuskey
201
A. J. Collmeyer
J. E. Shemer
Analysis of a complex data management access method by simulation
modeling ................... '" ., .......................... .
211
V.Y.Lum
H. Ling
l\1. E. Senko
Fast "infinite-key" privacy transformation for resource-sharing
systems ................................................... .
223
J. M. Carroll
P. M. l\1cLelland
231
J. S. Vierling
l\1. Shivaram
241
251
D. C. Martin
L. Siklossy
257
J. J. Allan
J. J. Lagowski
M. T. l\1uller
269
l\1. R. Irwin
275
G. E. Heyliger
281
N. Abramson
Computer-aided system design ................................. .
287
Integrated computer aided design systems ....................... .
297
Interactive graphic consoles-Environment and software .......... .
315
E. D. Crockett
D. H. Copp
J. W. Frandeen
C. A. Isberg
P. Bryant
W. E. Dickinson
lV1. R. Paige
R. C. Hurst
A. B. Rosenstein
R. L. Beckermeyer
COl\1PUTER ASSISTED UNDERGRADUATE INSTRUCTION
On line computer managed instruction-The first step ............ .
Development of analog/hybrid terminals for teaching system
dynamics .................................................. .
Computer tutors that know what they teach ..................... .
Planning for an undergraduate level computer-based science education system that will be responsive to society's needs in the
1970's .............................................. '....... .
COlVIPUTER CONIl\1UNICATION PART I
The telecommunication equipment market-Public policy and the
1970's ..................................................... .
Digital frequency modulation as a technique for improving telemetry
sampling bandwidth utilization ............................... .
THE ALOHA SYSTEl\1-Another alternative for computer communications ............................................... .
CO~lPUTER
AIDED DESIGN
INTERFACING COl\IPUTERS AND EDUCATION
l\lDS-A unique project in computer assisted mathematics ........ .
325
Teaching digital system design with a minicomputer .............. .
Computer jobs through training-A preliminary project report ..... .
333
345
R. H. Newton
P. W. Vonhof
W. C. Woodfill
l\1. G. l\1organ
l\1. R. l\1irabito
N. J. Down
COMPUTER COMMUNICATION PART II (A Panel Session)
(No papers in this volume)
SURVEY OF TIlVIE SHARING SYSTE1VIS (A Panel Session)
Technical and human engineering problems in connecting terminals
to a time-sharing system. . .................................. .
355
J. F. Ossanna
J. H. Saltzer
l\1:ultiprogramming in a medium-sized hybrid environment ......... .
The binary floating point digital differential analyzer ............. .
363
369
Time sharing of hybrid computers using electronic patching ........ .
377
W. R. Dodds
J. L.Elshoff
P. T. Hulina
R. l\1:. Howe
R. A. l\IIoran
T. D. Berge
HYBRID SYSTEMS
SIMULATION LANGUAGES AND SYSTEMS
J. D. l\1:ar kel
B. Carey
B. E. Tossman
C. E. Williams
N. K. Brown
R. L. Granger
G. S. Robinson
G. R. Trimble, Jr.
D. A. Bavly
Digital voice processing with a wave function representation of speech
387
SIl\1:CON-An advancement in the simulation of physical systems ...
399
COl\1:SL-A Communication System Simulation Language ........ .
407
Cyberlogic-A new system for computer controL ................. .
417
A model for traffic simulation and a simulation language for the
general transportation problem ............................... .
425
R. S. Walker
B. F. Womack
C. E. Lee
433
445
451
A. I. Wasserman
D. Van Tassel
R. Nlallary
461
J. E. Stuehler
471
L. A. O'Neill
477
D. Bjorner
493
D. E. Farmer
503
H. lVI. Gates
R. B. Blizard.
515
G. N. Pitts
P. B. Crawford
ART, VICE AND GAl\1:ES
Realization of a skillful bridge bidding program .................. .
Computer crime .............................................. .
Tran2-A computer graphics program to make sculpture .......... .
COl\1:PUTERS AND l\1:ANUFACTURING
l\1:anufacturing process control at IBl\tJ:. ......................... .
Extending computer-aided design into the manufacture of pulse
equalizers. . . .............................................. .
EFFECT OF GOVERNl\I[ENT CONTROLS IN THE
COlVIPUTING INDUSTRY (A Panel Session)
Finite state automation definition of data communication line control
procedures ................................................. .
A strategy for detecting faults in sequential machines not possessing
distinguishing sequences ..................................... .
Coding/ decoding for data compression and error control on data links
using digital computers ...................................... .
COl\I[PUTATIONAL EFFICIENCY AND PERFOR1\IANCE
l\1inimizing computer cost for the solution of certain scientific
problems .................................................. .
Analytical techniques for the statistical evaluation of program running
times .... , ................................................ .
Instrumenting computer systems and their programs .............. .
519
525
B. Beizer
B. Bussell
R. A. Koster
535
547
555
R.
R.
C.
R.
Integration of rapid access disk memories into real-time processors ..
1\1anagement problems unique to on-line real-time systems ......... .
563
569
ECAl\1-Extended Communications Access l\lethod .............. .
Programming in the medical real-time environment ............... .
581
589
R. G. Spencer
T. C. Malia
G. W. Dickson
G. J. Clancy, Jr.
N. A. Palley
D. H. Erbeck
J. A. Trotter, Jr.
Decision making with computer graphics in an inventory control
environment .........................................-...... .
599
Concurrent statistical evaluation during patient monitoring ........ .
609
NEW DIRECTIONS IN PROGRAlVIlVIING LANGUAGES
(A Panel Session) (No papers in this volume)
TEXT PROCESSING
SHOEBOX-A personal file handling system for textual data ...... .
HELP-A question answering system ........................... .
CyperText-An extensible composing and typesetting language .... .
S. Glantz
Roberts
G. Moore
P. 1\1ann
COIVIl\1UNICATION AND ON-LINE SYSTElVIS
J. S. Prokop
F. P. Brooks, Jr.
S. T. Sacks
N. A. Palley
H. Shubin
A.A.Afifi
SELECTED COlVIPUTER SYSTEl\1S ARCHITECTURES
Associative capabilities for mass storage through array organization ..
Interrupt processing with queued content-addressable memories .....
615
621
A language oriented computer design ........................... .
629
A. 1\1. Peskin
J. D. Erwin
E. D. Jensen
C. 1\,fcFarland
641
A. I. Rubin
653
1\1. Sakaguchi
N. Nishida
PROSPECTS FOR ANALOG/HYBRID COlVIPUTING
(A Panel Session)
Analog/hybrid-What it was, what it is, what it may be .......... .
TOPICAL PAPER
The hologram tablet-Anew graphic input device ................ .
The macro assembler, SWAP-A general
purpose interpretive processor
by M. E. BARTON
Bell Telephone Laboratories
Naperville, Illinois
INTRODUCTION
Inputs
A new macro assembler, the SWitching Assembly
Program (SWAP), provides a variety of new features
and avoids the restrictions which are generally found
in such programs. Most assemblers were not designed
to be either general enough or powerful enough to accomplish tasks other than produce object code. SWAP
may be used for a wide variety of other problems such
as interpretively processing a language quite foreign
to the assembler.
SWAP has been developed at Bell Telephone Laboratories, Incorporated, to assemble programs for three
very different telephone switching processors. (SWAP
is written in the IBM 360 assembly language and runs
on the 360 with at least 256K bytes of memory.) With
such varied object machines and the need to have all
source decks translatable from the previously used assembler languages to the SWAP language, it is no
wonder that the SWAP design includes many features
not found in other assemblers. The cumulative set of
features provides a powerful interpretive processor that
may be used for a wide variety of problems.
The SWAP assembler may receive its original input
from a card, disc, or tape data set. The SOURCE
pseudo-operation allows the programmer to change the
input source at any point within a program. It is also
capable of receiving input lines directly from another
program, normally a source editor.
Outputs
Because the input line format is free field, the assembly listing of the source lines may appear quite
unreadable. Therefore, the normal procedure is to have
the assembler align all the fields of the printed line.
The positions of the fields are, of course, a programmer
option. There are several classes of statements that
may be printed or suppressed at the programmer's
discretion. In keeping everything as general as possible,
it is natural that any operation, pseudo-operation, or
macro may be assigned to any combination of these
classes of statements.
In addition to producing the object program, which
varies with different applications, and the assembly
listing just described, SWAP has the facility to save
symbol, instruction, or macro definitions in the form of
libraries which may be loaded and used to assemble
other programs.
Macro expansions and the results of text substitution functions are another optional output. The programmer completely controls which lines are to be
generated and the format of these lines. These lines
may be printed separately from the object listing or
placed on card, disc, or tape storage. This optional output may be used to provide input to other assemblers,
DESCRIPTION
The source language is free field. Statement labels
begin in column one. Operation names and parameters
are delimited by a single comma or one or more blanks.
Comments are preceded by the sharp sign (#), and the
logical end of line is indicated by the semicolon (;) or
physical end of card. A method is provided for user interpretation of other than this standard syntax ; SWAP
is currently being used as a preliminary version of
several compilers.
1
2
Fall Joint Computer Conference, 1970
and in this way SWAP can become a pseudo-compiler
for almost any language. This output can also be used
to produce preliminary program documents from comments which were originally placed in ·the source· program deck.
Variables
There are numerous types of variable symbols, such
as integers, floating point numbers, truth value, and
character strings. The programmer may change or
assign the type of any symbol as he wishes. Fot this
purpose, the type of a symbol or operation is represented by a character. Each variable symbol may have
up to 250 user-defined attributes which are data associated with each symbol. In addition, each symbol
represents the top of a push-down list which allows the
programmer to make a local use of any symbol.
A string variable would be defined by· the TEXT
pseudo-operation:
VOWELS
TEXT
'AEIOU'
while a numeric value is assigned by SET:
LIMIT SET
10
The 'functional' notation is used extensively to
represent not only the value of a symbol attribute, but
also to represent array elements and predefined or
user-defined arithmetic functions. In the following
statement:
ALPHA (SA)
SET
BETA (SB) +10
the ALPHA attribute of symbol SA would be assigned
a value ten ·greater than the BETA attribute of symbol
SB.
An array of three dimensions would be declared by
the statement:
Expressions
The following is a hierarchical list of the operators
allowed in expressions:
1
**
*
or
and
/
unary-
and
unary-,
+
and
=, >, <, -, =
=>
=<
&
or
or
or
and
~
~
::;;
-,
and
}
exponentiation
multiplication and
division
negation and complement
addition and subtraction
the six relational operators
logical AND and
AND of complement
logical OR and EXeLUSIVE OR
( ), [ ], and { } may be used in the usual manner to
force evaluation in any order.
Four particular rules apply to the use of these
operations:
1. Combined relations ApBpC are evaluated the
same as the expression ApB&BpC where pis any
relational operator.
2. Character strings in comparisons are denot~d as
quoted strings.
3. The type of each operand is used to determine
the method of evaluation. (For example, the
complement of an integer is the 32-bit complement while the complement of a truth value is a
I-bit complement.)
4. If a TEXT symbol is encountered as an operand
in an expression, it is called an indirect symbol,
and its value is the result of evaluating the
string as an expression.
ARRAY CUBE ( -1:1,3,0:2)=4
In this example, the range of the first dimension runs
from -1 through + 1, while the second dimension is
from + 1 through +3, and the third is from 0 through
2. Each element would have the initial value 4, but
the following statement could be used to assign another
value to a particular element of the array:
CUBE ( -1,2,0)
SET
5
An attribute, array, or function reference may occur
anywhere that a symbol may be used in an arithmetic
expreSSlOn.
Predefined Functions
Several built-in or predefined functions are provided
to aid in evaluating some of the more common expressions. The following is a partial list of the available
functions:
E(EXP)
MAX (EXP1,
.•• ,
EXP n )
Results in 2 raised to the
EXP power.
Returns the maximum of
the expressions EXP1
through EXP n.
SWAP
STYP(EXP, C)
SET(SYMB, EXP)
Returns the value of EXP,
but the type of the result
is the character C as discussed in the Variables
section.
Returns the value of EXP
and assigns that same
value to the symbol
SYMB. This differs from
the SET pseudo-operation in that the symbol
is defined during the
evaluation of an expres-
Y is present, but the value of INC (3) is 4 since an
argument value for Y was omitted.
The other feature which allows an arbitrary number
of arguments is the ability to loop over a part of the
defining expression, using successive argument values
wherever the last dummy parameter name appears in
the range of the loop. This feature is invoked by the
appearance of an ellipsis ( ... ) in the defining expression. The range of the loop is from the operator immediately preceding the ellipsis backward to the first
occurrence of the same operator at the same level of
parentheses. As an example, consider the following
statement:
SIOn.
DFN
To allow the programmer to define any number of
new functions, the DFN pseudo-operation is provided.
The general form of a function definition is written:
••• ,
P n) =A1:B1, A 2 :B2,
••• ,
An:Bn
where F is the function name, the Ps are dummy
parameter names, and the As and Bs are any valid
expressions. These expressions may contain the Ps and
other variables as well as other function calls which may
be recursive.
To evaluate the function, the Bs are evaluated left
to right. The result is the value of the A corresponding
to the first B that has a value of true (or nonzero).
The colons may be read as the word "if." A simple
example would be the function:
DFN
POS(X)=1:X>0,0:X~0
which returns the value 1 if its argument is positive;
otherwise, the result is zero. If the expression Bn is
omitted, it is assumed to be true. Another example is
the following definition of Ackermann's function:
=A~X**(Y +C)'+- --
The range of the loop is from the
following the right
parenthesis backward to the + between the A and the
X. The call SUM (4, 1,2,3) would yield the same
result as the following expression:
A +4**(1 +C) +4**(2+C) +4**(3+C)
The loop may also extend over the expression between
two commas as the next example shows. A recursive
function to do the EXCLUSIVE OR of an indefinite
number of arguments could be defined by:
DFN
XOR(A, B, C) =A-,B I B-,A: -,C?,
XOR(XOR(A, B) ,IC,l ...
N =0, ACK(M -1, ACK(M, N-1))
Two features are provided to allow an arbitrary number of arguments in the call of a function. The first is
the ability to ask if an argument was implicitly omitted
from the call. This feature is invoked by a question
mark immediately following the dummy parameter
name. If the argument was present, the result of the
parameter-question mark is the value true; otherwise,
the value is false. For example, the function defined by:
INC(X, Y)=X+Y:Y?,X+1
would yield the value 7 when called by INC (2, 5) since
)
Sequencing control
The pseudo-operations that allow the normal sequence of processing to be modified provide the real
power of an assembler. In SWAP, the pseudo-operations
that provide that control are JUMP and DO. JUMP
forces the assembler to continue sequential processing
with the indicated line, ignoring any intervening lines.
The statement:
JUMP
DFN ACK(M, N) =N+l:M=0,ACK(M-1, 1):
DFN
SUM(X, Y)
+
Programmer-defined functions
DFN F(P1, P 2,
3
.LINE
will continue processing with the statement labeled:
.LINE. The symbol .LINE is called a sequence symbol
and is treated not as a normal symbol but only as the
destination of a JUMP or DO. Sequence symbols are
identified by the first character, which must be a period.
A normal symbol may also be used as the destination
of a JUMP or DO, if convenient. The destination of a
JUMP may be either before or after the JUMP statement.
The JUMP is taken conditionally when an expression is used following the sequence symbol:
JUMP
.XX, INC> 10
# IS
IT OVER LIMIT
4
Fall Joint Computer Conference, 1970
The JUMP to .XX will occur only if the value of the
symbol INC is greater than ten.
The DO pseudo-operation is used to control an assembly time loop and may be written in one of three
forms:
DO
DO
DO
.LOC, VAR= INIT, TEXP, INC
.LOC, VAR=INIT, LIMIT, INC
.LOC, VAR=(LIST)
(i)
(ii)
(iii)
Type (i) assigns the value of IN IT to the variable
symbol VAR. The truth value expression TEXP is
then evaluated and, if the result is true, all the lines
up to and including the line with .LOC in its location
field are assembled. The value of INC (if INC is
omitted, 1 is assumed) is then added to the value of
VAR and the test is repeated using the incremented
value of V AR.
Type (ii) is the same as type (i) except that the
value of V AR is compared to the value of LIMIT; the
loop is repeated if INC is positive and the value of VAR
is less then or equal to the value of LIMIT. If INC is
negative, the loop is repeated only while the value of
V AR is greater than or equal to the value of LIMIT.
Type (iii) assigns to V AR the value of the first item
in LIST. Succeeding values are used for each successive
time around the loop until LIST is exhausted.
The following are examples of the use of DO:
Type (i)
Type (ii)
Type (iii)
DO
DO
DO
.Y,M=I,M~10&A(M»0
.X, K=I, 100, K+1
.Z, N = (1, 3, 4, 7,11,13,17)
Control of optional output
Selected results of macro and text substitution facilities may be used as an optional output. This is accomplished by the use of the EDIT psuedo-operation
which may be used in a declarative, global, or range
mode.
The declarative mode does not cause any output to
be generated, but is used to declare the destination
(printer, punch, or file) of the output and the method
of handling long lines. It is also used to control the
exceptions to the global output mode. For example,
the statement:
PRINT EDIT OFF ('ALL') ,
ON ('REMARKS', NOTE, DOC),
CONT(72, 'X', '- - -')
would indicate that edited output is to be printed, and
that any line that exceeds 72 characters is to be split
into two print records with an X placed at the end of
the first 72 characters and the remainder appended to
the - - -. If EDIT ON, the global form, were to be
used with the above declarative, then only lines that
contain NOTE or DOC in the operation field as well
as all remark statements will be outputted.
The range form of ED IT allows a sequence of lines
to be outputted regardless of their syntax. Lines outputted in this mode are then ignored by the remainder
of the assembly processes.
Two examples of this form are EDIT .NEXT which
causes the next line to be outputted, and EDIT .LINE
which causes all lines up to, but not including, the line
with the sequence symbol .LINE in its label field. See
the Appendix for examples of the use of the EDIT
pseudo-operation.
Macros
The macro facilities incorporated in SWAP make it
one of the most flexible assemblers available. The
macro facilities presented here are by no means exhaustive but only representative of the more commonly used features.
The general form of a macro definition is:
MACRO
prototype statement
macro text lines
MEND
The prototype statement contains the name of the
macro definition as well as the dummy parameter
names which are used in the definition. The macro
text lines, a series of statements which make up the
definition of the macro, will be reproduced whenever
the macro is called.
Any operation, pseudo-operation, or macro may be
redefined as a macro. Also, there are no restrictions as
to which operatiorrs are used within a macro definition;
this means that it is legitimate for macro definitions to
be nested.
Macro operators and subarguments
Macro operators are provided to allow the programmer to obtain pertinent information about macro
arguments and some of their common parts. A macro
operator is indicated by its name character followed by
a period and the dummy parameter name of the
operand. For example, if a parameter named ARG has
the value (A, B, C), then the number operator,
SWAP
N.ARG, would be replaced by the number of subarguments of ARG; in this example, N.ARG is replaced
by 3.
Any subparameter of a macro argument may be accessed by sUbscripting the parameter name with the
number of the desired sub argument. Additional levels
of sub arguments are obtained with the use of multiple
indexes. As an example, let the parameter named ARG
assume the value P (Q, R (S, T)), then:
ARG(O)
ARG(I)
ARG(2)
ARG(2, 0)
ARG(2, 1)
is replaced by P
is replaced by Q
is replaced by R(S, T)
is replaced by R
is replaced by S
The macro operators may be used on the results of
each other as well as on subparameters; for example,
N.ARG (2) would be replaced by 2.
The following is an example of a simple macro to
define a list of symbols:
MACRO
DEFINE LIST
DO .LP, K=1, N .LIST
LIST(K,1)
SET LIST(K, 2)
.LP
NULL # MARK END OF DO LOOP
MEND
If the macro were called by the following line:
DEFINE «SYMB, 5), (MATRIX (2),7), (CC, 11))
it would expand to:
SYMB
MATRIX (2)
CC
SET 5
SET 7
SET 11
Some of the major macro functions are:
1. IS (expression, string) is replaced by string if
the value of expression is nonzero; otherwise,
the result is the null string.
2. IFNOT(string) is replaced by string if the
expression in the previously evaluated IS had a
value of zero; otherwise, the result is null.
3. STR(exPl, exp2, string) is replaced by exp2
characters starting with the expl character of
string.
4. MTXT (tsym ) is replaced by the character
string which is the value of the TEXT symbol
tsym.
5. MTYP (symb) is replaced by the character that
represents the type of the variable symbol
symb.
6. MSUB (string) is replaced by the result of doing
macro argument substitution on string a second
time.
7. SYSLST(exp) is replaced by the expth argument of the macro call.
8. MDO(DO parameters; string) is a horizontal
DO loop where string is the range of the loop.
Each time around, the loop produces the value
of string, which is normally dependent on the'
DO variable symbol.
Keyword argulllents
When the macro is called, keyword arguments are
indicated by the parameter name followed by an equal
sign and the argument string. An example would be
the following calls of a MOVE macro:
MOVE
MOVE
Macro functions
To provide more flexibility with the use of macros,
several system parameters and macro functions have
been made available. Macro functions are built-in
functions that are replaced by a string of characters.
This string, called the result, is determined by the
particular function and its arguments. The arguments
of a macro function may consist of macro parameters,
other macro function calls, literal character strings, or
symbolic variables. An example would be the DEC
macro function, which has one argument, either a
valid arithmetic or logical expression. The result is the
decimal number equal to the value of the expression;
the call DEC (7 +8) would be replaced by 15.
5
FROM=NEWDATA, TO=OLDDATA
or
TO=OLDDATA, FROM=NEWDATA
Both calls will yield the same expansions as the expansion of the MOVE macro using normal arguments:
MOVE NEWDATA,OLDDATA
Default arguments
Default strings are used whenever an argument is
omitted from a macro call. The default string is assigned on the macro prototype line by an equal sign
and the desired default string after the dummy parameter name. Although the notation is the same, default
arguments are completely independent of the use of
keyword arguments.
6
Fall Joint Computer Conference, 1970
Marco pseudo-operations
The ARGS pseudo-operation provides a method of
declaring an auxiliary parameter list which supplements the parameter list declared on the prototype
statement. These parameters may also be assigned
default values.
The parameters defined on an ARGS line may be
used anywhere a normal parameter may be used. The
parameter values may be reset by the use of keyword
arguments.
I t is also possible for the programmer to reset his
named macro argument values anywhere within a
macro by using the MSET pseudo-operation. For
example:
PARM MSET DEC(PARM)
would change the value of P ARM to its decimal value.
The following is an example of the use of the ARGS
pseudo-operation:
MACRO
FUN NUMBER
ARGS WORD = (ONE, TWO, THREE)
#
NUMBER=WORD (NUMBER) .
MEND
When the macro is called by FUN 1 + 1, the following
comment would be generated:
# l+l=TWO
but the call FUN 1+1, WORD = (EIN, ZWEI, DREI)
would generate:
# 1+1=ZWEI
Text manipulating facilities
Some of the more exotic features provided by SWAP
are the character string pseudo-operations and the
dollar macro call.
HUNT and SCAN pseudo-operations
The HUNT pseudo-operation allows the programmer
to scan a string of characters for any. break character
in a second string. It will then define two TEXT
symbols consisting of the portions of the string before
and after the break character. For example, the
statements:
BRKS TEXT
HUNT
'+-*/'
.LOC, TOKEN, REMAIN,
'LSIZE *ENTS', BRKS
will result in the symbols TOKEN and REMAIN
having the string values of 'LSIZE' and '*ENTS' respectively. If one of the characters inBRKS could not
be found in the scanned string, then a JUMP to the
statement labeled .LOC would occur.
The SCAN pseudo-operation provides the extensive
pattern matching facilities of SNOBOL3 I along with
success or failure transfer of control. This pseudooperation is written:
where TSYM is a previously defined string valued
variable. The SNOBOL3 notation is used to represent
the pattern elements PI through P n as well as the GO TO
field. See the references for a more detailed presentation
of these facilities.
Dollar functions
Dollar functions are very similar to macro functions
in that the result of a dollar function call is a string of
characters that replace the call. However, these functions may be used on input lines as well as in macros.
The dollar functions provide the ability to call a oneline macro anywhere on a line by preceding the macro
name with a dollar sign and following it with the argument list in parenthesis. For example, the macro:
MACRO
CHECK
A,B
IS(AO
MEND
MACRO
PRINT FMT
DO
K~=2,N.SYSLST
t. CHECR FOR ITERATIVE LISTS
IS (. STR (1, 1, SYSLST (K~) ) ' : ' (', ITEMI)IFNOT(ITMI:DEC(KI) TEXT)
'SYSLST(KI) ,
.X
NULL
MOO (K~=2, N. SYSLST; MTXT (ITMI :DEC (K~»
)
FMT
OU1'_
.x
MEND
8B
80
Fall Joint Computer Conference, 1970
MACRO
FMT
t.
OUT
KI SET 1;JI SET 0 ;JJI SET 0
.LP
EDIT
• NEXT
GENERATE A LINE OF PRINTOUT
MSUB(MTXT(FMT:_:DEC(KI»)
JUMP .LP,SET(KI,KI+1) SFMT:_L It HAS FORMAT BEEN EXHAUSTED
JUMP
.OUT,JI~N.SYSLSTIJISJJI
tt WHEN PRINT LIST
EXHAUSTED OR NOTHING BEING DONE
JJI
SEl'
JI
.RLP
EDIT
• NEXT
It BACK UP TO LAST LEFT PAREN
MSUB(STR(FMT:_K,SOO,MTXT(FMT:_:DEC(FMT:_R»»
JUMP .RLP SET (KI,FMT:_P.+ 1) >FMT:_L&JJI '
MEND
I
MACRO
FMT
.t SLASH
BRK_S
BRK_C
FMT:_:DEC{~LlNES)
AI
SET
0 ;ILINES
MEND
TEXT 'MDO(KI=1,AI;MTXT(ITMI:DEC(KI)}) ,
SET 'LINES.'
I
MACRO
BRK Q
•• QUOTED STRING
ITM%:DEC(SET(A%,A'.1» TEXT 'Q.MTXT(REM')·
REM % TEXT
'STR(K.Q.MTXT(REM')+2,99,MTXT(REMi»
•
MACRO
BRK_H
ITMI:DEC(SET(AI,AI+1»
REMI
,
t
MEND
TEXT
tt HOLERITH STRING
TEXT 'STR(2,TRMI,MTXT(REMI»'
'STR(TRMI+1,99,MTXT(REMI»'
MEND
t.
LN
MACRO
FTYP_I
INTEGER
MSET
STR(2,10,MTXT(TYPI»
OP
MSET
DEC (MAX (1, DUP~) )
ITMI:DEC(SET(Ai,AI+1»
I.DEC (JI»
TEXT
;I.DEC (I.SYSLST (SET
':I.MDO(IN=1,MIN(DP,I.N.I.SYSLST(J~,JI+1»
MEND
,LN,'
'»'
I
MACRO
FTYP X
ITMI:DEC(SET(AI,A'+1»
MEND
It BLANKS
TEXT 'MDO(NI=1,MAX(1,DUPI); )'
8D
8E
Fall Joint Computer Conference, 1970
MACRO
END
SYSPRINT EDIT OFF
MEND
FORT_PROG
I I TERMINATE SOURCE
tt. END OF SOURCE
LI~TING
PPOGRA~
It NOW EXECUTE SOURCE PFOGRAM
t t TERM! N1\ TE RUN
FORT_PROO
END 1
MEND
I
FORMAT
OPBITS
END
OPBITS ON(ACTIV~
OPBITS OFF (CONT)
END
ON(ACTIV~
t
ALLOW THESE OPS TO EXPAND
DURING MACRO DEFINIT!ON
t NO CONTINUATION
ALLOWED FOR END
MACRO
EDIT
OPBITS ON(ACTIVE)
•
EDIT
ON (FORMAT, END)
MACRO
t MAKE ENTIRE PROGRAM A MACRO DEFINITION
FORT_PROG
SYSPRINT EDIT • NEXT
•• EJECT TO NEW PAGE
1
PRINT
EDIT ON
It PRODOCE SOURCE LISTING
Definition mechanisms in extensible
programming languages
by STEPHEN A. SCHU1V[AN*
U niversite de Grenoble
Grenoble, France
and
PHILIPPE JORRAND
Centre Scientifique IBM-France
Grenoble, France
INTRODUCTION
1. A base language, encompassing a set of indispensable programming primitives, organized so
as to constitute, in themselves, a coherent
language.
2. A set of extension mechanisms, establishing a
systematic framework for defining new linguistic
constructions in terms of already existing ones.
The development of extensible programming languages
is currently an extremely active area of research, and
one which is considered very promising by a broad
segment of the computing community. This paper represents an attempt at unification and generalization of
these developments, reflecting a specific perspective on
their present. direction of evolution. The principal influences on this work are cited in the bibliography, and
the text itself is devoid of references. This is indicative
of the recurring difficulty of attributing the basic ideas
in this area to any single source; from the start, the
development effort has been characterized by an exceptional interchange of ideas.
One simple premise underlies the proposals for an
extensi hIe programming language: that a "user" should
be capable of modifying the definition of that language,
in order to define for himself the particular language
which corresponds tb his needs. While there is, for the
moment, a certain disagreement as to the degree of
"sophistication" which can reasonably be attributed to
such a user, there is also a growing realization that the
time is past when it is sufficient to confront him with
a complex and inflexible language on a "take it or
leave it" basis.
According to the current conception, an extensible
language is composed of two essential elements:
Within this frame of reference, an extended language is
that language which is defined by some specific set of
extensions to the given base language. In practice,
definitions can be pyramided, using a particular extended language as the new point of departure. Implicit
in this approach is the assumption that the processing
of any extended language program involves its systematic reduction into an equivalent program, expressed
entirely in terms of the base language.
Following a useful if arbitrary convention, the extension mechanisms are generally categorized as either
semantic or syntactic, depending on the capabilities that
they provide. These two types of extensibility are the
subjects of subsequent· sections, where models are developed for these mechanisms.
Motivations for extensible languages
The primary impetus behind the development of
extensible languages has been the need to resolve what
has become a classic conflict of goals in programming
language design. The problem can be formulated as
* Present address: Centre Scientifique IBM-France
9
10
Fall Joint Computer Conference, 1970
power oj expression versus economy oj concepts. Power
of expression encompasses both "how much can be
expressed" and "how easy it is to express". It is essenti ally a question of the effectiveness of the language,
as seen from the viewpoint of the user. Economy of
concepts refers to the idea that a language should
embody the "smallest possible number" of distinguishable concepts, each one existing at the "lowest possible
level". This point of view, which can be identified with
the implementer, is based on efficiency considerations,
and is supported by a simple economic fact: the costs
of producing and/or using a compiler can become prohibitive. Since it is wholly impractical to totally disregard either of these competitive claims, a language
designer is generally faced with the futile task of
reconciling two equally important but mutually exclusive objectives wit.hin a single language.
Extensible languages constitute an extremely pragmatic response to this problem, in the sense that they
represent a means of avoiding, rather than overcoming
this dilemma. In essence, this approach seeks to encourage rather than to suppress the proliferation of
programming languages; this reflects an increasing disillusionment with the "universal language" concept,
especially in light of the need to vastly expand the
domain of application for programming languages in
general. The purpose of extensible languages is to establish an orderly framework capable of accommodating
the development of numerous different, and possibly
quite distinctive dialects.
In an extensible language, the criteria concerning
ecohomy of concepts are imposed at the point of formulating the primitives which comprise the base language.
This remains, therefore, the responsibility of the implementer. JVIoreover, he is the one who determines the
nature of the extension mechanisms to be provided.
This acts to constrain the properties of the extended
languages subsequently defined, and to effectively control the consistency and efficiency of the corresponding
compilers.
The specific decisions affecting power of expression,
however, are left entirely to the discretion of the user,
subject only to the restrictions inherent in the extension
mechanisms at his disposal. This additional "degree of
freedom" seems appropriate, in that it is after all the
language user who is most immediately affected by
these decisions, and thus, most competent to make the
determination. The choices "rill, in general, depend on
both the particular application area as well as various
highly subjective criteria. What is important is that
the decision may be made independently for each individual extended language.
At the same time, the extensible language approach
overcomes what has heretofore been the principal ob-
stacIe to a diversity of programming languages: incom.;.
patibility among programs written in different languages. The solution follows automatically from the
fact that each dialect is translated into a common base
language, and· that this translation is effected by essentially the same processor.
Despite the intention of facilitating the definition of
diverse languages, the extensible language framework
is particularly appropriate for addressing such significant problems as machine-to-machine transferability,
language and compiler standardization, and object code
optimization. The problems remain within manageable
limits, independent of the number of different dialects;
they need only be resolved within the restricted scope
of the base language and the associated extension
mechanisms.
Evolution oj extensible languages
An extensible language, according to the original
conception, was a high level language whose compiler
permitted certain "perturbations" to be defined. Semantic extension was formulated as a more flexible set
of data and procedure declarations, while syntactic
extension was confined to integrating the entities which
could be declared into a pre-established style of expression. For the most part, the currently existing extensible
languages reflect this point of departure.
It is nonetheless true that the basic research underlying the development of extensible languages has taken
on the character of an "attempt to isolate and generalize
the various "component parts" of programming languages, with the objective of introducing the property
of "systematic variability". A consequence of this effort
has been the gradual emergence of a somewhat more
abstract view of extensible languages, wherein the base
language is construed as an inventory of essential
primitives, the syntax of which minimally organizes
these elements into a coherent language. Semantic extension is considered as a set of "constructors" serving
to generate neW, but completely compatible primitives;
syntactic extension permits the definition of the specific
structural combinations of these primitives which are
actually· meaningful. Thus, extensible languages have
progressively assumed the aspect of a language definition framework, one which has the unique property
that an operational compiler exists at each point in the
definitional process.
Accordingly, it is increasingly appropriate to regard
extensible languages as the basis for a practical language
definition system, irrespective of who has responsibility
for language development. Potentially, such an environment is applicable even to the definition of non-
Definition Mechanisms in Extensible Programming Languages
extensible languages. Heretofore, it has been implied
that any given extended language was itself fully
extensible, since its definition is simply the result of
successive levels of extension. In conjunction with the
progressive generalization of the extension capabilities,
however, one is naturally led to envision a complementary set of restriction mechanisms, which would
serve to selectively disable the corresponding extension
mechanisms.
The intended function of the restriction mechanisms
is to eliminate the inevitable overhead associated with
the ability to accommodate arbitrary extension. They
would be employed at the point where a particular
dialect is to be "frozen". In effect, such restriction
mechanisms represent a means of imposing constraints
on subsequent extensions to the defined language (even
to the extent of excluding them entirely), in exchange
for a proportional increase in the efficiency of the
translator. The advantage of this approach is obvious:
the end result of such a development process is both a
coherent definition of the language and an efficient,
operational compiler.
Within this expanded frame of reference, most of the
extensible languages covered by the current literature
might more properly be considered as· extended languages, even though they were not defined by means of
extension. This is not unexpected, since they represent
the results of the initial phase of development. The
remainder of this paper is devoted to a discussion of
the types of extension mechanisms appropriate to this
more evolved interpretation of extensible languages.
The subject of the next section is semantic extensibility,
while the final section is concerned with syntactic
extensibility. These two capabilities form a sort of twodimensional definition space, within which new programming languages may be created by means of
extension.
SEMANTIC EXTENSIBILITY
In order to discuss semantic extensibility, it is first
necessary to establish what is meant here by the
semantics of a programming language. A program remains an inert piece of text until such time as it is
submitted to some processor: in the current context, a
computer controlled by a compiler for the language in
which the program is expressed. The activity of the
processor can be broadly characterized by the following
steps:
1. Recognition of a unit of text.
2. Elaboration of a meaning for that unit.
3. Invocation of the actions implied by that
meaning.
11
According to the second of these steps, the notion of
meaning may be interpreted as the link between the
units of text and the corresponding actions. The set of
such links will be taken to represent the semantics of
the programming language.
As an example, the sequence of characters "3.14159"
is, in most languages, a legitimate unit of text. The
elaboration of its associated meaning might establish
the following set of assertions:
-this unit represents an object which is a value.
-that value has a type, which is real.
-the internal format of that value is floatingpoint.
-the object will reside in a table of constants.
This being established, the .actions causing the construction and allocation of the object maybe invoked.
The set of assertions forms the link between the text
and the actions; it represents the "meaning" of 3.14159.
With respect to the processor, the definition of the
semantics of a language may be considered to exist in
the form of a description of these links for each object
in the domain of the language. When a programming
language incorporates functions which permit explicit
modification of these descriptions; then that language
possesses the property of semantic extensibility. These
functions, referred to as semantic extension mechanisms,
serve to introduce new kinds of objects into the language, essentially by defining the set of linkages to be
attributed to the external representation of those objects.
Semantic extension in the domain of values: A model
The objects involved in the processing of a program
belong, in general, to a variety of categories, each of
which constitutes a potential domain for semantic
extension. The values, in the conventional sense, obviously form one such category. In order to illustrate
the overall concept of semantic extensibility, a model
for one specific mechanism of semantic extension will
be formulated here. It operates on a description of a
particular category of objects, which encompasses a
generalization of the usual notion of value. For example,
procedures, structures and pointers are also considered
as values, in addition to simple integers, booleans, etc.
These values are divided into classes, where each
class is characterized by a mode. The mode constitutes
the description of all of the values belonging to that
class. Thus the mode of· a value may be thought of as
playing a role analogous to that of a data-type. It is
12
Fall Joint Computer Conference, 1970
assumed that processing of a program is controlled by
syntactic analysis. Once a unit of text has been isolated,
the active set of modes is used by the compiler to
elaborate its meaning. Typically, modes are utilized
to make sure that a value is employed correctly, to
verify that expressions are consistent, to effect the
selection of operations and to decide where conversions
are required.
The principal component of the semantic extension
mechanism is a function which permits the definition
of new modes. Once a mode has been defined, the
values belonging to the class characterized by that
mode may be used in the same general ways as other
values. That is to say, those values can be stored into
variables, passed as parameters, returned as results of
functions, etc.
The mode definition function would be used like a
declaration in the base language. The following notation
will be taken as a model for the call on this function:
mode u is T with 7r;
either the name of an existing mode or a constructor
applied to some combination of previously defined
modes. There are assumed to be a finite number of
modes predefined within the base language. In the
scope of this paper, int, real, bool and char are taken
to be the symbols representing four of these basic
modes, standing for the modes of integer, real, boolean
and single character values, respectively. Thus, a valid
mode definition might be:
m ode integer is int;
The model presented here also includes a set of mode
constructors, which act to create new modes from existing
ones. The following list of constructors indicates the
kinds of combinations envisioned:
1. Pointers
A pointer is a value designating another value.
As any value, a pointer has a mode, which
indicates that:
The three components of the definition are:
1. the symbol clause "mode u",
2. the type clause "is T",
3. the property clause "with 7r".
The property c1ause may be omitted.
The symbol clause
-it is a pointer.
-it is able to point to values of a specified class.
The notation ptr M creates the mode characterizing pointers to values of mode M. For example,
mode ppr is ptr ptr real;
specifies that values of mode ppr are pointers to
pointers to reals.
In the symbol clause, a new symbol u is declared as
the name of the mode whose description is specified
by the other clauses. For example,
mode complex is ...
may be used to introduce the symbol complex. In addition, the mode to be defined may depend on formal
parameters, which are specified in the symbol clause as
follows:
mode matrix (int
ill,
int n) is ...
The actual parameters would presumably be supplied
when the symbol is used in a declarative context, such as
matrix (4, 5)A;
The type clause
In the type clause, T specifies the nature of the values
characterized by the mode being defined. Thus, T is
2. Procedures
A procedure is a value, implying that one can
actually have procedure variables, pass procedures as parameters and return them as the
results of other procedures. Being a value, a
procedure has a mode which indicates that:
-it is a procedure.
-it takes a fixed number (possibly zero) of
parameters, of specified modes.
-it returns a result of a given mode, or it does
not return any result.
The notation proc (MI, ... , Mn) M forms the
mode of a procedure taking n parameters, of
modes MI ... Mn respectively, and returning a
value of mode M. As an example, one could
declare
mode trigo is proc (real)real;
Definition Mechanisms in Extensible Programming Languages
for the class of trigonometric functions, and then
mode trigocompose is proc (trigo, trigo)trigo;
for the mode of functions taking two trigonometric functions as parameters, and delivering a
third one (which could be the composition of
the first two) as the result.
3. Aggregates
Two kinds of aggregates will be described:
a. the tuples, which have a constant number of
components, possibly of different modes;
b. the sequences, which have a possibly variable
number of components, but of identical
modes.
a. Tuples
The mode of a tuple having n components
is established by the notation [M 1s1, ... ,
Mnsn], where M 1 ... Mn are the modes of
the respective components, and Sl ... Sn
are the names of these components, which
serve as selectors. Thus, the definition of
the mode complex might be written.
mode complex is [real rp, real ip];
If Z is a complex value, one might write
Z.rp or Z.ip to access either the real part
or the imaginary part of Z.
b. Sequences
The mode of a sequence is constructed by
the notation seq (e)M, where e stands for an
expression producing an integer value, which
fixes the length of the sequence; the parenthesized expression may be omitted, in
which case the length is variable. The
components, each having mode M, are
indexed by integer values ranging from 1
to the current length, inclusively. The
mode for real square matrices could be
defined as follows:
mode rsqmatrix (int n)
is seq (n) seq (n) real;
If B is a real square matrix, then the notation B(i)(j) would provide access to an individual component.
4. Union
The union constructor introduces a mode characterizing values belonging to one of a specified
13
list of classes. The notation union (MI' ... , 1\1: n)
produces a mode for values having anyone of
the modes 1\1: 1... Mil' Thus, if one defines
mode procir is proc (union (int, real));
this mode describes procedures taking one parameter, which may be either an integer or a
real, and returning no result. A further example,
using the tuple, pointer~ sequence and union
constructors, shows the possibility of recursive
definition:
mode tree
is [char root,
seq ptr union (char, tree) branch];
The list of mode constructors given above is intended
to be indicative but not exhaustive. Moreover, it must
be emphasized that the constructors themselves are
essentially independent of the nature and number of
the basic modes. Consequently, one could readily admit
the use of such constructors with an entirely different
set of primitive modes (e.g., one which more closely
reflects the representations on an actual machine).
What is essential is that the new modes generated by
these constructors must be usable in the language in
the same ways as the original ones.
The property clause
The property clause "with 7r" when present, specifies
a list of properties possessed by the values of the mode
being defined. These properties identify a sub-class of
the values characterized by the mode in the type clause.
Two kinds of properties are introduced for the present
model: transforms and selectors.
1. Transforms
The transforms provide a means of specifying
the actions to be taken when a value of mode
M1 occurs in a context where a value of mode
M2 is required (1\1:1~M2). If M is the mode
being declared, then two notations may be used
to indicate a transform:
a. "from M1 by V.E1," which specifies that a
value of mode M may be produced from a
value of mode M1 (identified by the bound
variable V) by evaluating the expression E 1.
14
Fall Joint Computer Conference, 1970
b. "into M2 by V.E2'" which specifies that a
value of mode M2 may be produced from a
value of mode M (identified by the bound
variable V) by evaluating the expression E 2.
The following definitions provide an illustration:
mode complex
is [real rp, real ip]
with from real
by x. [x, 0.0],
into real
by y. (ify.ip=O
then y.rp
else error) ;
mode imaginary
is [real ip]
with from complex
by x. (if x.rp = 0
then [x.ip]
else error),
into complex
by y. [0.0, y.ip];
By the transforms in the above definitions, all of
the natural conversions among real, complex,
and imaginary values are provided. It must be
noted that the system of transformations
specified among the .modes may be. represented
by a directed graph, where the nodes correspond
to the modes, and the arcs are established by
the from and into transforms. Thus, the rule to
decide whether the transformation from Ml into
1\112 is known might be formulated as follows:
There must exist at least one path from MI
to M 2 •
n. If there are several paths, there must exist
one which is shorter than all of the others.
lll. That path represents the desired transformation.
1.
2. Selectors
The notation "take 1\1 1s as V.E" may appear in
the list of properties attached to the definition
of the mode M. It serves to establish the name
"s" as an additional selector which may be
applied to values of mode M to produce a value
of mode MI. Thus, if X is a value of mode M,
then the effect of writing "X.s" is to evaluate
the expression E (within which V acts as a
bound variable identifying the value X) and to
transform its result into a value of mode MI.
As au example, the definition of complex might
be augmented by attaching the following two
properties:
take real mag as Z. (sqrt (Z. rp
i
2+Z.ip
i
2»,
take radian ang as Z. (arctan (Z.ipjZ.rp»;
The mode radian is presumed to be defined elsewhere, and to properly characterize the class of
angular values.
As with the case of the constructors, the properties
presented here are intended to suggest the kinds of
facilities which are appropriate within the framework
established by the concept of mode.
In summary, it must be stressed that the model developed here is applicable only to one particular category of objects, namely the values on which a program
operates. Clearly, there exist other identifiable categories which enter into the processing of a program
(e.g., control structure, environment resources, etc.).
It is equally appropriate to regard these as potential
domains for semantic extensibility. This will no doubt
necessitate the introduction of additional extension
mechanisms, following the general approach established here. As the number of mechanisms is expanded,
the possibility for selective restriction of the extension
capabilities will become increasingly important. The
development of the corresponding semantic restriction
mechanisms is imperative, for they are essential to the
production of specialized compilers for languages
defined by means of extension.
SYNTACTIC EXTENSIBILITY
A language incorporating functions which permit a
user to introduce explicit modifications to the syntax
of that language is said to possess the property of
syntactic extensibility. The purpose of this section is to
establish the nature of such a facility. It is primarily
devoted to the development of a model which will serve
to characterize the mechanism of syntactic extension,
and permit exploration of its definitional range.
It must be made explicit that, when speaking of
modifications to the syntax of a language, one is in fact
talking about actual alterations to the grammar which
serves to define that syntax. For a conventional language, the grammar is essentially static. Thus, it is
conceivable that a programmer could be wholly unaware of its existence. The syntactic rules, which he is
nonetheless constrained to observe (whether he likes·
them or not), are the same each time he writes a pro-
Definition Mechanisms in Extensible Programming Languages
gram in that language, and no deviation is permitted
anywhere in the scope of the program. The situation is
significantly different for the case of a syntactically
extensible language. This capability is provided by
means of a set of functions, properly imbedded in the
language, which acts to change the grammar. Provided
that the user is cognizant of these functions and their
grammatical domain, he then has the option of effecting
perhaps quite substantial modifications to the syntax of
that language during the course of writing a program in
that language; this is in parallel with whatever semantic
extensions he might introduce. In effect, the grammar
itself becomes subject to dynamic variation, and the
actual syntax of the language becomes dependent on
the program being processed.
The syntactic macro mechanism: A model
The basis of most existing proposals for achieving
syntactic extensibility is what has come to be called
the syntactic macro mechanism. A model of this mechanism is introduced at this point in order to illustrate
the possibilities of syntactic extension. The model is
based on the assumption that the syntactic component
of the base language, and by induction any subsequent
extended language, can be effectively defined by a
context-free grammar (or the equivalent BNF representation). This relatively simple formalism is adopted
as the underlying definitional system despite an obvious
contradiction which is present: a grammar which is
subject to dynamic redefinition by constructs in the
language whose syntax it defines is certainly not
"context-free" in the strict sense. Therefore, it is only
the instantaneous syntactic definition of the language
which is considered within the context-free framework.
The most essential element of the syntactic macro
mechanism is the function which establishes the definition of a syntactic macro. It must be a legitimate linguistic construct of the base language proper, and its
format would likely resemble any other declaration in
that language. The following representation will be
used to model a call on this function:
macro cp where
7r
means p;
The respective components are:
cp, the production;
7r,
the predicate; and
p,
the replacement.
The macro clause would be written in the form
macro
C~'phrase'
15
where C is the name of a category (non-terminal)
symbol in the grammar, and the phrase is an ordered
sequence, Sl ... Sn, such that each constituent is the
name of a category or terminal symbol. Thus the production in a macro clause corresponds directly to a
context-free production. The where and means clauses
are optional components of the definition, and will be
discussed below.
A syntactic macro definition differs from an ordinary
declaration in the base language in the sense that it is a
function operating directly on the grammar, and takes
effect immediately. In essence, it incorporates the
specified production into the grammar. Subsequent to
the occurrence of such a definition in a program, syntactic configurations conforming to the structure of the
phrase are acceptable wherever the correspondingcategory is syntactically valid. This will apply until such
time as that definition is, in some way, disabled. As an
example, one might include a syntactic macro definition
starting with
macro
FACT~'PRIlVI
!'
for the purpose of introducing the factorial notation
into the syntax for arithmetic expressions. Within the
scope of that definition, the effect would be the same as
if the syntactic definition of the language (represented
in BNF) incorporated an additional alternative
(factor): : = . ..
I (primary)!
Thus, in principle, a statement of the form
c : = nl/((n-m)! *m!);
might become syntactically valid according to the
active set of definitions.
The production
The role of the production is to establish both the
context and the format in which "calls" on that macro
may be written. The category name on the left controls
where, within the syntactic framework, such calls are
permitted. One may potentially designate any category
which is referenced by the active set of productions.
The phrase indicates the exact syntactic configuration
which is to be interpreted as a call on that particular
macro. In general, one may specify any arbitrary sequence (possibly empty) of symbol names. The constituents may be existing symbols, terminals which
'were not previously present, or categories to be defined
in other macros. This is of course, subject to the constraint that the grammar as a whole must remain both
16
Fall Joint Computer Conference, 1970
well-formed and non-ambiguous, if it is to fulfill its
intended function.
In addition, the macro clause serves to declare a set
of formal parameters, which may be referenced elsewhere in the definition. Each separate call on that
macro can be thought of as establishing a local syntactic
context, defined 'with respect to the complete syntax tree
which structurally describes the program. This context
would be relative to the position of the node corresponding to the specified category, and would include
the immediate descendants of that node, corresponding
to the constituents of the phrase. Ata call, the symbol
names appearing in the production are associated with
the actual nodes occurring in that context. Thus, the
terminal names represent an individual instance of
that terminal, and the category names represent some
complete syntactic sub-tree belonging to that category.
In order to distinguish between different formal parameters having the same name, the convention of subscripting the names will be adopted here; this notation
could readily be replaced by declaration of unique
identifiers.
The replacement
The means clause specifies the syntactic structure
which constitutes the replacement for a call on that
particular macro. It is written in the form
means 'string'
where the string is an ordered sequence, composed of
either formal parameters or terminal symbol names.
An instance of this string is generated in place of every
call on that macro, within which the actual structure
represented by a formal parameter is substituted for
every occurrence of its name. If the complete syntactic
macro definition for the factorial operator had been
macro
panded. In effect, the meaning of every new construct
introduced into the language is defined by specifying
its systematic expansion into the base language. Accordingly, one might consider syntactic extension
merely as a means for permitting a set of "systematic
abbreviations" to be defined "on top of" the base
language.
An important consequence of the fact that a syntactic
macro definition is itself a valid element of the base
language is that such definitions may occur in the context of a replacement. This is illustrated by the following example, showing how a declaration for "pushdown stack" might be introduced:
macro DECLo~'TYPEI stack [EXPR1] IDEN1;'
means
'TYPE 1 array [1:EXPR 1] IDEN 1 ;
integer level_IDEN 1 initial 0;
macro PRIMo~'depth_IDEN l'
means 'res (EXPR1)';
macro PRIMl~'IDENl'
means '(if level_IDENI >0
then
(IDENI [level_IDEN 1],
level_IDEN1 : =
level_I DEN 1 -1;)
else
error ("overdraw
IDEN 1 "))';
macro REFRo~'IDEN l'
means '(if level_IDEN I <
depth_IDENI
then
(level_IDEN 1 : =
level_IDEN 1 1;
IDEN 1 [level_IDEN1])
else
error ("overflow
IDEN1"))';';
+
FACTo~'PRIMl!'
means 'factorial (PRIM 1) , ;
Thus a declaration of the form
integer stack [K] S;
then each call on this macro would simply be replaced
by a call on the procedure named "factorial", assumed
to be defined elsewhere.
When present, the means clause establishes the
semantic interpretation to be associated with the corresponding production; if absent, then presumably the
construct is only an intermediate form, whose interpretation is subsumed in some larger context. The
"meaning," however, is given as the expansion of that
construct into a "logically lower level language" .
While the replacement may be expressed in terms of
calls on other syntactic macros, these will also be ex-
would generate not only the necessary array for holding
the contents of the stack, but also several other declarations, including:
1. An integer variable, named level_S, corre-
sponding to the level counter of the stack. It is
initialized to zero on declaration.
2. A literal, written "depth_S," for representing
the depth of that stack. Its expansion is given
in terms of the operator res, which is taken to
mean the result of a previously evaluated ex-
Definition 1\{echanisms in Extensible Programming Languages
pression, and presumed to be defined accordingly.
3. A macro definition (PRIlVh) which establishes,
by means of a compound expression, the interpretation of the stack name in "fetch-context".
This allows one to write "N: = S;" for removing
the value from the top of the stack S and assigning it to the integer variable N.
4. A macro definition (REFRo) which establishes
the corresponding "store context" operation.
One can then write "S: = 5 ;" to push a new value
into the stack.
3.
17
Si~'phrase'
\vhere Si is a previously declared parameter
representing a category, and the phrase is written
analogously to that of the production in a macro
clause. It verifies whether the immediate substructure of the specified parameter corresponds
to the indicated configuration. The constituents
of the phrase are also declared as formal parameters. An interesting example is suggested by a
peculiarity in PL/l, wherein the relation
"7 <6<5" is found to be true. A possible
remedy might be formulated as follows:
macro RELo~'REL1STAT 1
A PROCl~'HEADl ... '
A HEADl~'IDENl:proc ... '
The ellipsis notation is introduced with the
framework of functions (3) and (4) to indicate
that the structure of the corresponding constituents is irrelevant [and indeed, it may not
even be knowable in the contexts that can be
established by functions (5) and (6)].
7. 3 Si~'string'
which is successful on· the condition that the
string (generated analogously to the replacement
string) is directly reducible to the category
specified by Si, which is also declared as a formal
parameter to represent the cOIhpleted sub-tree
reflecting the analysis.
8. 3 Si{='string'
which is analogous to function (7), but the condition is generalized to verify whether the string
is reducible (regardless of the depth of the
structure) to the specified category. The definition of the "maximum" function, which requires
two syntactic macros, provides an interesting
example:
macro PRIMo~'max (EXPRLIST 1 ) ,
where EXPRLIST l~'EXPRl'
means '(EXPR l)';
macro PRIMl~'max (EXPRLIST l)'
where EXPRLIST ]~'EXPRLIST 2,
EXPR 2 '
A 3 PRIM 2{='max (EXPRLIST 2)'
means '(if PRIJ\1: 2 > EXPR 2
then res PRIM 2
else res (EXPR 2))"
9. P (arguments)
where P is the name of a semantic predicate, and
the arguments may be either formal parameters
or terminal symbols. Such conditions constitute
a means of imposing non-syntactic constraints
on the definition of a syntactic macro. They are
especially applicable in those situations where
it is necessary to establish the mode of a particular entity. For example, one might rewrite the
factorial definition as follows:
macro FACTo~'PRIMl!'
where is_integer (PRIM l )
means 'factorial (PRIl\1: l)' ;
In this form the definition also has the effect
of allowing different meanings to be associated
with the factorial operator, dependent on the
mode of the primary.
10. 3 Si: F (arguments)
Where F is the name of a semantic function
which conditionally returns a syntactic result.
Si is also declared as a formal parameter to represent this result. The semantic functions and
predicates establish an interface whereby it is
possible to introduce syntactic and semantic
interdependencies. A likely application of semantic functions would be definitions involving
identifiers:
where 3 LABL l : newlabel (IDENl) ...
A particularly intriguing possibility is to provide a semantic function which evaluates an
arbitrary expression:
where 3 CONST 1: evaluate (EXPR 1)
.•.
Obviously, this concept could be expanded to
encompass the execution of entire programs, if
desired.
I t is evident that the role of the where clause in a
syntactic macro definition is to provide a framework
for specifying those properties which effectively cannot
be expressed within the context-free constraints. The
fashion in which they are isolated allows these aspects
to be incorporated without sacrificing all of the practical advantages which come from adopting a relatively
simple syntactic formalism as the point of departure.
With respect to the model presented here, however, it is
nonetheless clear that the definitional power of the
syntactic macro mechanism is determined by the power
of the predicates.
Operationally, the syntactic macro mechanism can
be characterized by three distinct phases, each of which
is briefly considered below.
Definition phase
The definition phase encompasses the different functions incorporated within the base language which act
to insert, delete or modify a syntactic macro definition.
Together, they constitute a facility for explicitly editing
the given grammar, and are employed to form what
might be called. the active syntactic definition. This consists of the productions of the currently active syntac-
Definition Mechanisms in Extensible Programming· Languages
tic macros (with their associated predicates and replacements), plus the original productions of the base
language. An interesting generalization would be to
provide a means of selectively eliminating base language productions from the active syntactic definition,
there by excluding those constructions from the source
language; they would still remain part of the base
language definition, however, and continue to be considered valid in the context of a replacement. In this
fashion, the syntax of an extended language could be
essentially independent of the base language syntax,
thus further enhancing the definitional power of the
syntactic macro mechanism.
Interpretation phase
The interpretation phase includes the processing of
syntactic macro calls. It consists of three separate
operations: (1), recognition of the production; (2),
verification of the predicate; and (3), generation of the
replacement. Obviously, these operations must proceed concurrently with the process of syntactic analysis,
since syntactic macro expansion is incontestably a
"compile-time facility". Given the present formulation
of the syntactic macro mechanism, some form of what
is called "syntax directed analysis" suggests itself
initially as the appropriate approach for the analyzer.
It must be observed that the character of the analysis
procedure is constrained to a certain extent by the
nature of the predicates contained within the active
syntactic definition. Furthermore, the presence of
semantic predicates and functions precludes realization
of the analyzer/generator as a pure preprocessor.
In general, there will be the inevitable trade-off to
be made between power of definition and efficiency of
operation. It is pointless to pretend that this trade-off
can be completely neglected in the process of formulating the syntactic definition of a particular extended
language. However, deliberate emphasis has been given
here to power of definition, with the intention of providing a very general language development framework,
one which furnishes an operational compiler at every
stage. It is argued that the problem of obtaining an efficient compiler properly belongs to a subsequent phase.
Restriction phase
The restriction phase, as construed here, would be a
separate operation, corresponding to the automatic
consolidation of some active syntactic definition in
order to provide a specialized syntactic analyzer for
that particular dialect. The degree to which this
19
analyzer can be optimized is determined both by the
syntactic complexity of the given extended language,
and by the specific constraints on further syntactic
extension which are imposed at that point. If subsequent extensions are to be permitted, they might be
confined within extremely narrow limits in order to
improve the performance of the analyzer; they may be
excluded entirely by suppressing the syntactic definition functions in the base langua'ge. In either case,
various well-defined sub-sets of context-free grammars,
for which explicit identification and efficient analysis
algorithms are known to exist, constitute a basis for
establishing the restrictions. This represents the greatest practical advantage of having formulated the syntactic definition essentially within the context-free
framework.
In conclusion, it is to be remarked that syntactic
extensibility is especially amenable to realization by
means of an extremely powerful extension mechanism
in conjunction with a proportionally powerful restrictions mechanism. This approach provides the essential
definitional flexibility, which is a prerequisite for an
effective language development tool, without sacrificing
the possibility of an efficient compiler. In the end,
however, the properties of a particular extended language dictate the efficiency of its processor, rather than
the converse. This is consistent with the broadened
interpretation of extensible languages discussed in this
paper.
BIBLIOGRAPHY
1 T E CHEATHAM JR
The introduction of definitional facilities into higher level
programming languages
Proceedings of AFIPS 1966 Fall Joint Computer Conference
Second edition Vol 29 pp 623-637 November 1966
2 T E CHEATHAM JR A FISCHER Ph JORRAND
On the basis for ELF-an extensible language facility
Proceedings of AFIPS 1968 Fall Joint Computer Conference
Vol 33 Part 2 pp 937-948 November 1968
3 C CHRISTENSEN C J SHAW Editors
Proceedings of the extensible languages symposium
Boston Massachusetts May 1969 SIGPLAN Notices
Vol 4 Number 8 August 1969
4 B A GALLER A J PERLIS
A proposal jor definitions in ALGOL
Communications of the AGM Vol 10 Number 4 pp
204-299 April 1967
5 J V GARWICK
GPL, a truly general purpose language
Communications of the ACM Vol 11 Number 9 pp
634-639 September 1968
6 E T IRONS
Experience with an extensible language
Communications of the ACM Vol 13 Number 1 pp 31-40
January 1970
20
Fall Joint Computer Conference, 1970
7 Ph JORRAND
Some aspects of BASEL, the base language for an extensible
language facility
Proceedings of the Extensible Languages Symposium
SIGPLAN Notices Vol 4 Number 8 pp 14-17 August 1969
8 B M LEAVENWORTH
Syntax macros and extended translation
Communications of the ACM Vol 9 Number 11 pp 790-793
November 1966
9 M D McILROY
M aero instruction extensions to compiler languages
Communications of the ACM Vol 3 Number 4 pp 214-220
April 1960
10 A J PERLIS
The synthesis of algorithmic systems
First ACM Turing Lecture Journal of the ACM Vol 14
pp 1-9 January 1967
11 T A STANDISH
Some features of PPL, a polymorphic programming language
Proceedings of the Extensible Languages Symposium
SIGPLAN Notices Vol 4 Number 8 pp 20-26 August 1969
12 T A STANDISH
Some compiler-compiler techniques for use in extensible
languages
Proceedings of the Extensible Languages Symposium
SIGPLAN Notices Vol 4 Number 8 pp 55-62 August 1969
13 A VAN WIJNGAARDEN B J MAILLOUX
J E L PECK C H A KOSTER
Report on the algorithmic language ALGOL 68
MR 101 Mathematisch Centrum Amsterdam October 1969
14 B WEGBREIT
A data type definition facility
Harvard University Division of Engineering and Applied
Physics unpublished 1969
Vulcan-A string handling language
with dynamic storage control*
by E. F. STORlVI
Syracuse University
Syracuse, New York
and
R. H. VAUGHAN
National Resource Analysis Center
Charlottesville, Virginia
INTRODUCTION
meric computation is provisional in the sense that one
ordinarily wants to transform a piece of data only if
that datum (or some other) has certain properties.
For example, a certain kind of English sentence with
a verb in the passive, may want to be transformed
into a corresponding sentence with an active verb.
Or, in a theorem proving context, two formal expressions may have joint structural properties which permit
a certain conclusion to be drawn. In practice, however,
it is the rule rather than the exception that a datum
will fail to have the required property, and in such a
case one wishes that certain assignments of values had
never taken place. In order to accommodate these very
common situations the semantics of Vulcan are defined
and implemented so that changes to the work space
are provisional. While this policy requires some complex machinery to maintain internal storage in the
presence of global/local distinctions and of formal/
actual usage, these maintenance features give Vulcan
much of its power and flexibility.
3. Suppression of Bookkeeping Detail: A programmer should never need to concern himself with storage
allocation matters. Nor should there be troublesome
side effects of the storage maintenance conventions.
Specifically it should be possible to call a set of parameters by name in invoking a procedure or subroutine
so that changes to the values of actual parameters may
easily be propagated back to the calling context. In
such a case no special action should be required from
the programmer. In addition the details of the scan of
a symbol string to locate an infix substring should
never intrude on the programmer's convenience. And
the use of local/global distinctions and formal/actual
The implementation of the man-machine interface
for question-answering systems, fact-retrieval systems
and others in the area of information management
frequently involves a concern with non-numeric programming techniques. In addition, theorem proving
algorithms and more sophisticated procedures for
processing natural language text require a capability
to manipulate representations of non-numeric data
with some ease, and to pose complex structural questions about such data.
This paper describes a symbol manipulation facility
which attempts to provide the principal capabilities
required by the applications mentioned above. In
order to reach this goal we have identified the following
important and desirable characteristics for a set of
non-numeric programming capabilities.
1. Conditional Expressions: Since the formal representations of non-numeric information are ordinarily
defined inductively, it is to be expected that algorithms
to operate on such representations will also be specified
inductively, by cases. A conditional language structure
seems appropriate for a "by-cases" style of programming.
2. Storage Maintenance: Assemblers and other higher-level langua,ges eliminate many of the troublesome
aspects of the storage allocation problem for the user.
Very little use has been made, however, of more sophisticated storage maintenance functions. N on-nu-
* This work was supported by the National Resource Analysis
Center in the Office of Emergency Preparedness.
21
22
Fall Joint Computer Conference, 1970
usage should require no special action in a recursive
situation.
4. Numeric Capabilities: It should be possible to
perform routine counting and indexing operations in
the same language contexts that are appropriate for
processing symbol strings. At the same time, more
complex numerical operations should be available, at
least by means of linkage to a conventional numerical
language.
5. Input/Output: Comprehensive file declaration
and item handling facilities should be included if the
non-numeric features are to be useful in realistic applications. Simple formatting conventions should be available to establish a correspondence between the fields
of a record and a suitable set of symbol strings.
6. Interpretive Execution: There is little penalty
associated with the interpretive execution of nonnumeric algorithms, since the bulk of the system's
resources are concerned with accommodating a sequential, fixed~field system to a recursive, variable-field
process. In addition, interpretive execution is easier
to modify on a trial basis, and permits some freedom
in the modification of source language syntax, provided
there is an intermediary program to convert from
source code to the internally stored form, suitable
for interpretive execution.
While there are other desirable features for a very
general programming language, these were accepted
as a minimum set for exploratory purposes. An overall
goal was to attain a reasonably efficient utilization
of machine resources. In this implementation study
it was felt desirable to achieve running speed at the
expense of storage utilization if a choice were required.
Since most non-numeric computing processes are
thought to be slow in execution, it was decided to emphasize speed whenever possible in the Vulcan system.
List processing certainly plays a central role in the
applications contemplated here. But the Vulcan language was initially intended to be experimental and
to provide an exploration tool, and the implementation was therefore restricted to string manipulation,
elementary arithmetic and file handling.
OVERVIEW
The Vulcan language has been successfully implemented on a Univac 1108 system running under EXEC8, and a comprehensive programmer's reference manual
is available. 1 The emphasis in the implementation of
V ul~an has been on providing a powerful storage maintenance structure in place of complex and general elementary operations. From experience with applications this has been a satisfactory compromise. Ex-
travagant elementary operations have not been so
commonly needed, and when needed they are easily
supplied as specially tailored Vulcan procedures.
Storage maintenance for a recursive situation, on the
other hand, would be much more difficult to supply
in terms of more conventional programming language
structures.
V ulcan is an imperative rather than a functional
language. Since every call on a Vulcan procedure may
be treated both as. an imperative assertion and as a
Boolean expression there are places in the language
design where the notion of truth value assignment
has a character not predictable from more conventional usage. The conventions adopted to cover these
cases may be seen to be justified by their use in applications.
Since Vulcan is a conditional language there are
no labels and no GOTO statements. In a word, the
logical structure of an algorithm must be expressed
in purely inductive terms.
For the numerical calculations associated with a
string manipulation algorithm there are rudimentary
arithmetic operations and conversions between alphanumeric and binary, and there is a comprehensive
range test. All of these operations are defined only for
binary integers. 1\10re complex numerical processing
may be invoked by coding a Fortran program with
parameters passed to it from Vulcan. While there are
restrictions on this facility it has been found to be
more than adequate for the situations encountered so
far.
A complete package of' file processing functions is
available as an integral part of the Vulcan system.
Individual records can be read or written, files opened
or closed, temporary or permanent, on tape or mass
storage. By specifying a format in terms of lengths of
constituent substrings, a record can be directly decomposed into its fields by a single call on the item
handling facility. Calls on the item handler are compatible with the Boolean character of a Vulcan procedure.
There is an initial syntax scanner which puts the
Vulcan constructs into a standard form suitable for
interpretive execution. There are several constructs
which are admitted by the syntax scanner for which
there are no interpretable internal codes, and the
scanner is used to supply equivalent interpretable
internal codes for these situations. The ability to deal
with quoted material in any context appropriate to
an identifier is a case in point.
The scanner has been implemented so that a Vulcan
program may be punched on cards in free-field style.
There are no restrictions on the position of Vulcan
constructs on the program cards except that a dollar
VULCAN
sign (signalling a comment card) may not appear in
column 1, and columns 73-80 are not read.
The more common run-time errors are recognized
by the interpreter and there are appropriate error
messages. As with any non-numeric facility, restraint
and judgment are required to avoid situations where
excessive time or storage can be used in accomplishing
very little.
The entire Vulcan scanner/interpreter occupies
approximately 3900 words of core. A small amount of
storage is initially allocated for symbol tables and
string storage. When this storage is exhausted additional .5000 word blocks of storage are obtained from
the executive. Routine data processing computations
seem to make modest demands on storage, while a
theorem-prover may consume as much storage as is
given it.
A system written in Vulcan consists of a set of Vulcan
procedures. A procedure is a sequence of statements,
and a statement is a sequence of clauses. A clause is
conditional in character and consists of a series of basic
symbol manipulation functions, Input/Output operations, a limited set of arithmetic facilities, and procedure calls. The language is recursive in execution
so that a call on a procedure is executed in a context
which depends on the data available at the time the
call is made. The distinctions between local and global
identifiers and between formal and actual parameters
that are common to Algol are explicitly utilized in
Vulcan.
23
A facility exists to assign a literal string to an identifier:
(1) X = 'ABC'
(2) Y = (assigns the empty string to Y)
Quoted strings may be associated together from left to
right. Suppose one wishes to assign the following literal
string:
RECORDS CONTAINING 'ABC' ARE LOST.
The following literal assignment will create and store
the above string:
X = 'RECORDS CONTAINING'" , 'ABC' " ,
'ARE LOST.'
Spaces outside quote marks are ignored by the
translator. Note that five sub-strings are quoted in
the above literal assignment:
RECORDS CONTAINING
ABC
ARE LOST.
LANGUAGE DEFINITION
Symbol strings
A string is a sequence of zero or more occurrences
of characters from the UNIVAC 1108 character set.
In particular, the empty string, with zero character
occurrences, is an acceptable string. A string is normally referenced with an identifier and an identifier
to which no string has been assigned is said to be improper. (One common run-time error results from an
attempt to use an improper identifier in an incorrect
way.) A symbol string may also be quoted directly in
the context of an instruction. Except for the left-hand
side of an infix or assignment operation, anywhere that
a string identifier may be used, a quoted literal string
may be used in place of that identifier. For example,
both
(1) WRITE ('ABC')
and
(2) X = 'ABC', WRITE (X),
cause the string 'ABC' to be printed.
The string value of an identifier is called the referent
of that identifier and it may be changed as a result
of an operation. Note that the quote mark itself is
always quoted in isolation.
Language structure
The instructions In Vulcan are embedded in expressions which, like instructions, come out true or
false. A clause is an expression which has an antecedent
and a consequent part, separated by a colon, and
bounded by parentheses. The instructions are coded
in the antecedent and consequent parts and are separated \\1.th commas. For example,
where the ~i and Pi are Vulcan instructions.
A clause comes out true if all the instructions in the
antecedent part, executed from left to right, come out
ture. In this case, all the operations in the consequent
24
Fall Joint Computer Conference, 1970
part are executed, from left to right. For example, the
clause
will come out true and PI will be executed just in case
instruction cPI comes out true and instruction cP2 comes
out false (its negation making it true).
A clause with no antecedent part always comes out
true:
The consequent part of a clause may also be empty:
A program is a set of procedures with a period (.)
terminating the last procedure. The initial procedure
is executed first and acts as a driver or main program
for the system. All other procedures are executed only
by means of calls to them. The completion of this
initial procedure terminates the run.
String manipulation operations
There are two basic string manipulation instructions,
the concatenate operation and the infix test.
(cPI, cP2:)
A clause with neither an antecedent nor a consequent
part comes out true and performs no computation.
(:)
A statement is a series of clauses enclosed in square
brackets:
The consequent part of at most one clause will
be executed within a statement. Starting with the
left-most clause, if a particular clause comes out true
(as the result of all the tests in its antecedent part
coming out true), then, as soon as execution of all the
operations in the clause is finished, the remaining
clauses are skipped and execution begins in the next
statement. If a particular clause comes out false (as
the result of some test in its antecedent part coming out
false), then, execution begins on the next clause. If
any clause comes out true in a statement, then, the
statement is considered to come out true. If all clauses
in a statement come out false, then, the statement is
considered to come out false.
A procedure body is a sequence of statements
bounded by angle brackets, ', and preserve
the original.
Procedure INITIAL sets the values for the identifiers W, X, and Y and then calls procedure REP,
passing in the actual parameters W, X, Y, and Z to
formal parameters A, B, C, and D. (Note that W, X,
and Yare proper and that Z is improper when the call is
made.) Procedure REP then replaces all occurrences of
string B in string A with string C and calls the new
string D. Notice that if no occurrence of B is found
in A, then D is simply set to the referent of A. Called
with the input given in procedure INITIAL, REP will
set the referent of Z to 'LIST ITEl\1S IF AGE> 24
AND WEIGHT> 150'.
(2) 'll.ll.9.000'
PROCEDURE INITIAL;
(3) 'll.$ll.19.24'
(4)
LOCAL W, X, Y, Z;
'+ -86'
If the string to be converted· is not well-formed, then
BINARY(X) comes out false. If it is well-formed, then
the command comes out true and the referent of X is
the converted binary integer string, six characters in
length. If X is improper, error termination occurs.
Arithmetic operations are listed below.
means
X
(2) SUB (X, Y, Z)
means
X = Y - Z
(3) MPY (X, Y, Z)
means
X = Y
(4) DIV (X, Y, Z)
means
X = Yj Z
(5) SETZRO (X)
means X = 0
=
Y
+Z
(1) ADD (X, Y, Z)
([(: W = 'LIST ITEl\1S IF AGE GREATER THAN
24 AND WEIGHT GREATER THAN 150',
X = 'GREATER THAN', Y = '>', REP(W,
X, Y,Z»])
PROCEDURE REP (A, B, C, D);
LOCAL Xl, X2;
([(AjX1.B.X2 : REP (X2, B, C, D), D = X1.C.D)
( :D = A)])
*Z
where the identifiers Y and Z must have referents that
are binary integers, six characters in length. Each
operation always comes out true .. The operation DIV
(X, Y, Z) yields the integral quotient in X and discards
the remainder.
There is one numeric test:
RANGE (X, Y, Z),
where the identifiers· X, .Y, and Z must be binary integers, six characters in length. RANGE(X, Y, Z) comes
out true just in case X ~ Y ~ Z and comes out false
otherwise.
The following Vulcan· program illustrates the basic
operations and the language structure presented thus
far.
In this example, as part of a fact retrieval query
scheme, the task is to simplify an English language
sentence by replacing all occurrences of the string
INPUT OUTPUT OPERATIONS
The Input-Output operations in Vulcan fall into
two categories: (1) card reading and line printing
operations, and (2) file handling operations (for tapes,
Fastrand files, etc.).
Card read and line print
There are standard operations to read a string from
a card and to write a string on the line printer. The
instructions are as follows:
(1) WRITE (Xl, ... , XN)
(2) PRINT (Xl, ... , XN)
(3) READ (Xl, ... ,XN)
WRITE causes the referents of the strings for each
identifier in the list to be printed on successive lines.
PRINT, for each identifier in the list, writes out the
28
Fall Joint Computer Conference, 1970
identifier, followed by an ' =' sign, followed by the
string. If a string is longer than the number of print
positions on the line, remaining characters of the string
are printed on subsequent lines.
For each identifier in the list, READ reads the next
card and assigns the string of characters on the card
to the next identifier. Trailing blanks on a card are
deleted before assigning the string to the identifier.
If a blank card is read, the empty string is assigned
to the identifier.
The WRITE and PRINT operations always come
out true. READ comes out false if any EXEC 8 control card is read, but comes out true otherwise.
There is a modified version of READ available for
use with remote terminal applications which avoids
unwanted line feeds and carriage returns.
File handling operations
The traditional concept of reading and writing items
(logical records) and blocks (physical records) is extended in Vulcan to provide for the handling of individual fields within items. An item in a file is thought
of as a single string which may be decoded into various
substrings, or fields. Alternatively, a set of substrings,
or fields, may be grouped together to form an item
which is then put into a file. These two functions are
accomplished by the ITIVIREAD and ITIVIWRITE
operations, respectively. Supplied on each ITIVIREAD
or ITlVIWRITE request is the name of the file to be
processed, a format which is a definition of the fields
within the item, and a list of identifiers. The specific
relation between the format and the list of identifiers
in each particular request is the subject of Part B of
this section. The general sequence of commands for
manipUlating data files in Vulcan is as follows. Prior
to executing the Vulcan program, buffer storage requirements must be supplied with the FILE statement.
Each file to be processed must be assigned, either externally or dynamically, through the CSF instruction
(described later). The file must be opened before reading
or writing and then closed after processing. A file may
be reopened after it is closed, and it need not be reassigned unless it has been freed. The Vulcan file handling
capability employs the Input-Output Interface for
FORTRAN V under EXEC 8 described in the National
Resource Analysis Center's Guidebook, REG-104.
The user is advised to read this manual before using
the Vulcan file handling commands. The instructions
for file handling and their calling sequences follow.
1. OPEN: opens a file for processing.
CALL: OPEN(FN, l\10DE, TYPE, LRS, PRS,
LAF, LAB), where
FN = Filename (1-12 characters)
}VIODE = l\10de of operation (1 :::;l\10DE:::;7)
TYPE = Type of blocks (1 ~TYPE:::; 5)
LRS
= Logical record size, for fixed size
records.
(l:::;LRS:::;PRS).
If
LRS = '0' then variable SIze
records are indicated.
PRS
= Physical record size (1 :::;PRS:::;N,
where N is buffer size stated on
the FILE declaration).
LAF
= Look-ahead factor (is ignored
if LAF= (empty»
LAB
= Label (is ignored if LAB =
(empty».
Only the first five arguments are necessary for
opening a file. The label field (LAB), or the label (LAB)
and look-ahead factor (LAF) fields may be omitted
in the call. The OPEN request comes out true if the
operation is completed normally and comes out false
otherwise. I/O status information may be retrieved
with the STATUS instruction, described later in this
section. For example, the Vulcan instruction
OPEN('TEACH', '2', '2', '28', '28')
"\\-ill open an output file named 'TEACH' (with fixed
size blocks with no block counts and no sum checks)
of 28-word records each and 28-word items (i.e., one
item per physical record).
2. CLOSE: closes a file that has been opened.
CALL: CLOSE (FN, TYPE), where
FN
= File name (1-12 characters)
TYPE = Close type (1- 2!56 I-
a:::
o
~
64-
...J
~
161-
'1. SIO I IYSTE••
~
f3
a::
>-
I-
SB
11111.
.1
t
4.11.0
2
lid,
,.11
I
III
4 1'10
4 11100
z
..
Z
"1000
NORMALIZED SYSTEM PERFORMANCE
Figure 6-Main memory requirements as a function of
processor power
formance cannot be improved by a hierarchy. Clearly,
as the needed capacity approaches the buffer size, use
of two leve]s is uneconomical.
In extending the memory hierarchy structure to
multiple levels, the statistics of Figure 4 continue to
apply. They must be corrected for the block size used,
however. At each successive level the capacity must
increase as the access time increases. The number of
references not found in an intermediate level will be
approximately the same as if that level were itself the
inner level of memory in the system.
64K BYTE
CAPACITY
>-
>-
37
..J
Algorithms
m
-
LLJ
N
--'
«
::E
2. first leve1 buffer costs twice as high ($.50)
3. main memory access longer (50 cycles)
4. miss ratio improved (lowered) by a factor of
two for each capacity.
Some qualitative rules for optimizing memory
system cost/performance are apparent from these
analyses:
1. as buffer memory is relatively more expensive
less should be used;
2. as main memory is relatively slower more buffer should be used;
3. as algorithms yield a lower miss rate less buffer
should be used.
The converses also apply.
In order to assess the utility of a three-level hierarchy one must first evaluate the two-level alternatives.
To find the most favorable three-level configuration
we must consider a range of capacities for each buffer
level. Figure 12 shows how cost-performance values
for the three-level alternatives can be displayed as a
function of first-level buffer capacity for comparison
with the two-level situation.
Conditions that are favorable to the use of a threelevel configuration include:
1. expensive first level technology
2. steep cost/performance curve for main memory
technology
3. relatively high miss ratios
4. large total memory requirements
An optimum three-level configuration will use less
first-level and more second-level buffer memory than
the equivalent two-level case. The two-level con-
~O----~----~----~----~--~----~
8
16
32
64
128
256
Z
FIRST LEVEL BUFFER CAPACITY
(K BYTES)
Figure 12-Cost/performance analyses of three-level hierarchy
examples
figuration is more generally applicable, until a lower
cost bulk memory is available.
DISCUSSION
A properly designed memory hierarchy magnifies
the apparent performance/cost ratio of the memory
system. For example, the first case assumed in Figure
11 shows a cost/performance advantage of five times
that of a plausible single-level memory system with a
three-cycle access costing $.15 per bit. The combination achieves the capacity of the outer level at a performance only slightly less than that of the inner level.
Because of the substantial difference in the capacities,
the total cost is not greatly more than that of the outer
level alone.
The early memory hierarchy designs attempted to
integrate the speed/cost characteristics of electronic
and electromechanical storage. Now the large performance loss could be predicted from the relatively
enormous access time of the rotating device. For example, degradation of more than 100 times over operation from entirely within two-microsecond memory
would occur with addresses generated every two microseconds, 64K byte buffer (core) capacity, 512 word
block size, and 8ms average drum access time. To compensate for such disparity in access time, the inner
memory must contain nearly complete programs.
42
Fall Joint Computer Conference, 1970
160K
Figure 13-Distribution of program size
Successful time-sharing systems essentially do this.
Figure 13 shows the results of several studies13 ,14,15 of
the distribution of their program size.
These time-sharing systems also indicate direction
toward the use of multiple level internal memory. In
particular, they show the need for low-cost mediumaccess bulk memory. They are caught between inadequate response time achieved paging from drum or
disk and prohibitive cost in providing enough of present
large capacity core memories (LCM). However, designers such as Freemanll and MacDougall12 have
stated that only by investment in such LCM can systems as powerful as the 360/75 have page accessibility
adequate to balance system cost/performance. Freeman's design associates the LCM with a backing disk,
as a pseudo-disk system.
Transparent hierarchy can make it easier to connect
systems into multiprocessing configurations, with
only the outer level common. This minimizes interference at the common memory, and delays due to
cable length and switching. It has no direct effect on
associated software problems.
To date, hierarchy has been used only in the main
(program) memory system. The concept is also powerful in control memories used for microprogram storage.
There it provides the advantages of writeable control
memory, while allowing the microprograms to reside in
inexpensive read-only or non-volatile read-write memory.
A primary business reason for using hierarchy is to
permit continued use of ferrite memories in large systems. With a buffer to improve system performance,
ferrites can be used in a lowest cost design. It is unnecessary to develop ferrite or other magnetic memories at costly, high performance levels.
The uSe of multiple levels also removes the need to
develop memories with delicately balanced cost/performance goals. Rather, independent efforts can aim
toward fast buffer memories and inexpensive large
capacity memories. This permits effective use of resources and implies higher probability of success.
Systems research in the near future should concentrate upon better characterization of existing systems
and programs. There is still little published data that
describes systems in terms of their significant statistical
characteristics. This is particularly true with respect
to the patterns of information scanning that are now
buried under the channel operations required to exchange internal and external data. Only from analysis
and publication of program statistics and accompanying
machine performance data will we gain the insight
needed to improve system structure significantly.
REFERENCES
1 C J CONTI
Concepts for buffer storage
IEEE Computer Group News Vol 2 No 8 March 1969
2 C J CONTI D H GIBSON S H PITKOWSKY
Structural aspects of the system/360-Model 85, I.-General
organization
IBM Systems Journal 7 11968
3 J S LIPTAY
Structural aspects of the system 360 Model 85, II-The
cache
IBM Systems Journal 711968
4 T KILBURN
Electronic Digital Computing Machine
Patent 3,248,702
5 T KILBURN D B G EDWARDS M J LANIGAN
F H SUMMER
One-level storage system
IRE Transactions on Electronic Computers
Vol 11 No 2 1962 pp 223-235
6 D W ANDERSON F J SPARACIO
R M TOMASULO
The IBM System/360 Model 91: Machine philosophy and
instruction handling
IBM Journal Vol 11 No 81967
7 L BLOOM M COHEN S PORTER
Considerations in the design of a computer with a high
logic-to-memory speed ratio
Proc of Sessions on Gigacycle Computing Systems AlEE
Winter General Meeting January 1962
On Memory System Design
8 D H GIBSON
Considerations in block oriented systems design
AFIPS Proceedings Vol 30 SJCC 1967 pp 75-80
9 S S SISSON M J FLYNN
Addressing patterns and memory handling algorithms
AFIPS Proceedings Vol 33 FJCC 1968 pp 957-967
10 B S BRAWN F G GUSTAVSEN
Program behavior in a paging environment
AFIPS Proceedings Vol 33 FJCC 1968 pp 1019-1032
11 D N FREEMAN
A storage hierarchy system for batch processing
AFIPS Proceedings Vol 32 SJCC 1968 p 229
12 M H MACDOUGALL
Simulation of an ECS-based operating system
AFIPS Proceedings Vol 30 SJCC 1967 P 735
13 A L SCHERR
Time-sharing measurement
Datamation Vol 12 No 4 April 1966 pp 22-26
14 I F FREIBERGS
The dynamic behavior of programs
AFIPS Proceedings Vol 33 FJCC 1968 pp 1163-1167
15 G E BRYANT
JOSS-A statistical summary
AFIPS Proceedings Vol 31 FJCC 1967 pp 769-777
43
Design of a very large storage system*
by SAMUEL J. PENNY, ROBERT FINK, and IVIARGARET ALSTON-GARNJOST
University of California
Berkeley, California
files-and single experiments produced tape libraries of
hundreds of reels each.
The problems of handling large tape libraries had
become well known to the experimenters. Tapes were
lost; they developed bad spots; the wrong tapes· were
used; keeping track of what data were on what tape
became a major effort. All these problems degraded the
quality of the data and made the experiments more
expensive. A definite need existed for a new approach.
The study of the problem began with establishment
of a set of criteria for a large-capacity on-line storage
device, and members of the LRL staff started investigating commerically available equipment. The basic
criteria used were:
INTRODUCTION
The Mass Storage System (MSS) is a data-management
system for the on-line storage and retrieval of very large
amounts of permanent data. The MSS uses an IBM
1360 photo-digital storage system (called the chipstore)
with an on-line capacity of 3 X 1011 bits as its data
storage and retrieval equipment. It also uses a CDC 854
disk pack for the storage of control tables and indices.
Both these devices are attached to a CDC 6600 digital
computer at the Lawrence Radiation LaboratoryBerkeley.
Plans for the NISS began in 1963 with a search for an
alternative to magnetic tape as data storage for analyses
in the field of high energy physics. A contract was
signed with IBM in 1965 for the chipstore, and it was
delivered in March of 1968. The associated software on
the 6600 was designed, produced, and tested by LRL
personnel, and the Mass Storage System was made
available as a production facility in July of 1969.
This paper is concerned with the design effort that
was made in developing the }\1:ass Storage System. The
important design decisions, and some of the reasons
behind those decisions, are discussed. Brief descriptions
of the hardware and software illustrate the final result
of this effort.
a. The storage device should be on-line to the
central computing facility.
b. It should have an on-line capacity of at least
2.5XIOll bits (equivalent to 2000 reels of tape).
c. Access time to data in the storage device should
be no more than a few seconds.
d. The data-reading transfer rate should be at least
as fast as magnetic tape.
e. The device should have random-access
capability.
f. The storage medium of the device should be of
archival quality, lasting 5 years at least.
g. The storage medium need not be rewritable.
h. The frequency of unrecoverable read errors
should be much lower than on magnetic tape.
1. Data should be easily movable between the
on-line storage device and shelf storage.
j. The device hardware should be reliable and not
subject to excessive failures and down time.
k. Finally, the storage device should be economically worthwhile and within our budget.
CHOICE OF THE HARDWARE
By 1963 the analysis of nuclear particle interactions
had become a very large application on the digital
computers at LRL-Berkeley. More than half the
available time on the IBM 7094 computer was being
used for this analysis, and the effort was expanding.
Much of the problem was purely data manipulationsorting, merging, scanning, and indexing large tape
Several devices were proposed to the Laboratory by
various vendors. After careful study, including computer
simulation of the hardware and scientific evaluations of
* Work done under auspices of the U.S. Atomic Energy Commission.
45
46
Fall Joint Computer Conference, 1970
Developer
fluids entry
-'----- Control path
- - . Dota path
~ Pneumatic box path
Unexposed
film entry
Monual .ntry
and .xlt for
boxes
.IL7a7 -5312
Figure 1-General MSS architecture
the technologies, the decision was made to enter into a
contract with IBM for delivery, in fiscal year 1968, of
the 1360 photo-digital storage system. This contract was
signed in June of 1965. The major application contemplated at that time is described in Ref. 1.
It was clear that one of the major problems in the
design of the associated software would be the storage
and maintenance of control tables and indices to the
data. Unless indexing was handled automatically by the
software, the storage system would quickly become
more of a problem than it was worth. Protection of the
indices was seen to be equally important, for the
system would be dependent on them to physically locate
the data. It was decided that a magnetic disk pack
drive, with its removable pack,was the most suitable
device for the storage of the MSS tables and indices.
A CDC 854 disk pack drive was purchased for this
purpose.
developer unit completes the processing of a chip within
2.5 min; it overlaps the developing of eight chips so that
its processing rate is comparable to that of the recorder.
Up to 32 chips are stored together in a plastic box.
Figure 2 shows a recorded film chip and the box in
which it is kept. These boxes are transported between
the recorder-developer, the box storage file, and the chip
reader station by means of an air blower system.
Transport times between modules on the Berkeley
system average around 3 sec.
Under the command of the 6600 computer the
chipstore transports a box from the storage file to the
reader, picks out a chip, and positions it for reading.
The chip is read with a spot of light generated by a
cathode-ray tube and detected by a photomultiplier
tube at an effective data rate of 2 million bits per
second. The error correction-detection codes are checked
for validity as the data are read, and if the data are
incorrect, an extensive reread and error-correction
scheme is used to try to reproduce the correct data. The
data are then sent to the 6600 across a high-speed data
channel. Chip pick and store times are less than 0.5 sec.
The box storage file on the Berkeley 1360 system has
a capacity of 2250 boxes. This represents an on-line data
capacity of 2750 full reels of magnetic tape (at 800
BPI); 1360 systems at other sites have additional file
modules, giving them an on-line capacity three or more
times as great as at Berkeley.
A manual entry station on the chipstore allows boxes
of chips to be taken out of the system or to be reinserted.
By keeping the currently unused data in off-line storage
and retaining only the active data in the file, the
potential size of the data base that can be built in the
MSS is equivalent to tens of thousands of magnetic
tapes.
DESCRIPTION OF THE HARDWARE
1360 Photo-digital storage system
The IBM 1360 chipstore is an input-output device
composed of a storage file containing 2250 boxes of"
silver halide film chips, a chip recorder-developer, and a
chip reader. Figure 1 shows the general arrangement of
the chipstore hardware and its relation to the CDC 6600
computer. References 2 through 5 describe the hardware
in detail. A brief summary is given below.
A chip is 35 by 70 mm in size and holds 4.7 million bits
of data as well as addressing and error-correction or
error-detection codes. Data from the 6600 computer are
recorded on the chip in a vacuum with an electron beam,
taking about 18 sec per chip. The automatic film
Figure 2-Recorded film chips and storage box
Design of Very Large Storage System
A process control computer is built into the chipstore
hardware. This small computer is responsible for
controlling all hardware actions as well as diagnosing
malfunctions. It also does the detailed scheduling of
events on the device. Communication between the
chipstore and the host computer goes through this
processor. This relieves the host of the responsibility of
commanding the hardware in detail, and offers a great
deal of flexibility.
854 Disk pack drive
The CDC 854 disk pack drive holds a removable
10-surface disk pack. The pack has a typical access time
of 90 msec, and a data transfer rate of about 1 million
bits per sec. Its storage capacity is 48 million bits.
MSS uses this pack for the storage of all its tables and
indices to the data that have been written into the 1360
chipstore. A disk pack was chosen for this function to
insure the integrity of the MSS tables. The 854 has a
proven record of hardware and data reliability. Also,
since the pack is removable, the drive can be repaired
and serviced without threat to the tables.
6600 Computer complex
The chipstore is connected to one of the CDC 6600
computers at LRL through a high-speed data channel.
The 6600 computer has 131072 words of 60-bit central
core memory (CM) , a central processor unit (CPU)
operating at a 100-nsec cycle rate, and 10 peripheral
processor units (PPU). Each PPU contains 4096 words
of 12-bit core memory and operates at a 1-}Lsec cycle
rate. The PPUs control the data channel connections to
the external input-output equipment and act as the
interface between jobs residing in C1\1 and the external
world.
The operating system on the 6600 is multiprogrammed
to allow several jobs to reside in CM at once and share
the use of the CPU. Two of the PPUs act as the system
monitor and operator interface for the system, and those
remaining are available to process task requests from
the monitor and execute jobs. The MSS, composed of
both CPU and PPU programs, has been built as a
subsystem to this operating system.
CHOICE OF THE MASS STORAGE SYSTEM
SOFTWARE
Design objectives
Having made the commitment on hardware, the
Laboratory was faced with designing and implementing
47
the associated software. The basic problem was to
produce a software system on the CDC 6600 computer
that, using the IBM 1360 chipstore, ,would lead to the
greatest increase in the productive capacity of scientists
at the Laboratory. In addition, it was necessary that the
system be one that the scientists would accept and use,
and to which they would be willing to entrust their data.
I t would be required to be of modular design and
"open-ended," allowing expansion and adjustment to
new techniques that the scientists might develop for
their data analysis.
Overall study of the problem yielded three primary
objectives. 1\1ost important was to increase the reliability of the data storage, both by reducing the number
of data-read errors and by protecting the data from
being lost or destroyed; much time and effort could be
saved if this objective were met. The second objective
was to increase the utilization of the whole computer
complex. The third was to provide facilities for new,
more efficient approaches to data analysis in the future.
The problem was divided into three technical design
areas: the interaction between the software and the
hardware, the interaction between the user and the
software, and the structure of the stored data.
In the area of software-hardware interaction, the
design objectives were to maximize protection of the
user data, interleave the actions for several jobs on the
hardware, reduce the need for operator intervention, and
realize maximum utilization of the hardware. This was
the approximate order of importance.
Objectives in the area of user interaction with the
MSS included making that interaction easy for the user,
offering him a flexible data-read capability, and supplying him with a protected environment for his data. Ease
of data manipulation was of high value, but not at the
expense of data protection. A flexible read mechanism
was necessary, since if the users could not read their data
from the 1\1SS, they would seek other devices. This
flexibility was to include reading data from the chips tore
at rates up to its hardware limit, having random access
to the data under user control, possibly intermixing data
from the chipstore, magnetic tapes, and system disk
files, and being able to read volumes of data ranging in
size from a single word to the equivalent of many reels
of tape.
The problem of data structures for the MSS was
primarily one of finding a framework into which existing
data could be formatted and which met the requirements of system and user interaction. This included the
ability to handle variable-length data records and files
and to access these data in a random fashion. It was
decided that a provision to let the user reference his data
by name and to let the system dynamically allocate
storage space was very important. It was also important
48
Fall Joint Computer Conference, 1970
to have flexible on-line-off-line data-transfer facility so
that inactive data could be moved out of the way.
Software design decisions
Several important design decisions were made that
have had a strong effect on the nature of the final
system. Some of these decisions are listed here.
Each box used for data storage is given a unique
identification number, and this number appears on a
label attached to the box. A film chip containing data is
given a unique home address, consisting of the identification number of the box in which it is to reside and the
slot in that box where it is to be kept. Control words
written at the beginning of the chip and at various places
throughout the data contain this address (along with
the location of the control word on the chip), and this
information can be checked by the system to guarantee
correct positioning for retrieval of the data. It is also
used to aid in recovery procedures for identifying boxes
and chips. This control information can be used to help
reconstruct the MSS tables if they are destroyed.
The control words are written in context with the data
to define the record and file structure of the data on the
chips. The user is allowed· to give the address of any
control word (such as the one at the beginning of a
record) to specify what data are to be read. This scheme
meets the design objective of allowing random access to
data in the chipstore.
Data to be written into the chipstore are effectively
staged. The user must have prepared the data he wishes
to be recorded in the record and file structure he desires
in some prior operation. He then initiates the execution
of a system function that puts the source data into chip
format, causes its recording on film chips, waits for the
chips to be developed, does a read check of the data, and
then updates the J\1SS tables.
Data read from the chipstore are normally sent
directly to the user's program, though system utility
functions are provided for copying data from the
chipstore to tape or disk. If the user desires, he may
include a system read subroutine with his object
program that will take data directly from the chipstore
and supply them to his executing program. This method
was chosen to meet the objectives of high data-transfer
rates and to provide the ability to read gigantic files
of data.
To aid the user in the access and management of his
data in the J\1SS, it was decided to create a datamanagement control language oriented to applications
on the chipstore. A user can label his data with names
of his own choosing and reference the data by those
names. A two-level hierarchy of identification is used,
that of data set and subset. The data set is a collection
of named subsets, in which each subset is some structure
of user data. The control language is not limited to
manipulating only data from the chipstore; it can also
be used to work with magnetic tape or system disk files.
Two more decisions have greatly simplified the
overall problem of data management in the MSS. The
first was to allocate most of the on-line storage space on
the chipstore in blocks to the scientists engaged in data
analysis· of current experiments, and give them the
responsibility of choosing which of their data are to
reside on-line within their block and which are to be
moved off-line. The second decision was to treat all as
permanent. Once successfully written, film chips are
never physically destroyed. At most, the user may
delete his reference to the data, and the chips are
moved off-line.
DESCRIPTION OF THE J\1SS SOFTWARE
The system in use on the 6600 computer for utilizing
the chips tore results both from design effort at the
beginning of the project and from experience gained
during the implementation and initial production
phases. Its essential features are listed below.
Indexing and control of the data stored in the
chipstore are handled through five tables kept on the
disk pack, as follows.
The box group allocation table controls the allocation
of on-line storage space to the various scientists or
experiments at the Laboratory. Any attempt by a user
to expand the amount of on-line space in use by his box
group above its allowable limit will cause his job to be
aborted.
The box identification table contains an entry for each
uniquely numbered box containing user data chips. An
entry tells which box group owns the box, where that
box is stored (on-line or off-line), which chip slots are
used in the box, and the date of its last use.
The file position table describes the current contents
of the 1360 file module, defines the use of each pocket in
the file, and gives the identification number of the box
stored in it.
The data set table contains an entry for each of the
named collections of data stored in the chipstore. Status
and accounting information is kept with each data-set
table entry. Each active entry also points to the list of
subsets collected under that data set.
The subset list table contains the lists of named subsets
belonging to the entries in the data set table. A subset
entry in a list gives the name of the subset, the address
of the data making up that subset, and status information about the subset.
Design of Very Large Storage System
These tables are accessed through a special PPU task
processor program called DPR. This processor reads or
writes the entries in the tables as directed. However,
if the tables are to be written, special checks and
procedures are used to aid in their protection. Twice
daily the entire contents of the MSS disk pack are
copied onto magnetic tape. This is backup in case the
data on the pack are lost.
All communication to the chipstore across the data
channel link is handled through another PPU task
processor program called 1CS; 1CS is multiprogrammed
so that it can be servicing more than one job at a time.
Part of its responsibility is to schedule the requests of
the various user jobs to make most effective use of the
system. For instance, jobs requiring a small amount
of data are allowed to interrupt long read jobs. Algorithms· for overlapping box moving, chip reading, and
chip writing are also used to make more effective use
of the hardware.
1CS and DPR act as task processors for jobs residing
in the central memory of the 6600. The jobs use the
MSSREAD subroutine (to read from the chips tore) or
the COPYMSS system utility to interface to these task
processors. These central memory codes are described
below.
The reading of data from the chipstore to a job in
central memory is handled by a system subroutine
called MSSREAD. The addresses of the data to be read
and how the data are to be transmitted are given to
MSSREAD in a data-definition file. This file is prepared
prior to the use of MSSREAD by the COPYMSS
program described later; MSSREAD handles the
reading of data from magnetic tape, from disk files, or
from the chipstore. If the data address is the name of a
tape or disk file, MSSREAD requests a PPU to perf.orm
. the input of the data from the device a record at a tIme.
If the address is for data recorded in the chipstore, it
connects to 1CS, and working with that PPU code, takes
data from the chipstore, decodes the in-context structure and supplies the data to the calling program.
A'system program called COPY1\,fSS is responsible
for supplying the user with four of the more common
functions in MSS. It processes the MSS data-manage-
TABLE I-Distribution of MSS Implementation Effort.
Operation
Procurement and Evaluation
System design
Software coding
Software checkout
Maintenance, documentation, etc.
Man-years
1.0
2.8
1.7
0.8
1.2
49
TABLE II-MSS Usage Per Week.
Number of read jobs
Number of write jobs
Chips read
Bits read
Unrecoverable read errors
Chips written
Percentage down time
250
100
11500
5.4X1010
15
1900
8.5
ment control language to construct the data-definition
file for MSSREAD. It performs simple operations of
copying data from the chipstore to tape or disk files. It
prepares reports for a user, listing the status of his data
sets and subsets. Finally, COPY1\,fSS is the program
that writes the data onto film chips in the chipstore.
To write data to the chipstore, the user must prepare
his data in the record and file structure he desires. He
then uses the MSS control language to tell COPYMSS
what the data set and subset names of the data are to be
and where the data can be found. COPY1\1SS inserts the
required control words as the data are sent through 1CS
to the chips tore to be recorded on film chips. After the
chips have been developed, 1CS rereads the data to
verify that each chip is good. If a chip is not recorded
properly, it is discarded and the same data are written
onto a new chip. When all data have been successfully
recorded and the chips are stored in the home positions,
COPYMSS uses DPR to update the disk pack tables,
noting the existence of the new data set-subset.
The remaining parts of the 1\1SS software include
accounting procedures, recovery programs, and programs to control the transfer of data between on-line
and off-line storage. These programs, used by the
computer operations group, are not available to the
general user.
RESULTS AND CONCLUSIONS
Effort
A total of about 7.5 man-years of work was invested
in the Mass Storage System at LRL-Berkeley. The
staff on the project was composed of the authors with
some help from other programmers in the 1\,fathemati~s
and Computing Department. The breakdown of thIS
effort is shown in Table I.
Operating experience
The Mass Storage System has been in production
status since June 1969. Initial reaction of most of the
50
Fall Joint Computer Conference, 1970
TABLE III-Comparison of Storage Devices at LRL-Berkeley
On-line capacity (bits/device)
Equivalent reels of tape
Cost of removable unit
Storage medium cost (¢/10 3 bits)
Average random access (sec)
Maximum transfer rate (kilobits/sec)
Effective transfer rate&
Approximate capital costs (thousands
of dollars)
Mean error-free burst length (bits)
MSS
CDC 607
tape drive
CDC 854
disk pack
IBM 2311
data cell
CDC 6603
system disk
3 .3X 1011
2750
$13jbox
0.008
3
2000
1100
1000
1.2XI08
1
$20/reel
0.017
(minutes)
720
500
100
4.8X107
0.4
$500/pack
1.0
0.075
1330
4.5X10 8
3.75
35
3.0X109
25
$500/cell
0.17
0.6
450
200
220
1.6XI09
2.5XI07
>1010
109
>1010
0.125
3750
400
220
&Based on usage at LRL-Berkeley; the rates given include device-positioning time.
users was guarded, and many potential users were slow
in converting to its use. As a result, usage was only about
2 hours a day for the first 3 months. Soon after, this level
started to increase, and at the end of one year of
production usage a typical week (in the month of June
1970) showed the usage given in Table II.
IVlost of the reading from the chips tore is of a serial
nature, though the use of the random-access capability
is increasing. Proportionally more random access
activity is expected in the future as users become more
aware of its possibilities.
A comparison of the 1\188 with other data-storage
systems at the Laboratory, shown in Table III, points
out the reasons for the increased usage. For large
volumes of data, the closest competitor is magnetic tape
(assumed here to be full 2400-foot reels, seven-track,
recorded at 800 BPI).
The values shown in Table III are based on the
following assumptions: on-line capacities are based on
having a single unit (e.g., a single tape drive); capital
costs are not included in the storage medium costs;
effective transfer rates are based on usage at LRL, and
are very low for the system disk because all jobs are
competing for its use; and all costs given are only
approximate.
The average data-transfer rate on long read jobs
(involving many chips and many boxes) is more than
one million bits per second. This is decidedly better than
magnetic tape. Short reads go much faster than from
tape once the 3-sec access time is complete.
The biggest selling point for the Mass8torage
System has been the extremely low data-error rate on
reads. This rate is less than 1/60 of the error rate on
magnetic tape. The second most important point has
been the potential size of the data files stored in the
chipstore. Several data bases of from 20 to 200 boxes
of data have been constructed. Users find that having
all their data on-line to the computer and not having to
rely on the operators to hang tapes is a great advantage.
Their jobs run faster and there is less chance that they
will not run correctly.
The cost of storing data on the chipstore has proven
to be competitive with magnetic tape, especially for
short files or for files that will be read a number of times.
Users are. beginning to find it profitable to store their
high-use temporary files on the chipstore.
The system has not been without its difficulties.
Hardware reliability has at times been an agonizing
problem, but as usage increases and the engineers gain
more experience on the hardware, the down time for the
system has decreased significantly. We now feel that
5 percent down time would be acceptable, though less
would be preferable. Fortunately, lack of hardware
reliability has not affected the data reliability.
CONCLUSIONS
Though intended primarily as a replacement for
magnetic tape in certain applications, the MSS has
shown other benefits and capabilities. Data reliability is
many times better than for magnetic tape. Some
applications requiring error-free storage of large
amounts of data simply are not practical with magnetic
tape, but they become practical on the chipstore. The
nominal read rate is faster than that of magnetic tape
for long serial files. In addition, any portion of a file is
randomly accessible in a time ranging from a few
milliseconds to 5 seconds.
The MSS is not without its limitations and problems.
The 1360 is a limited-production device: only five have
been built. It uses technologies within the state of the
art but not thoroughly tested by long experience.
Design of Very Large Storage System
Keeping the system down time below reasonable limits
is a continuing and exacting effort. Development of both
hardware and software has been expensive. The software
was a problem because the chips tore was a new device
and people had no experience with such large storage
systems.
The Mass Storage System has met its purpose of
increasing the productive capacity of scientists at the
Laboratory. It has also brought with it a new set of
problems, as well as a new set of possibilities. The
biggest problem is how to live with a system of such
large capacity, for as more and more data are entrusted
to the chipstore, the potential loss in case of total failure
increases rapidly. The MSS offers its users important
facilities not previously available to them. More
important, the age of the very large Mass Store has
been entered. In the future, the MSS will become an
important tool in the computing industry.
51
REFERENCES
1 M H ALSTON S J PENNY
The use of a large photodigital mass store for bubble chamber
analysis
IEEE Trans Nucl Sci Volume NS-12 4 pp 160-163 1965
2 J D KUEHLER H R KERBY
A photo-digital mass storage system
AFIPS Conference Proceedings of the Fall Joint Computer
Conference Volume 29 pp 735-742 1966
3 L B OLDHAM R T CHIEN D T TANG
Error detection and correction in a photo-digital storage
system
IBM J Res Develop Volume 126 pp 422-4301968
4 D P GUSTLIN D D PRENTICE
Dynamic recovery techniques guarantee system reliability
AFIPS Conference Proceedings of the Fall Joint Computer
Conference Part II Volume 33 pp 1389-1397 1968
5 R M FURMAN
IBM 1360 photo-digital storage system
IBM Technical Report TR 02.427 May 15 1968
Design of a megabit semiconductor
memory system
by D. LUND, C. A. ALLEN, S. R. ANDERSEN and G. K. TU
Cogar Corporation
Wappingers Falls, N ew York
INTRODUCTION
insertion and extraction of cards a mechanical assembly
is also included. The card connectors are mounted on a
printed circuit interconnection board. All necessary
system wiring is done on the outside surfaces of this
This paper describes a 32,768 word by 36 bit word
Read/Write Memory System with an access time of
250ns, and a cycle time of 400ns.
The memory system is based on IV[OS technology for
the storage array and bipolar technology for the
interface electronics. A functionally designed storage
array chip with internal decoding minimizes the number
of external connections, thereby maximizing overall
system reliability. The average power dissipation of the
overall system is maintained at about OAmw per bit
including all support circuitry dissipation. This is based
on a card configuration of 102 modules with a maximum
module dissipation of 600mw.
System status
At present test sites containing individual storage
array chip circuits and single bit cross sections have
been processed and are being evaluated. Although
initial test results are favorable sufficient data has not
been accumulated to verify all design criteria. Sourcedrain storage array chip production masks are in line
with other levels nearing completion. Layouts of the·
bipolar support chips are complete and ready for
generation of production masks.
1~
Lw~~
System description
CONNECTIONS
An isometric view of the complete 32,384 word by 36
bit memory system is shown in Figure 1. The total
volume occupied by the system is 0.6 cu. ft., resulting in
a packing density of approximately 2 million bits/cu. ft.
A mechanical housing is provided for the eight multilayer printed circuit cards that contain the memory
storage elements and peripheral circuits. To facilitate
'.... 'J,......
! /'.AIRt t
FLOW
I
I
MEMORY SYSTEM ASSEMBLY
(8 CA RD )
Figure 1-Memory system assembly
53
54
Fall Joint Computer Conference, 1970
board with voltage distribution accomplished by the
internal planes. Additional edge connectors are mounted
in this board to accommodate I/O signal cabling via
plug-in paddle cards. Power connections are provided
at the outermost edge of the board.
Since the purpose of this design was to provide a
large, fast, low-cost system for use as a computer main
frame memory the following design constraints were
observed:
8.80 IN.
,-
A one megabit capacity was chosen to be representative of the size of memory that is applicable to a fairly
large, high-speed processor. It was decided that the
system should be built from modular elements so that
memory size and organization could be easily varied.
An additional advantage of ease of servicing and
stocking accrued from this approach.
Speed
A balance between manufacturability and system
requirements was established in setting the performance
objectives. This tradeoff resulted in a goal of 250ns.
access time and 400ns cycle time.
Density
The density of memory cells should be maximized in
order to create minimum cost per cell. An objective of
1024 bits of information was chosen as a reasonable goal
using present LSI technology on a .125 in. X .125 in.
chip. In order to keep the I/O signal count within
reasonable bounds it was decided that address complementing and decoding should be included within the
chip. The chip was structured 1024 words by one bit.
Memory card
A drawing of the basic modular unit, the memory
card, is shown in Figure 2. The card is a multilayer
printed circuit unit with two external planes for signal
wiring and two internal planes for distribution of the
three required voltages and ground. Ninety-eight
double sided connecting tabs are situated along one
edge of the card on a .150 in. pitch. These tabs provide
for a mating connection with the edge co.nnectors
mounted on the interconnection board, and serve to
electrically connect all supply voltages and signal wiring
~I II-
-,
.96CM
~=~o~~~~~~~~;-
'~ """"c TYP
A A A A A A A A A P P
A A A A A A A A A P P
(39)
A A A A A A A A A P P
A A A A A A A A A P P
Ill£D
W
L
MEMORY
CARD
§
A A A A A A A A A P P B
~
A A A A A A A A A P P B
A A A A A A A A A P P CL ___ .-R (~rp
....
~
Capacity
22.35 CM
l
g\
f'i ...- _ D~LAY
A A A A A A A A A P P
B B L.t
S/L S/L S/L S/L S/L S/L S/L S/L S/L
t:~OIIIIIIlmmIIlIlIImlDl_IIIIIIHIIIIIIII.~
CONNE~TOR3
~
-11-.100 TYP
-l.
L ___________ J
TYP
(3)
..I:~ ~~
:=P
,BOARD
- -
::b
' • ,
=-r;;!;L
fi
Figure 2-Memory card
to the card. The modules mounted on the card contain
one or two chips each, solder reflow bonded to a wiring
pattern on a ceramic substrate. Each module occupies a
0.7 in. square area. The 72 modules marked "A" cont~in
the storage array with two chips of 1024 bits each
included in each module. The "B" modules provide the
primary stages of bipolar buffering while the "P"
modules contain the secondary bipolar buffering and
decoding. :l\{odules "CL" and "DEL" provide for timing
generation while the remaining "S/L" modules perform
the sense amplification and latching functions.
Logic design
Memory system logic design was based on the
modular card concept to provide easy upward and
downward variation of total memory capacity. This
card contains all necessary input buffering circuitry,
timing circuits, storage elements, sensing circuits, and
output registers. The card is structured so that smaller
organizations can be obtained by depopulating modules.
TTL compatible open collector outputs are provided to
allow "wired-or" expansion in multiple card systems
such as the 32K word by 36 bit system discussed here.
Unit TTL compatible input loads help alleviate the
problems of driving a multiple card system.
Card logic flow
A signal flow logic diagram for the 8192 word by 18
bit memory card is shown in Figure 3. Thirteen single
rail address lines are required to uniquely determine one
Design of Mega-Bit Semiconductor Memory System
55
- READ/+WRITE o--.!...i-----+-I
B
+A
+A
ADDRESS
INPUTS
+A
+A
+A
+A
+A
+A
(8)
(8)
(8)
(8)
(8)
(8)
(8)
(8)
B
B
B
B
B
B
B
B
(9)
WORD
DECODE
AND
DRIVE
(9)
(9)
ARRAY
32 X 32
(9)
(9)
(9)
(9)
(9)
z
~>0 { .
cU&...,
a:Ci!
§~..J
GND
I&.
Z
0
RESET
(,)
SET
CONFIGURATION {UPPER 112 - EVEN IITS
CONTROL
LOWER 112 - ODD BITI
2,4,_ ETC.
l,lI,5 ETC.
COST PERFORMANCE MEMORY CARD LOGIC
( 8192 WORDS BY 18 BITS )
( WITH MI AND M2 INPUTS GROUNDED AS SHOWN)
Figure 3-Cost performance memory card logic
of 8192 words. Four control lines are required as
follows:
Select-causes selection of entire card.
Read/Write-determine the mode of operation to
be performed.
Set-provides timing for the output data register.
Clock-generates timing for read and write operations as well as timing for cyclic data refreshing.
Thirty-six more lines are used for data-in and
data-out.
array chips. Ten address lines (0-9) drive all storage
array chips on the card in parallel, decoding to one of
the 1024 bits stored on each chip. The remaining address
lines (10-12) are decoded and combined with the timed
Select pulse to create two Row Select signals which
energize two of the sixteen rows of array chips on the
card (two rows of chips per row of modules). Srnce there
are nine array chips in each row, a total of eighteen bits
are read out in each operation. The eighteen bits are
transmitted to eighteen combination differential sense
amplifier and latch circuits which are, in turn, wired to
the card connector interface.
Read operation signal flow
All input lines are buffered immediately upon entering
the memory card. A second stage of address buffering is
included on the card to allow fan out to all 144 storage
Write operation signal flow
Cell selection is performed in the same fashion during
a write cycle as in a read cycle. However, instead of
56
Fall Joint Computer Conference, 1970
sensing the differential pairs associated with each bit
position as in a read operation, the lines are pulsed by
one of a pair of bit driver circuits. The magnitude of this
excursion is sufficient to force the selected cell to the
desired state as indicated by the condition of the
data-in line.
Storage array chip logic organization
The storage array chip is organized in a 32 by 32
matrix of storage cells. Five input address lines are
complemented upon entering the chip and then
selectively wired to the word decoder drivers to provide
a one-of-32 selection. These word drivers are also gated
by Row Select so that only storage cells on a selected
chip are energized. The remaining one-of-32 decoding
function is performed on the cell outputs using the
remaining five input address lines. The 32 outputs of
this final gating stage are wire-ored together to the
single differential pair of output bit lines.
Tillling structure
Because the array chip is operated in a dynamic
fashion, it is necessary to provide several timed lines
for periodic refreshing of data and for restoration of the
array chip selection circuits after a read or write
operation. To minimize the number of lines required at
the system interface, the timing generation circuits and
delay lines are included on each memory card. These
functions are implemented with nonsaturating current
switch circuits for minimum skew between timed pulses.
Tapped delay lines are used to chop and delay the input
clock pulse. A total of four timing pulses are generated
as described below:
(nl)
160
I
I
ADDRESS
.J
ENABLE
--.J
400
I
_ 1 _ _ _ _ _ _ _'
_____---....r
REFRESH
SELECT
SELECT I
REFRESH
RESTORE
Figure 4-Storage array chip input timing
the selection circuit node capacitances that were
discharged during the immediately preceding operation,
and for the node capacitances of the storage cells
themselves.
A diagram showing the relative timings of array chip
input lines is shown in Figure 4.
A timing chart for the memory system interface is
shown in Figure 5. It can be seen that two timed lines
are required at this interface. The first is the Clock line
from which all the aforementioned timings are derived.
The second is the Set line which latches array data into
the output register.
Systelll operation
A block diagram for the complete 32K word by 36 bit
memory system is shown in Figure 6. Eight memory
.
T
Row Select: This line is used to turn on the array
chip word and bit selection circuits during a read or
write operation.
Refresh: This line is timed to follow the Row Select
line and energizes all word selection circuits to refresh
the array data.
Enable: The address inverters on the array chip are
enabled by this line during a normal read or write
operation. During the refresh portion of the cycle the
absence of this pulse disables the address inverters so
that all word selection circuits are simultaneously
energized. This permits refreshing of data in all storage
cells.
Restore: This line gates on load devices in all array
chip selection circuits· during the refresh portion of the
cycle. These devices provide a recharging path for all
TIME
o
CLOCK
-
100
200
300
.
~OO
T
600
w
700
SELECT
Z
~
fUUUUL'
ADDRESS
MOOIFY
~
if/////M
v////u//.
READ I
WRITE
~~
SET
.
w
WRITE
READ
Ii:a..- ~
DATA OUT
V//A!
ACCESS TIME •
2~0
nl
DATA IN
1.----...
1. . - -
READ - - - -....
WRITE
----t.1
TIMING DIAGRAM FOR COST PERFORMANCE
READ-WRITE MEMORY SySTEMS
Figure 5-,-Timing diagram for cost performance read-write
memory systems
Design of Mega-Bit Semiconductor Memory System
SET
~
SELECT 0
~
DATA IN
(I - 18)
READ I WRITE
-~
SELECT 2
SELECT
~
~
~
8192 WORD
BY
18 BIT
MEMORY CARD
~
8192 WORD
BY
18 BIT
MEMORY CARD
~
8192 WOR!).
BY
18 BIT
MEMORY CARD
V
~~
DATA OUT
(I - 18)
'/
8192 WORD
~~
~ ~
DATA IN
(19 - 36)
r\
r\
CLOCK
SELECT 3
~
V
I
ADDRESS
(13 LINES)
8192 WORD
BY
18 BIT
MEMORY CARD
~
1\
-
~~
1-1-
l\~
~
1\
~~
tLz:
'''~'T
MEMORY CARD
t!>:l
8192 WORD
BY
18 BIT
MEMORY CARD
~
8192 WORD
BY
18 BIT
MEMORY CARD
~
8192 WORD
BY
18 BIT
MEMORY CARD
~~
DATA OUT
(19 - 36)
""
Figure 6-Memory system block diagram
cards, each containing 8192 words by eighteen bits are
interconnected as shown to form the total system. All
cards are addressed in parallel with four mutually
exclusive Select lines energizing one pair of memory
cards each cycle. Each card output is "wire-ored" with
three other card outputs to expand word depth from
8192 words to 32,768 words.
lV[aximum access time is 250ns as measured from the
+ 1.6 volt level of the input Clock leading edge transition. IVIinimum allowable cycle time is 400ns. and is
measured in a similar manner from one leading edge
Clock transition to the next. Since the Clock line
provides refreshing of data, it is also necessary that a
maximum Clock repetition time of 1.2~s be maintained
to avoid loss of information.
Circuit design
In the design of LSI memories the most important
costs to be minimized are as follows:
Unmounted chip cost per bit
Chip carrier cost per bit
Printed circuit card cost per bit
Support costs per bit
57
The chip cost per bit is largely a function of the area
of processed silicon required per bit of storage, the
process complexity as measured by the number of
masking or diffusion steps, and the chip yield. All of
these factors strongly favor a MOS-FET chip process
over bipolar process. For a given chip size the chip
carrier costs, the printed circuit cost and the support
costs are all inversely proportional to the number of bits
per chip, thus the advantage of high~density MOS-FET
array circuitry is overwhelming.
The chief drawback to MOS-FET circuits for semiconductor memories is their low gain-bandwidth
compared with bipolar circuits using equivalent geometric tolerances. This shortcoming can be minimized
by using bipolar circuits to provide the high-current
drives to the MOS-FET array circuits, and by using
bipolar amplifier circuits to detect the low MOS-FET
sense currents. If the circuits are partitioned so that all
the devices on a given chip are either bipolar or MOSFET, no additional processing complexity is added by
mixing the two device types within the same system.
The use of bipolar support circuits also allows easy
interfacing with standard bipolar logic signals, thus
the interface circuits can match exactly standard
interface driving and loading conditions.
Given an MOS-FET array chip, the two most
important remaining choices involve the polarity of the
MOS-FET device (n-channel or p-channel) and the gate
oxide thickness. It is well known that the transconductance of n-channel devices is approximately three
times that of equivalent p-channel device and thus the
current available to charge and discharge capacitance is
SUbstantially greater. Since the substrate is backbiased
by several volts in an n-channel device, the source-tosubstrate and drain-to-substrate capacitances are also
slightly lower, with the net result that n-channel
circuits are a factor of two to three faster than equivalent p-channel circuits. This speed difference is critically
important if address decoding and bit/sense line gating
are to be included on the MOS-FET chip. Because the
transconductance of a MOS-FET device, and consequently its ability to rapidly charge and discharge a
capacitance, is inversely proportional to the gate oxide
thickne~s, it is advisable to use the minimum thickness
that the state of- the art will allow; in this case 500
Angstroms was chosen as the minimum that would give
a good yield of pinhole free oxide with adequate
breakdown voltage. Other key device parameters are
tabulated below:
V t = 1.25V nominal with substrate bias
psub = 20cm P type
'Ym
pd
= 33.5~a/v nominal
= 70/square N type
58
Fall Joint Computer Conference, 1970
r - --- - WOiti::"TWOito
------------ARRAV:::---l
I
I NYERTER DECODER
RESTORE
IIV
52 UNITSJI
I R ~1t.NIA8LE II UNITS 52 UNITS:
J--
j
I __
1 - - - " -- ~R-i cs I"
~~~ty
II
IOZ4
SAR~l
~
'
I
~
~
IOV
~
I
__
L--+---+--+-':::"'--"'::::::~~~ FO'5"i-
~
FO'18
I fuaE I
I
I
~----..,-~-----,
INVERTER
II UNITS
10V
I
:
UNITS~
I
DECOD£R
52 UNITS
I
I
1
1:~I_$j
. . '. . i." -- --------~
I
1
I
L
~
-i
-_~
I
-i
~
~C"
1•
I
UN I TI
I
~~." ORO" I
8/S PAIRSJ
______ L _____________ _
cross-section circuit schematic of the array chip.
Included below are nominal chip parameters:
Address input capacitance ... (including gate protective device) 4pf
Enable input capacitance. . . (depending on address) 2.75 pf or 20pf
Restore input capacitance ... (including gate protective device) 57pf
Sense line input capacitance ... 5.5pf
Select input capacitance ... 8pf
Word line capacitance ... 7.5 pf
Bit line capacitance ... 2pf
Sense current ... 150JLa
l\1aximum gate protective device input 3400V
Figure7-Array chip cross-section
Storage cell
Chip partitioning
Since it was desired that the same chip set be used to
configure memory systems of different sizes, different
word lengths, and different system speeds, many of the
chip partitioning choices are obvious. The timing
circuits, which are used only once per system, are
contained on a separate chip. The sensing and bit/drive
circuits are combined on one chip to allow easy expandability in the bit dimension. The array drivers are
contained on a third chip type to allow easy expansion
in the memory size, while general buffering and gating
logic make up the fourth chip type. The most important
chip-partitioning choice involves the dividing line
between bipolar and MOS-FET circuits at the array
chip interface. By including the array word-line
decoding and the array bit/sense line gating on the
array chip, the number of connections to the array chip
can be greatly reduced, allowing the chip carrier wiring
to be less dense and the chip pad size and spacing to be
relaxed. The complexity of the bipolar support circuitry
was reduced still further by including the address
inverters on the array chip, with a small penalty in
delay. Ifa MOS-FET sense amplifier/bit driver were
included on the array chip, however, the increase in
delay would be excessive, owing to the poor response
time of MOS-FET high-gain amplifiers. In the design
shown here, the cell sense current is gated to a bipolar
sense amplifier for amplification and discrimination, and
the cell nodes are driven through the same l\10S-FET
gating circuits to the desired state during the write
operation. This arrangement requires that approximately 35 percent of the available array chip area be
used for decoding and gating circuits, with the remaining
65 percent used for storage cells. Figure 7 shows a
Typical MOS-FET storage cells are shown in
Figure 8. In ceIl8(a), Tl and T2 form the cross-coupled
pair, while T 3 and T 4 gate the external circuitry to the
cell nodes, either to sense the state of the cell by
detecting the imbalance in the current through T 3 and
+v
BI T I SENSE
BIT I SENSE
~---------+-.
WORD DR I VE
(0 )
+v
BIT I SENSE
BIT I SENSE
~---------+--. WORD DRIVE
(c)
Figure 8-Storage cell configurations
Design of Mega-Bit Semiconductor Memory System
THIN OXIDE
L
I...
I
W----e-I
l _ _ _ _ _ _ _ _ _ _ _ -'
Figure 9-W /L ratio
T 4 or to write into the cell by pulling one node to ground
while simultaneously driving the other cell node positive. The load devices, T5 and T 6 , replace the leakage
current from the more positive node during stand-by.
Since one of the load devices has full voltage across it at
all times, the standby power dissipation of the cell will
be quite high in comparison to the cell sense current
unless the W/L ratio, Figure 9, of the load device
(T 5, T 6) is made very small compared to the W /L ratio
of the cross-coupled device (T I , T2)' This, in turn,
requires that either the load devices or the active
devices or both occupy a large chip area. In addition,
the standby load current flowing through the on-biased
active device provides a voltage drop across that device,
tending to unlatch the cell. This effect can be compensated for by increasing the value of all device
thresholds, however, this will require a higher supply
voltage to maintain the same standby current thereby
increasing the power dissipation.
In cell 8(b), the standby power is reduced by pUlsing
the "restore" input at a clock rate sufficiently fast to
replace leakage current from the cell node capacitance,
while maintaining a low average power drain. The chief
drawback to this cell is the five connections must be
made to the cell, with a resulting increase in cell
complexity over (a) above.
Cell 8(c) shows the configuration chosen for this
memory. In this cell, both the word selection and the
restore functions are performed through the same
devices and array lines, by time sharing the word-select
and restore line. During read-out, the cell operation is
similar to 8(b) above. At the end of each memory cycle,
however, all word lines are raised to the "restore" level
for a period sufficient to recharge the cell node capacitances, then all word lines are dropped and the next
memory cycle can begin. Selection of the "restore" level
is dependent on the speed at which the cell node
capacitance is to be charged and the sense line voltage
support level required during restore. Too high a
"restore" level creates a large current flow thru the
restore devices lowering the sense line voltage used to
charge the cell; too low a voltage prevents the cell node
59
capacitance from reaching the required voltage for data
retention. This cell employs fewer devices and less
complex array wiring than either of the cells above, and
thus requires substantially less silicon area. The
disadvantage of this approach is that the restore
function must be synchronized with the normal read/
write function since they share the same circuitry. The
average power cannot be made as low as in (b) above,
since the restore current and the sense current are both
determined by a common device, and the restore
frequency is determined by the memory cycle time;
however, the average power can be made significantly
lower than with the static cell 8(a) above.
MOS-FET support circuits
The MOS-FET support circuits employed on the
array chip are shown in Figure 10. A better understanding of the circuit operation will be gained by first
considering the MOS-FET inverter circuit (Figure 10).
At the end of a read/write cycle, the input address level
is held down, the E level is down, and the R line is
pulsed positive, charging node A to approximately +7
volts. When the R pulse has terminated, node A
remains positive awaiting the next input. At the start
of the read/write cycle, the address input is applied to
T I ; if the address line is positive, node A quickly
discharges through T I , and when E is applied to T 3,
+v
SELECT I REFRESH
~~
ADDRESS
r
I
4
3
2
5
(b)
+V
E
R~ftr~l
TI
ADDRESS I ""ur ...:.--.-.j
I
T3
4 I-
..
-:-
:±= CL
(a)
Figure lO-Array chip inverter-decoder circuits
6()
Fall Joint Computer Conference, 1970
T 3 remains non-conducting and the address inverter
output remains at ground potential. If, however, the
address input line is a down level, then node A remains
charged to +7 volts, and both Tl and T2 are cut-off,
while T 3 is biased on. When a positive E pulse is
applied to T 3, current is capacitively coupled into
node A from both the E node and from the output node,
with the result that node A is driven more positive than
either; thus T 3 remains strongly biased on, charging the
output node capacitance to the level of E. When the
positive E pulse is terminated, the same action quickly
discharges the output to ground through the E line. At
the ead of the address pulse, a positive R pulse is again
applied to T 2, restoring node A to
7 volts. This
regenerative inverter has several advantages over a
conventional source follower circuit; (a) the output up
level is set by the level of the E input, and does not vary
with the device threshold voltage; (b) the output rise
time is nearly linear, since the gate-to-source bias on T3
remains well above the threshold voltage throughout
the transition, and (c) this same high conductance
output device can be used to both charge and discharge
the load capacitance. Since the leakage current from
node A during a cycle is negligible, the final potential
of node A, and thus the output drive current, is
determined by the capacitor-divider action of the
gate-to-source, gate-to-drain, and gate-to-substrate
capacitances associated with device T 3. Any of these
capacitances can be artificially increased to optimize the
circuit operation. The operation of the decoder circuit
(Figure lOb) is similar to the inverter just described,
with the bi-Ievel chip select/refresh line replacing the E
input discussed previously. Thus, a single word line is
selected to the higher (Select) level during the Read/
Write portion of the cycle, while all word lines are
selected to the lower (Refresh) level during the Restore
portion of the cycle. Thus the cell input/output devices
are biased to a low impedance to provide maximum
sense current during readout, and to a higher impedance
to reduce the power dissipation and maintain the
necessary sense line voltage during the restore operation.
Protective devices are used on all gate inputs to the
array chip to reduce the yield loss from static electricity
during processing, testing, and assembly. Because the
array chip uses a P-epitaxy grown on a P+ substrate it
was possible in this system to replace the usual RC
protective device with a more favorable zener type. This
device is an N diffusion diffused at the same time as
the source-drain diffusions and exhibits a low internal
impedance when its depletion region intersects the P+
substrate. The required reverse breakdown voltage is
obtained by controlling the depth of the N diffusion.
When driven with an impedance equivalent to a human
body, approximately 1000 ohms, gate protection is
+
+
+
1-----1
i
's VB.
i
h
NUMBER OF
I
IA~~~~~~~~sl
1 INFINITY I
1
1
I
I
I
1
1
V.
ATE
Figure 11-Gate protective device
provided for input levels up to 3400 volts. Figure 11 and
equation 1 represent the characteristics and operation
of this type protective device as presented during the
IEEE, International Electron Devices lVleeting, October
29 thru 31, 1969. 1 For analysis the device is arranged as
a series of distributed elements; each element containing sub-elements rs, ra, and V BR.
Vgate = V BR+ {(V in - V BR)(rsra)I/2 [cosh (rs'Y /ra) 1/2]-1 } /
R8+(rSra)1/2
(1)
In this design 'Y, the number of elements, was set at
nine with the following sub-element values:
rs
= 4.27 ohms
r
= 61.2 ohms
V BR = 30 volts
The maximum capacitance before breakdown
1. 25pf.
IS
Bipolar support circuits
Because of the critical timing relationships required
among the Select/Refresh, Enable, Address, and Restore pulses to the array chip, all timing pulses are
generated on each card by a special timing chip and three
tapped delay lines. This arrangement· allows each card
to be fully tested with the timing circuits that will drive
it, and minimizes any interaction between cards in a
multi-card system.
The TTL compatible buffer chip allows interfacing
conveniently with the TTL compatible logic of the using
system, and 'minimizes the loading which the memory
presents to the system.
A schematic cross-section of the Drive and Sense
circuits is shown in Figure 12. The Driver module, when
addressed, selects a row of nine Array Chips from a low
impedance TTL output. The ten address inputs to the
Design of Mega-Bit Semiconductor Memory System
TO 7 0'1'11111 AIIIIAY C:III.'
61
CROSS SEeTION
HIVE -SENSE SCHEMATle
DIAGRAM
FIG. 1-2
"'ST'"
IIiADLI
--- - -------- - -- - - -------- ------ - ---- ---'-i
~
~.:a
7
II_.ILICT
'1'1._111-,
o-+-~,.,.,."
:::.- :!
1I
1
-
I till"
·111
I
I
1
0-+-- - - - - '
I
AaO-'-----'
1
.. 0-+------'
'1
I
1
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ .J1
r- - - - - - - - - - - - - - - - - - - - - - - - - - Vet
DATAIII-
81,.
KIlO
ZlNO
DIIIVI
OUT
-FLOIII
- ------
--------------------------,
-
II.
UI
DI'I'
_VI
OUT
O-~:--~~----~-L==~====::~====~==~====~====t===~======~==~-4----~----~----~
r- ___________ J
I _________
111111 LATCII "DULl
L
.,
1
1
I
1
1
I
I
L-------"3I
LATCII ~:;;.::=:::-r--<>
I
I
1
I
ON.
L
___________________________________________
NT
IIIIIT
III
..
JI
Figure 12-Cross-section drive-sense schematic diagram
Array Chip serve to select one bit of the 1024 bits/chip.
The write pulse permits the data-in to be loaded
differentially into the single bit which has been addressed. The removal of the write pulse turns off both
the "one" and "zero" bit drives with the low impedance
active pull ups rapidly charging the capacitance of the
bit lines to a voltage level required for the re~d mode of
operation.
The sense amplifier requires a minimum differential
signal of 50 micro amps to detect a "one" or "zero"
stored in the addressed bit. This information is transferred to a set-reset latch which is included to increase
the "data-good" time to the using system.
During a portion of every cycle not used for read/
write operation the timing chip provides refresh and
restore timing pulses which turn on all the driver modules on the memory card to a lower voltage level, and
perform the refresh operation previously discussed.
All four of the bipolar support chips are packaged
one-chip per chip carrier, to allow flexibility in configuring various size memory systems. In all cases,
the power density is limited to 600 mw per chip carrier,
15-0
140
130
1\
...
~
110
!
1
I
CARD S
\
l~lP~~9)"H,8.8"W
I
~
~
~
90
200
250
I
CARD PITCH" 0.6"
MODULE PI.TCH • 0.7"
Tin· 50·C
~
100
80
150
I
VAR 1AT 1ON OF JUNC T 1ON TEMPERATURE
WITH
VELOC ITY AND INLET TEMPERATURE
300
-
350
~ t--.
400
VELOCITY
450
r--- r---500
550
600
ft I min
Figure 13-Variation of junction temperature with velocity and
inlet temperature
62
Fall Joint Computer Conference, 1970
a level which allows for convenient forced-air cooling.
Because the limiting heat factor is the junction temperature of the bipolar support circuits an cooling
considerations are in respect to this parameter. Figure
13 illustrates the junction temperature as a function
of air flow thru the system.
CONCLUSION
The memory system described here is but one of many
possible sizes and organizations that can be created
using the same modular approach. If desired, several
smaller organizations can be used within the same
system without significant cost penalties. The system
approach to memory design has created an optimum
condition wherein each individual component is
matched to the other components with which it must
interact. This approach also yields a memory with
a simple, effective, easily usable set of interface requirements. It is anticipated that increasing yields
will allow prices competitive with magnetic storage
for high-performance main memories. This low cost,
coupled with high performance and density, makes
a powerful combination for use in future system designs.
REFERENCE
1 M LENZLINGER
Gate protection of MIS devices
Presented at International Electron Devices Meeting
Washington D C 1969
Optimum test patterns for parity networks
by D. C. BOSSEN, D. L. OSTAPKO and A. M. PATEL
IBM Laboratories
Poughkeepsie, N ew York
input Exclusive-OR gate. Each gate, therefore, is
given a complete functional test so that single error
detection means that any error in "one Exclusive-OR
gate can be detected. The following is the definition
of a gate test.
INTRODUCTION
The logic related to the error detecting and/or correcting circuitry of digital computers often contains
portions which calculate the parity of a collection of
bits. A tree structure composed of Exclusive-OR gates
is used to perform this calculation. Similar to any other
circuitry, the operation of this parity tree is subject
to malfunctions. A procedure for testing malfunctions
in a parity tree is presented in this report.
Two important assumptions are maintained throughout the paper. First, it is assumed that the parity tree
is realized as an interconnection of Exclusive-OR gates
whose internal structure is unknown or may differ.
This requires that each gate in the network receive a
complete functional test. Second, it is assumed that
detection of single gate failures is desired.
Since each gate must be functionally tested, an minput Exclusive-OR gate must receive 2m input patterns. It will be shown that 2m test patterns are also
sufficient to test the network of any size, if m is the
maximum number of input lines to any Exclusive-OR
gate. Hence, the procedure yields the minimum number
of test patterns necessary to completely test the network for any single Exclusive-OR gate failure. It will
also be shown, by example, that the procedure is fast
and easy to apply, even for parity trees having a large
number of inputs.
Definition 1 :
A test for a k-input Exclusive-OR gate is the set of
2k distinct input patterns of length k. Figure 1 shows a
three input Exclusive-OR gate, the 23=8 input test
patterns, and the output sequence which must result
if a complete functional test is to be performed.
If the output sequence and the sequences applied to
each input are considered separately, each will be a
vector of length 2k. Thus;-the Exclusive-OR gate can
be considered to operate on input vectors while producing an output vector. Figure 2 shows a three input
Exclusive-OR gate when it is considered as a vector
processor. In terms of vectors, a test is defined as
follows.
Definition 2:
A test for a k-input Exclusive-OR gate is a set of k
vectors of length 2k which, when considered as k sequences of length 2k , presents a1l2k distinct test patterns
to the gate inputs.
GATE AND NETWORK TESTABILITY
Theorem 1:
If K is a test for a k-input Exclusive-OR gate, then
any set M, MCK, having m, 2~m~k-l, elements
forms 2k - m tests for an m-input Exclusive-OR gate.
Since the approach is to test the network by testing
every gate in the network, it is primarily necessary to
discuss what constitutes a test for an individual Exclusive-OR gate. Although it is assumed that the
parity trees are realized as a network of Exclusive-OR
gates, no internal realization is assumed for the Exclusive-OR gates. Hence, it will be presumed that all
2k input patterns are necessary to diagnose a single k-
Proof:
Consider the k vectors in K as sequences. Arrange
the sequences as a k by 2k matrix in which the last m
63
64
Fall Joint Computer Conference, 1970
00010111
00101011
01001101
=:8. .-..
Wo WI W2 W3 W4 W5 Ws
01110001
Figure I-Three input Exclusive-OR gate with test patterns
rows are the sequences in M. Code each column' as a
binary number with the highest order bit at the top.
Since the columns are an distinct according to definition
1, each of the numbers 0 through 2k-1 must appear
exactly once. Considering just the bottom m rows, it
follows that each of the binary numbers 0 through
2m-1 must appe:u exactly 2k - m times. Since each of
the possible sequences of m bits appears 2k - m times,
definition 1 implies that the set M forms 2k - m tests for
an m-input Exclusive-OR gate.
Network testability:
Two conditions are necessary for a network of Exclusive-OR gates to be completely tested. First, each
gate must receive a set of input vectors that forms a
test. Second, anyone gate error must be detectable at
the network output. For the first condition it is necessary that the set of vectors from which the tests are
taken be closed under the operation performed by the
k-input Exclusive-OR gates. The second condition
requires that any erroneous output vector produce an
erroneous network output vector. The structure of this
set of vectors and their generation will be discussed in
the following sections.
AN EXAMPLE
Wo
101 I 100
Wo 0
WI
010 I I 10
WI
W
2
W3
00101 I I
W2
W4
1100101
w5
I I I 00 10
W4
w5
Ws
01
Ws
100 101 I
1001
W5 W3 W2 Ws WI W4
0 Ws W W3 Wo W
4
2
0 Wo W5 W WI
4
~3
0
0
I, ~
= 01001101, .!!. = 01110001
Figure 2-Three input Exclusive-OR gate as a vector processor
w3
0
Figure 3-Test sequences and their addition table
then successively determining input sequences which
test each gate to produce the desired output.
Figure 3 presents the seven sequences and the associated addition table that will be used in the example. Figure 4 illustrates the gate labeling procedure
which will be used to determine the inputs when the
output is specified. Figure 5 shows the parity tree with
57 inputs and 30 Exclusive-OR gates of two and three
inputs arranged in a four level tree. The procedure
generates eight test patterns which will completely test
all 30 gates of the tree.
The procedure is initiated by assigning an arbitrary
sequence to the output of the tree. In the example,
Wo is selected as the final output sequence. Employing
the 3-input gate labeling procedures shown in Figure
4, the inputs are determined to be WI, W 2, and W 4 •
With these three sequences, the gate is completely
tested. These inputs are then traced back to the three
gates in the third level. Using the gate labeling procedure again, the inputs for the gates from left to right
are W 2, W a, Ws; W 3 , Wo; and W s, W 2 • The sequences
assigned to the inputs can be determined quickly and
easily by making use of tracing and labeling. Under
proper operation, each gate is completely tested and a
single gate failure will produce an incorrect sequence
2 -INPUT
= 00010111, ~ = 0010101
w2 Wo
0
The test pattern generation procedure is so simple
and easy to apply that it will be presented by way of
an example before the theoretical properties of the
desired sequences are discussed. The algorithm proceeds by selecting an arbitrary output sequence and
WHERE ~
WI Ws W5
NOTE: Wi
==
3-INPUT
Wi (MOD 7)
Figure 4-Gate labeling procedures
Optimum Test Patterns
at the output. Above each input the required sequence
is listed, and the correct output is the sequence Woo
The test patterns are obtained by reading across the
sequences and noting the correct output. The test is
completed by adding the all zero test pattern. This
should produce a zero output.
65
000000000000000000000000000000000000000000000000000000000
III 100
110 III
Oil 110
001011
101001
010 101
100 010
101 100
010 III
100 110
III 011
110001
011 101
001 010
010001 101 001 110 100
100 101 010 101 011 III
II I 010 100 010001 110
110 100 III 100 101011
011.11 I 110 II I 010001
001 110011 110 100 101
101 OJ 1001 Oil II 1010
010001
100 101
II 1010
110100
Oil '"
001 110
101011
011 110 100 101
001 01 I III 010
101 001 110 100
010101 011 III
100 010001 110
III 100 101 011
110 II I 010001
III III 001
110 110 101
011 Oil 010
001001 100
101 101 II I
010010110
100 100011
4SO 561 013561 602 124013 124 346561 602124 23534651 013 4SO 450 124
THEORETICAL PRELIMINARIES
Consider the set of vectors generated by taking all
mod-2 linear combinations of the k vectors of a given
test set K. This set is obviously closed under mod-2
vector addition. In a parity check tree network an
input of any subset of vectors from this set will produce vectors in the set at all input-output nodes of
the Exclusive-OR gates. Some further insight can be
gained by viewing the above set as a binary group
code. The generator matrix G of this code, whose rows
are k vectors from K, contains all possible k-tuples as
columns. If we delete the column of all O's in G, the
resulting code is known as a MacDonald l code in which
the vector length n is 2k -1 and the minimum distance
d is 2 k - l • The cyclic form of the MacDonald code is
the code generated by a maximum length shift register.2
o
I
o
I
I
I
o
o
Figure 5-Four level parity tree with test patterns
degree kin GF (2). Let g(X) = (Xn-1)jp(X) where
Theorem 2:
Any independent set of k vectors from the Maximum
Length Shift Register Code of length 2k -1 forms a test
set for a k-input Exclusive-OR gate, excepting the
pattern of all O's.
Proof:
n = 2k -1. Then the first vector Wo of the MLSRC is
the binary vector obtained by concatenating k-1
zeros to the sequence of the coefficients of g (X). The
vectors WI, W 3 ••• Wl- 2 are then obtained by shifting
WI cyclically to the right by one digit for 2k - 2 times.
The method is illustrated for k = 3. A primitive polynomial of degree 3 in GF (2) can be obtained from
tables, 2 e.g., X3+ X + 1 is primitive.
g(X) = (X'l-1)j(Xa+X+1) =X4+X2+X+1.
Any independent set of k-vectors from the code
forms a generator of the code. In the Maximum Length
Shift Register Code as well as in the MacDonald Code,
2d-n = 1. This implies*3 that any generator matrix
of the code contains one column of each non-zero type.
By definition 2, this forms the test for a k-input ExOR gate excepting the test pattern of all O's.
Corollary:
Then Wo is obtained from g(X) as
Wo=10 1 1 1 0 0
The sequences WI, W 2 ••• W6 are obtained by shifting
Wo cyclically as,
W1=0 1 0 1 1 1 0
W 2 =O 0 1 0 1 1 1
TV3 = 1 0 0 1 0 1 1
For an m-input gate, m~k, any set of m-vectors
from a MLSRC of length 2k -1 forms a sufficient test.
The proof follows from Theorems 1 and 2.
The maximum length shift register sequences can
be generated2 by using a primitive polynomial p(X) of
* In
Reference 3 it is shown that in a group code with 2d -n =
t > 0, there are t columns of each type.
W 4 =1 1 0 0 1 0 1
W5=1 1 1 0 0 1 0
W 6 =O 1 1 1 0 0 1
Note that when W 2k-2 is shifted cyclically to the right
by 1 digit, the resulting vector is Woo For the purpose
of uniformity of relationship among the vectors we
66
Fall Joint Computer Conference, 1970
introduce the notation: Wi== Wi (mod 2k_l). Now the
following theorem gives a method of selecting independent vectors from a MLSRC.
Theorem 3:
The vectors Wi, W i+l, ... , W i+k-l in a MLSRC of
length 2k -:-1 form an independent set.
Proof:
Suppose g(X) is given by g(X) = grXr+ gr_1Xr-I +
O, where r= (2k-l) -k. Then the set of
vector W o, WI, ... ,Wk - I are given by
... + glX+g
go
gr-l
0
0
0
go
0
0
go
0
o
o
o
(2) and (3) to determine the proper inputs to
the. corresponding gates.
4. The vectors at the input lines to the Ex-OR tree
are then the test input vectors with the correct
output as Wi.
5. An additional all 0 pattern as input to the· network with 0 as correct output completes the
test.
It is easy to see· that the test patterns generated by
the above algorithm provide a complete test for each
Ex-OR gate in the parity check tree. Furthermore, any
single gate failure will generate an erroneous word
which will propagate to the output. This is due to the
linearity of an Ex-OR gate. Suppose one of its inputs is
the sequence Wi with a corresponding correct output
sequence W j. If the input Wi is changed by an error
vector to Wi+e, then the corresponding output is
Wj+e. Clearly, the error will appear superimposed on
the observed network output.
TEST MECHANIZATION
o
o ..
go
Clearly they are linearly independent. Because of the
cyclic relationship, this implies that Wi, W i+I , ... ,
W i +k - 1 are independent.
Corollary:
The vectors Wi+I, Wi+2, ... ,Wi+m- I , and WiEBWi+lEB
... EBWi+m-I, (m~k), form an independent set. With
this as a test to an m-input Ex-OR gate, the correct
output vector is Wi.
As a direct consequence of the above theorems we
have the following algorithm for the test pattern generation for a given Exclusive-OR network.
We have shown that the necessary test patterns for
a parity tree can be determined by a simple procedure
using a set of k independent vectors or code words
W o, WI, ... , W k - l from a MLSRC as the input to
each gate of k inputs. The result of applying this procedure to a network is an input sequence Wi for each
network input and each network output. Testing is accomplished by applying the determined sequences
simultaneously to each input and then comparing the
expected network outputs with the observed network
outputs.
Let the gate having the greatest number of inputs in
the. network show k inputs. The entire test can be
mechanized using a single (2k-l)-stage feedback
shift register. To do this a unique property of the
MLSR codes is used. From this property it follows that
the entire set of non-zero code words is given by the
Algorithm for test pattern generation:
It is assumed that the Exclusive-OR network is constructed in the form of a tree by connecting m-input
Ex-OR gates where· m may be any number such that
m~k.
1. Select any vector Wi from a MLSRC of length
2k -1 as the output of the network.
2. Label the inputs to the last Ex-OR as Wi+I,
W i+2, ••• , W i+m-l, and Wi EB W i+l EB ... EB W i+m-l·
3. Trace each of the above inputs back to the
driving gate with the same vector. Repeat steps
~--Wo
---=,--... W,
L....--._ _ _
------------'----~0,--_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Figure 6-Shift register for generating test patterns
W2 "-3
W "-2
2
Optimum Test Patterns
67
2k - 2 cyclic shifts of any non-zero code word together
with the code word itself.
If a (2k-1)-stage shift register is loaded with a particular code word Wo as in Figure 6, then the sequence
of bits observed at position 1 during 2k -1 shifts of
the register is the code word Woo Similarly for every
other position i, a different code word W i - 1 is observed,
so that the entire set of 2k -1 sequences is available.
Since the correct output of the network is one of the
code words, it is also available at one of the stage outputs for comparison. The general test configuration is
given by Figure 7.
SELF-CHECKING PARITY TREE
Let us suppose that the test sequences and the shift
register connections for a parity network have been
determined as in Figure 7. A modification of this mechanization can be used to produce a self-testing parity
network under its normal operation. The key idea is to
monitor the normal randomly (assumed) occurring
inputs to the network and to compare them with the
present outputs of the shift register. When and only when
a match occurs, the comparison of the outputs of the
parity networks with the appropriate code words is
used to indicate either correct or incorrect operation,
and the shift register is shifted once. This brings a
new test pattern for comparison with the normal inputs. Every 2k -1 shifts of the register means that a
complete test for all single failures has been performed
on the network.
12 "-1
STAGE s.R.l
1
Wo
~~
W2"_3
W2"-2
···
PARITY
TREE
~~
ERROR
Figure 8-Self checking parity tree
The mechanization of the self-checking parity tree
is shown in Figure 8. The inputs to the AND gate
Awl are the set of input lines of the parity tree which
receive the test sequence Wi. The inputs to the AND
gates AWiO are the inverse of the input lines of the parity
tree which receive the test sequence Wi.
An alternate approach to self-checking is to use the
testing circuit of Figure 7 as a permanent part of the
parity tree. The testing is performed on a time-sharing
or periodic basis while the circuit is not used in its
normal mode. This is easily accomplished by having
the clock, which controls the shift register, gated by a
signal which indicates the parity tree is not being used.
This could be a major portion of the memory cycle
when the parity tree under consideration is used for
memory ECC.
CONCLUSION
....
.....,
j
OR
!
ERROR
Figure 7-General testing scheme
I
We have shown that a very low and predictable number
of test patterns are necessary and sufficient for the
complete testing of a parity tree under the single failure
assumption. The required tests are easily and rapidly
determined by an algorithm which is presented. (An
application of this technique is also given for a selfchecking parity tree.) Since the effect of the input test
patterns is a complete functional test of each gate, the
tests are independent of any particular failure mode.
68
Fall Joint Computer Conference, 1970
REFERENCES
1 J E MAcDONALD
Design methods for maximum minimum-distance I error
correcting codes
IBM J of R&D Vol 4 pp 43-471960
2 W W PETERSON
Error correcting codes
MIT Press Cambridge Massachusetts 1961
3 A M PATEL
Maximal group codes with specified minimum distance
IBM J of R&D Vol 14 pp 434-443 1970
A method of test generation for fault
location in combinationallogic*
.
by Y. KOGA and C. CHEN
University of Illinois
Urbana, Illinois
and
K. NAE1VIURA
Nippon Telegraph and Telephone Public Corporation
Musashino, Tokyo, Japan
exhaustively generated tests to isolate failures or near
minimal test generation methods for failure detection,
but their methods are impractical to generate tests
for actual digital machines. Actual test generation
using the method presented in this paper has been
done for the ILLIAC IV Processing Element control
logic, and is briefly discussed.
INTRODUCTION
The Path Generating Methodl is a simple procedure
to obtain, from a directed graph, an irredundant set of
paths that is sufficient to detect and isolate all distinguishable failures. It was developed as a tool for diagnostic generation at the system level, e.g., to test data
paths and register }oading and to test a sequence of
transfer instructions. But it has been found to be a
powerful tool for test generation for combinational
logic networks as well.
The combinational network to be diagnosed is represented as a set of complementary Boolean forms, where
complementation operators have been driven inward
to the independent variables using DeMorgan's Law.
A graph is then obtained from the equations by translating logical sum and logical products into parallel
and serial connections, respectively. A set of paths is
generated from the graph, which is irredundant and
sufficient for detection and isolation of single stucktype failures.
The advantage of this approach to test generation
lies in the irredundancy and isolation capability of the
generated tests as well as the simplicity of the algorithm.
Several test generation methods have been develveloped,2,3,4,5,6 but none attacks the problem of efficient
test generation for failure isolation. Some of these
papers presented methods to reduce redundancy of
PATH GENERATING METHOD
In this section, test generation by the PGM (Path
Generation Method) to a given directed graph will be
discussed briefly.
Let us consider a graph with a single input and a
single output such as that shown in Figure 1. If this
actual circuit has multiple inputs or outputs, we add a
dummy input or output node and connect them to the
actual inputs or outputs so that the graph has only one
input and one output node.
There exist thirteen possible paths from the input
node No to the output node N5 of the digraph in Figure
1, but not all of these are needed to cover every arc of
the graph. We arrive at a reduced number of test paths
in the following manner.
Starting at the input node, we list all the nodes which
are directly fed by the input node, i.e., have an incident arc which originated at the 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. Nodes directly
connected to the level one nodes are then listed and
assigned to level two. This step is repeated until all
* This work was supported by the Advanced Research Projects
Agency as administered by the Rome Air Development Center,
under Contract No. US AF 30(602)4144.
69
70
Fall Joint Computer Conference, 1970
INPUT
~ ---=:':":::---11
)t---:;O~/1:""-__d
d=o·b·c
a
a
b
c
graph
OUTPUT
o
Figure 1-A directed graph
nodes are covered. If a node has already occurred on a
higher level or previously on the same level, we define
it as a pseudo-terminal node and cease to trace arcs
down from it.
Whenever a path from the input reaches a pseudoterminal node, we complete the path by arbitrarily
c
~ INPUT
No
•
denotes
a' pseudo
terminal node.
complement graph
and 1 denote a stuck-at-one and stuck-at-zero
failure, respectively, and
by the output failure.
*
denotes a masked failure
Figure 3-AND gate and its graphic representation
choosing any route (usually the shortest) which goes
from it to the output. Six paths are obtained from the
digraph in Figure 1 as shown in Figure 2, where shortest paths are selected after reaching a pseudo-terminal
node.
The main advantage of this test generation method
is that the set of paths generated by the PGM is an
irredundant set which is sufficient for detecting and
locating any distinguishable single failure within any
cycle-free graph. It should be noted that any arc in the
graph is assumed to be able to be actuated independently for a test path.
GRAPHIC REPRESENTATION OF
COMBINATIONAL LOGIC
Figure 2-Generated test paths
To apply this PGM to a combinational logic network,
a graphic representation of a combinational logic
which takes into account stuck-type failures must be
used.
An AND gate with three inputs and one output has
possible s-a-1 (stuck at one) and s-a-O (stuck at zero)
failures. A s-a-O failure at output d is indistinguishable
Method of Test Generation
from each s-a-O failure of the inputs a, band c, but there
exist five distinguishable failures, as shown in Figure 3.
Let· us consider the straightforward graphic representations of this AND gate and its complement expression. In this example, a, band c can denote simple
variables or sets of subgraphs representing parts of a
logic network. Note that if the four paths are assumed
to be paths to test the AND gate where these. paths
can be actuated independently, all distinguishable
faults can be detected and single faults can be located.
The graphic representation is slightly modified to
demonstrate this, as shown in Figure 4, where Fd=O
means no such fault that the output d is s-a-O.
It is obvious that anyone of five distinguishable
faults can be located by the four test paths, where only
one test path should be completed for each test. To
generate a set of test inputs, variable valu'es should be
assigned such that only the path to be tested is completed and the rest of the paths are cut off. The test
values for the variables (a, b, c) are determined to be
(1, 1, 1), (0, 1, 1), (1, 0, 1) and (1, 1, 0) for a three
input AND gate.
If one input variable is dependent on another then
normally distinguishable failures may become indistinguishable. For example, if variable a is dependent
upon variable b, then a s-a-l failure at input a and a
s-a-l failure at input b may become indistinguishable
or undetectable.
Whenever anyone of the variables a, b, and c is replaced by a subgraph which represents a part of a logic
network, the same discussion is extended to the complex
71
:~d
Original Logic gat~
(a)
d ~
ab
+ c
eao.
~e~,.
e
a.,
~F.:.',
Fe.,
(b)
=
d
CL"
'C=O
Possible gate failures
: °0°
~o
~_,
(c) OR gate test
generation graph
1;.,
F;
b-,
~-o
e
subgraph for e and
.lSr
(d)
e
denotes a new indistinguishable failure by connection.
r.raph for test generation
Figure 5-A logic network containing a negation
a
b
C
Fc"=1
Fd=o
Figure 4-Complex graph for test generation to take into
account failures
graph. Also, a similar argument can be applied to an
OR gate. If a NOT operation appears between two
successive gates, the input variables to the following
gate are replaced by the dual subgraph of the preceding
gate. Alternatively, the graph will be given directly
from equations modified such that negations are driven
inward to the primary input variables by applying
DeMorgan's Law to the given Boolean equation. For
example, the graph for test generation with the logic
network in Figure 5a is given as shown in Figure 5d.
The same graph is derived from the transformation
of the Boolean equation as
d=ab+c=a+b+c
and the graph for test generation is given directly by
the above equation. It is obvious that distinguishable
failures in the original logic network are still distinguishable in the complex graph representation for test
generation.
72
Fall Joint Computer Conference, 1970
eration and distinguishable failures in a combinational
network were not clearly established. The main advantage of the graphic representation of a combinational network (including the complement expression)
is that the graph contains failure information explicitly
as discontinuities of arcs or nodes instead of s-a-O and
s-a-l failures in the original combinational logic
network.
r-------..,I
~--------~I
Fvm2-COf :
!r---------~I
I
:
I
~
~ T.
!::r--L i
tH. .JJi
1.
TEST GENERATION FOR COMBINATIONAL
CONTROL LOGIC
L ___
~
r--------,
~
piI-wi6--1
PAW-W17-:.t •
JiUti
I
:
I
I
I
I
I
I
I
PY[8-ACLDl
Figure 6-An example of control logic of ILLIAC IV PE (Closed
dotted line denotes an IC package and half one denotes
a part of IC package)
From the previous discussion it will be noted that if
those input variables which correspond to the nodes
in a path test through the original graph of a logic function are activated, the combinational logic network will
give an output of a logic 1, whereas if the path goes
through the complement graph, the output will be a O.
For example, if we set a = 1, b = 1 and c = 1 in Figure 4,
the output of the network is a logical 1. If a, b or c
stucks at 0, the faulty network will produce output 0
instead of 1. This test can detect single failures a, b, c
or output d stuck at o.
In order to detect the s-a-l failure of input line a, b, c
and output line d, the path tests in the complement
graph are required. A s-a-O type failure of one node in
an original graph will become a s-a-l type failure in
the complement graph and s-a-l type failure of one
node in an original graph will become s-a-O type failure
in the complement graph. Now it is clear that the complement graph of the original graph is required for the
output stuck at ~1.
In test generation methods which have been presented in the past, the relationships between test gen-
The output of any portion of a computer control logic
is usually governed by many input conditions, but the
fan-in of a typical logical element is usually restricted
to only a few inputs. This causes the number of gate
levels necessary to generate a function to increase and
the structure of control logic becomes tree-like. The
network shown in Figure 6 is a typical control logic of
the ILLIAC IV PE. Since there are about 50 distinguishable failures in the network, about 50 iterations
of a path sensitizing would be required by conventional
technique, or more than 8000 terms would have to be
handled by Armstrong's method. 2 In both cases, neither
the irreducibility of tests nor the isolation capability
of distinguishable failures would be guaranteed.
The network of Figure 6 is translated into the graph
of Figure 7 and Figure 8, from which the PGM will
generate tests, and the irredundancy and isolation
capability of the generated tests are guaranteed as well
as the simplicity of the algorithm.
To make a test path in the graph, the variables on
the path under test should be actuated and the rest of
the paths should be cut off. If the original logic network does not have a complete tree structure, a few
conflicts may occur in assigning values to variables to
Figure 7-A graph representation of Figure 610gic diagram
Method of Test Generation
make a test path generated by the PGM. These may
easily be resolved, as will be shown later.
73
PYE8-ACLDI +-( «PMW-EI---O AND NOT FYEM32-LOT) OR
«FYEElA-HMT OR NOT PMW-EI---O) AND NOT
Transformation of boolean equations to arc descriptions
FYE8-ACLCl) OR
«NOT P-EX-UF-LH AND
The description of a combinational logic network is
assumed to be given by a set of Boolean equations
using the operators AND, OR and NOT.
For example, from Figure 6 of a part of the control
logic of the ILLIAC IV PE, the Boolean equation is
(FYEElA-HMT OR NOT PMW-EI---O»
AND NOT
FYEM648L-T) OR
(NOT FYE98ASLIT AND
«FYEElA-HMT OR NOT PMW-EI---O) AND NOT
P-CARRYH-L AND NOT PEXDI-L48L») OR
«P4W-WIO--IOR PAW-W09--1 OR
PBW-W09--1) AND
(NOT P-EX-UFlLH AND
(NOT PAW-W16--1 AND PAW-W17--1) AND
(NOT FYEM329LIT OR NOT FYEMULTL9T) AND
FYEM648L-T
P-EX-UF-LH
(FYEElA-HMT OR NOT PMW-EI---O») OR
« (FYFElA-HMT OR NOT PMW-EI---O) AND NOT
P-EX-UF-LH AND NOT FYEM649L-T AND
(NOT PAW-W16--1 AND PAW-W17--1»
FYE98ASLIT
(PAW-WOl--l OR PBW-WOl--l OR
P4W-W02--1»
FYEElA-HMT
AND
OR
«PGC--16--1 OR P--1-7I--O) AND
«(FYEZlA-HMT OR NOT PMW-EI---O) AND NOT
FYE98ABLIl) OR
PMW-El---O
(NOT FYE9BABLFI AND
PAW-WOl--l
(FYEElA-HMT OR NOT PMW-EI---O»»);
PBW-WOl--l
Figure 9-Squeezed equation of Figure 6
P4W-W02--1
FYE98ABLIl
FYEElA-HMT
PMW-EI---O
P--L-7I--O
Figure 8-A complementary graph of Figure 6 logic diagram
derived* and this equation was then 'squeezed' by a
program as shown in Figure 9, where logical constants
(used to disable unused gate inputs) are removed from
the functional Boolean expression, and NOT operators
are driven into the innermost individual variables of
the equation by use of DeMorgan's Law.
N ow we try to transform the Boolean equations into
the graph descriptions. AND operations are trans-
* In the case of the ILLIAC IV PE design, the Boolean equations
are automatically generated from wiring information. This same
equation set was also used for debugging the logical design.
74
z
Fall Joint Computer Conference, 1970
=
a AND b
z
= a OR b
Let zbe a Boolean function of the Boolean variables
Xl, X2, ••• ,Xn and expressed as Z=Z(XI, X2, ••• , xn).
Let P be one of the path tests generated from the arc
description of the Boolean function z, and, be defined
bya set of Boolean variables on the path as P=
{Xll1 Xh, ••• ,Xla } where Xl l1 Xl 2, ••• ,xlaE {Xl, X2, ••• ,
Xn,
~a)
AND operation
(b) OR operation
Figure 10-Transformation of the Boolean equations into graph.
AND operation in graphic form
formed into series connections and OR operations into
parallel connections as shown in Figure 10.
The graphic representation of a combinational logic
network is translated as arc description for the input
to the PGM program. The AND operation, a AND b,
is translated as b~a, where a is the source node and b
the destination node. The OR operation is translated
as a~dn1, dn2~a, b~dn1 and dn2~b, where dn represents dummy node.
In the arc description generation program which we
developed, redundant dummy nodes are removed insofar as possible. For example, dummy nodes can be
eliminated from the OR operation in the various ways
shown in Figure 11 depending on the original Boolean
equation.
For ILLJAC IV PE control logic we get 111 Boolean
equations. The 111 Boolean equations and their 111
complemented equations can be visualized as 222· subgraphs and all connected to an input node and output
node. The arc descriptions of this big graph are processed by a program (PGM algorithm) to produce a
set of 464 paths for diagnosis.
X2, ••. , X n }.
{Xll1 Xh, ••• , Xl a }·
The conflict in the path will cause some trouble in
the assignment of the variables. Most of the time, they
can be avoided and this will be discussed in the next
section.
Let P= {Xll1 Xl 2, ••• ,Xla } be one of the paths and
('YI, 'Y2, ••• ,'Yn) be one of the value assignments where
'Y i = 1 if i E {h, l2, .•. , la} and the other 'Y i values are
arbitrarily chosen. If there exists another path P' such
that P' = {Xhl1 Xh2' ••• ,Xht/} where Xh17 Xh2' •• · ' Xht/E
{Xl, X2, ••• ,xn } and Xhl = ... =XhfJ= 1 after the above
assignment, the path P' = {Xh17 Xh2' ••• , Xht/} is called
a sneak path.
The sneak path P' is actually a path with its variables
being assigned 1 in addition to the path P in which we
are interested. The test values assigned to the variables
of the path test P= {Xl17 Xh, ••• ,Xlal can detect stuck
type failures s-a-O or s-a-1 for each literal in the path.
For example, if one of the input signals is Xi ( EP) then
the test pattern derived from P can detect a s-a-O failure
at input Xi. If one of the input signals is Xi ( EP) and
its literal Xi appears in P, that is xiEP, then the test
pattern derived from P can detect a s-a-l failure at
input Xi. Note that this detect ability of the failures associated with the input Xi is under the assumption
Al\B
AA~
Conflict and sneak paths
In a graphic representation, every path on the graph
is assumed to ,be able to be actuated independently to
the other paths, but this assumption is not always
true in the case of combinational logic network
representations.
For example, if there is a variable on a path such
that the variable simultaneously completes one portion
of the path and opens another portion of the path,
that is, the variable x appears as both x and x in one
path, then no test path actually exists.
In the following theoretical discussion, theseproblems will be analyzed accurately.
Xl,
A path P= {Xll1 Xh, ••• ,Xlal is said to have a
conflict if there exists at least one Xi such that Xi E
{Xl, X2, ••• ,Xn }, Xli=Xi and Xlk=Xi for Xli' XlkE
i)
V
( ... ) AND (A,tlR B) AND ( •••
ii) C AND (A
pR
B) AND ( •••
nl
A
O
B
A
B
E
iii) ( . . pR ••
) AND
(A
PR
B) AND E
iv)
C AND (A
pR
B) AND E
Figure ll-OR operation in graphic form
Method of Test Generation
that there are no conflicts or sneak paths for any test
value assignment to the variables in the path. Apparently redundancy in the original logic network
causes sneak paths in the graph representation, and
these sneak paths reduce the detectability of failures
by the path tests.
This is discussed more precisely as follows: Let
P= {xzu XZ 2, .•• , xzal, where xzi(jE {I, ... , aD is a
literal in the path we are interested in and P' =
{Xhu Xh2' ••• Xh/3} (-~P) is a sneak path as defined previously. Let a subset P" be defined as P" = p n p' •
Then the test value assignment to the variables of
path P can at most detect stuck-type failures in the
input signals XZu XZ 2, .•• ,xziEP". The test pattern
cannot detect failures in XZi+!' .•. , XZa E P - P".
This is proved as follows:
If a path P is in the original graph, a sneak path P'
cannot be in the complement graph. Let P be in the
original graph corresponding to the logical network
function f and P' be in the complement graph corresponding to the complemented logical network function J. Then we can express f and! as follows:
f=XlI 'Xl2 .•• XZa+RI
!=Xhl. X h2' . . xh/3+R2
By sneak path definition Xlu Xl2, ••• Xl a , Xhl1 ••• Xh{J
are assigned 1, therefore f = 1 + RI = 1. But f = 1 contradicts ! = 1 + R2 = 1. So a path P being in the original
graph and the sneak path pI being in the complement
graph cannot exist. Similar arguments can be applied
to prove that a path P be in the complement graph and
a sneak path pI being in the original graph cannot
exist. So P and P' both must be in the original graph
corresponding to the Boolean function f or both in
the complement graph corresponding to the complemented function J.
First, assume that the path P and the sneak path
pI are in the graph, not including complement expression, corresponding to the original logic function f. If
all the variables in the path Pare ANDed together
the result is XlIXZ2Xl~ • • • Xla' This is a term of the Boolean
expression of the logic network function f after expansion but before simplification. Similarly for the
sneak path pI we get another term XhlXhz •• ,Xh{J for
the Boolean functionf. Letf=xlI .. . Xla+Xhl" ,xh{J+R.
Where R is the logic sum of the remaining terms of the
Boolean function f.
Since Xl l1 XZ 2, ••• ,xziEP" =pnp' , we can rearrange
the function f as follows:
According to the value assignment and sneak path
75
definitions, we assign 1 to Xl l1 XZ 2, • , Xla and Xhl1 • , Xh/3
for the variables corresponding to the path P. A test
with logic value assignment 1 to Xk can detect a s-a-O
failure at location Xk if the change of the logic value
from 1 to 0 will result in a change of the logic values
at the output. On the other hand a test with logic
value assignment 0 to Xk can detect a s-a-l failure at
location Xk if the change of the logic value from 0 to 1
will result in a change of the logic value at the output.
First consider the s-a-O failure for Xli where XliE P"
and XZi is positive. Under the value assignment scheme
xlr=l, xz 2 =1, . . . , xla=l, xhl=I, ••• and xh{J=I, also
R = O. If Xli stucks at 0 and R still remains at 0, this will
change the function value from 1 to O. This corresponds
to the change of the output of the combinational logic
network from 1 to O. If R contains such one term in the
form of sum of products, as XliXklXk2' • • Xky and Xkl =
Xk2= ••• =xky=l and Xli=O under the previous assignment, the stucking at 0 of XZi will change R from 0 to 1.
This keeps the output remain at 1 when the input Xli
stucks at O. Therefore, the test derived from the path
P cannot detect the s-a-O failure a Xli' This will not
occur when xZi is a one-sided variable. So the test can
detect the s-a-O failures for those positive one-sided
variables xljin P". For the variable,s Xli+l1 Xl i +2 , • • •
and Xla E P - P", the test cannot detect the failures.
Assume xjEP-P" is a positive variable and stucks at
O. The term XZ i + 1XZ i +2 • • • Xla becomes 0 but Xhi+lXhi+2' ••
Xh{J is still 1 under the same value assignment scheme.
Since all xi's E P" are assigned logical 1, the function
value still remains at 1 regardless of whether Xj E P - P"
is 0 or 1. So the test cannot detect the s-a-O failures for
any positive variable Xj in P - P".
Similar arguments can be applied for s-a-l failure
of Xi and its literal xiEP. Now we have only proven
those paths in the original graph which correspond
to the Boolean function f. Similar arguments can be
applied to those paths in the complement graph except
the function is J instead of f.
If P" = P n p' is an empty set, the test derived from
P cannot detect any failure. Thus this test is useless,
and such a path P is said to have a fatal sneak path P'.
Test generation
The PGM program generates a set of paths from
the arc descriptions of the combinational logic network.
These paths will be processed to produce a set of test
sequences to detect and locate the failures.
Let z be a Boolean function of Boolean variables
Xl, X2, ••• , Xn and expressed as z = z (Xl, X2, ••• , Xn) •
Without loss of generality, assume z is positive in
Xl, X2, ••• , Xi and negative in Xi+1, Xi+2, ••• , Xii that is,
76
Fall Joint Computer Conference, 1970
through Xi appear in uncomplemented form and
Xi+! through Xj appear in complemented form only. But
Z is both positive and negative in Xj+l, Xj+2, ••• , X n •
That is, both Xk and Xk ( j + 1 ~ k ~ n) appear in the irredundant disjunctive form of· z. For example, if
Z(Xl, X2, X3, X4) =XlX2+X2X3+X4 then Z is positive in Xl,
negative in X3 and X4 but either positive or negative in
X2. Let us define those variables Xl, X2, • • • , Xi and
Xi+l, ..• , Xj as one-sided variables and those variables
Xj+l, Xj+2, ••• , Xn as two-sided variables.
Suppose the PGM program produces paths PI,
P 2 , ••• , Pm from the arc description of the equation
Z = Z (Xl, X2, ••• , Xn). Consider only one path Pl. Let
PI be defined by a set of variables on the path as
PI = {Xll' Xh, ••• , Xlal,
where
Xl
Let Xl D Xlz, ••. ,Xla be defined as variables inside path
and other variables as variables outside path. For example, if we have Z=Z(Xl, X2, X3, X4) and PI = {Xl, X2},
then Xl and X2 are variables inside path and X3 and X4
are variables outside path.
If PI = {Xll1 Xl 2 , • • • , Xl a } is one of the paths produced
by PGM program from the arc descriptions of the
equation Z=Z(Xl, X2, ••• x n ), then one can get the test
from PI by the following procedure:
Application to ILLIAC IV PE control logic
The ILLIAC IV PE can be divided functionally into
three major portions, the data paths, the arithmetic
units such as the carry propagate adder, the barrel
switch, etc., and the control logic unit. Tests for the
data paths and arithmetic units have been generated
by other methods. l
To diagnose the ILLIAC IV PE completely, control
logic tests have been generated by an automatic test
generator system which uses the methods presented in
the previous sections.
The control logic test generator system consists of
the following subsystems:
1. Equation generation and simplification program
2. Transformation program to change Boolean
equations into arc descriptions
3. PGM program
4. Test generation program
a. Conflict checking
b. Value assignment to variables
c. Sneak path checking
They are combined into the system shown in Figure
12.
1. Set the positive variables inside path at 1 and
the negative variables inside path at O.
2. Check two-sided variables inside path. If Xi and
Xi appear in the path, conflict occurs. Stop. If
only positive form Xi of the two-sided variables
Xi appears in the path, set it at 1. Otherwise at
o.
3. Set the positive variables outside path at 0 and
negative variables outside path at 1.
4. Set the two-sided variables outside path at o.
5. Check for sneak paths.
6. If a sneak path exists, change one of the twosided variables. Go back to step 5. If the sneak
path still exists after checking all the combinations of the binary values of two-sided variables
outside path, check for the fatal sneak path.
7. If no fatal sneak path appears, the assignment
of the logic values is good. Therefore, a test is
determined.
When the PGM was applied to the ILLIAC IV PE
control logic, onlysix of 111 equations were discovered
to have path conflicts. Many of these conflicts may be
avoided by rearranging the input cards to the PGM
program, since the paths selected depend somewhat on
the ordering of the input equations.
(111 equations)
Pragram which drives
the "NOT" to the
innermost individual
variables
~-r--_...L...J (464 tests)
Transformation from
Boolean equations
into the Arc
descriptions
Test Generat ian
1. Conflict checking
2. Assignment of
the variables
3. Sneak path checking
Figure 12-Controllogic test generation system
Method of Test Generation
77
TABLE I-Value Assigned Tests for Combinational Logic Network of
Figure 6 Diagram
(THE OUTPUT SIGNAL IS PYE8-ACLDl)
SIGNAL NAMES
PATH NUMBERS
111111111122222222223333333333444
123456789012345678901234567890123456789012
FYE8-ACLCl
FYE98ABLFl
FYE98ABLIl
FYE98ASLIT
FYEEIA-HMT
FYEM329LIT
FYEM32-LOT
FYEM648L-T
FYEM649L-T
FYEMULTL9T
P4W-W02-1
P4W-WI0-l
PAW-WOl-l
P4W-W09-1
PAW-Wl6-1
PAW-W17-1
PBW-WOl-1
PBW-W09-1
PEXDI-L48L
PGC-I6-1
PMW-EI-0
P-CARRYH-L
P-FX-UFILH
P-EX-UF-LH
P-L-71-0
111111111101110111111111111111111111111011
111111001111111110111010100000000000000000
111110111111011111111100100000000000000000
111111110111111101111111111111111100011111
010110010000111010111001101111011101101011
101111111111111011100000000000010000000000
111111111110111111111111111111111111111101
111111111011101111111111111111111111100111
110001111111111111011110100001111111111111
011111111111111111111000000000010000000000
001000000000000000100110111111111111111111
100000000000000100001111111110111111111111
000010000000000000000110111111111111111111
000000000000000000010111111110111111111111
000001111111111011000000000100000100000000
111110000000000100111111110111110111111111
000100000000000000000110111111111111111111
010000000000000000000111111110111111111111
111111110111111101111000000000000001000000
000001010000100001000110100000000000000000
010110010001111010111111111111111111111101
111111110111111101111000000000000000100000
001111111111111011100111111110000011111111
110001111011101111011000000010000000001000
000000100000000000000110100000000000000000
THE FIRST 21 PATHS ARE FOR THE
OUTPUT "PYE8-ACLDl" WHICH CORRESPONDS TO THE ORIGINAL GRAPH.
THE REST OF THE PATHS ARE FOR'
THE COMPLEMENTARY OUTPUT "NOT
PYE8-ACLDl" WHICH CORRESPONDS
TO THE COMPLEMENTARY GRAPH.
Table I shows the variable assignment for the control
logic tests in Figure 6.
Test dictionaries for failure location can be generated
by a system similar to the test dictionary generator
system associated with the PGM program. The test
dictionary generation will be reported in a separate
paper.
CONCLUSION
The path generation method for test generation for
combinational logic has been discussed and an example
of the test generation system for ILLIAC IV PE control
logic has been presented.
Test generation by means of graph representation
of the Boolean functions of combinational logic networks has several advantages over other methods.
First, distinguishable faults are explicitly expressed as
nodes in the graph. A test which is derived from one
path in the graph can detect stuck-type failures, if no
sneak paths exist. The nodes in the graph correspond
to the failure locations and failure types (s-a-O or
s-a-l) in the combinational logic network.
Second, a complete set of tests for fault location can
easily be generated from the graph by the PGM program. If no conflicts or sneak paths exist in the set of
paths generated by the PGM, the corresponding set of
tests is sufficient for locating failures in the combinational logic network.
78
Fall Joint Computer Conference, 1970
This method is a powerful tool for testing tree structure logic networks. If the structure of a logic network
is not of the tree type, the conflicts may occur.
A method of checking for conflicts and sneak paths
has also been presented. This is used to determine the
validity of the tests for the combinational logic network.
Conflicts can easily be reduced by replacing tests or
rearranging of the PGM inputs after inspection of the
generated tests. It is noted tha t these conflicts are not a
result of our approach, but rather a property of the
network itself.
Generally, conflicts will be few in control logic networks because their structure is close to a pure tree
structure, and no sneak paths exist if there is no redundancy in a logical network.
ACKNOWLEDGMENT
The authors would like to thank Mr. L. Abel for his
enthusiastic discussion and our advisor,Professor D. L.
Slotnick.
This work was supported by the Advanced Research
Projects Agency as administered by the Rome Air
Development Center, under Contract No. US AF
30(602)4144.
REFERENCES
1 A B CARROLL M KATO Y KOGA
K NAEMURA
A method of diagnostic test generation
Proceedings of Spring Joint Computer Conference pp
221-228 1969
2 D B ARMSTRONG
On finding a nearly minimal set of fault detection tests for
combinational logic nets
IEEE Trans on Computers, Vol EC-15 No 1 pp 66-73
February 1966
3 J P ROTH W G BOURICIUS P R SCHNEIDER
Programmed algorithms· to compute tests to detect and distinguish between failures in logic circuits
IEEE Trans on Computers Vol EC-16 No 5 pp 567-580
October 1967
4 H Y CHANG
An algorithm for selecting an optimum set of diagnostic tests
IEEE Trans on Computers Vol EC-14 No 5 pp 706-711
October 1965
5 C V RAMAMOORTHY
A structural theory of machine diagnosis
Proceedings of Spring Joint Computer Conference pp
743-7561967
6 W H KAUTZ
Fault testing and diagnosis in combinational digital circuits
IEEE Trans on Computers Vol EC-17 pp 352-366 April
1968
7 D R SHERTZ
On the representation of digital faults
University of Illinois Coordinated Science Laboratory
Report R418 May 1969
The application of parity checks to an arithmetic control
by C. P. DISPARTE
Xerox Data Systems
EI Segundo, California
INTRODUCTION
Inactivity alarm.
As circuit costs go down and system complexity goes
up, the inclusion of more built-in error detection circuitry becomes attractive. l\1:ost of today's equipment
uses parity bits for detection of data transfer errors.
between units and within units. Error detection for
arithmetic data with product or residue type encoding
has been used to a limited extent. However, a particularly difficult area for error detection has been control
logic. When an error occurs in the control, the machine
is likely to assume a state where data is meaningless
and/ or recovery is impossible. Some presently known
methods of checking control logic are summarized below.
Checks the loss of timing or control signals.
Method of checking an arithmetic control
The application of parity checks for error detection
in an arithmetic control appears to have been first suggested in 1962 by D. J. Wheeler.2 He suggested the
application of a "parity check for the words of the store"
as an advantage of the fixed store control where parity
checks would be applied to each microinstruction word.
In a conventional type control, the method of applying
parity checks is similar provided that the parity bits are
introduced at the flow chart stage of the design. The
present method is applied to an Illiac II type arithmetic
control which is a conventional control rather than a
read only store control. The method gives single error
detection of the arithmetic control where errors are defined as stuck in "1" or "0".
Methods of checking control logic!
Sequential logic latch checking
A parity latch is added to a group of control latches
to insure proper parity. The state logic must be desjgned
such that there is no common hardware controlling the
change of different latches.
THE ILLIAC II
Checking with a sim.ple sequential circuit
The Illiac II which was built at the University of Illinois is composed of four major subsystems as shown in
Figure 1. The Executive Subsystem includes Advanced
Control, the Address Arithmetic Unit and a register
memory. The Arithmetic Subsystem contains Delayed
Control, the Link Mechanisms and the Arithmetic Unit.
The Core Memory Subsystem is the- main storage. The
Interplay Subsystem contains auxiliary storage, I/O
devices and the associated control logic.
A small auxiliary control is designed which serves as a
comparison model for the larger control being checked.
Using a special pattern detecting circuit
An auxiliary sequential machine is designed which
repeats a portion of the larger sequential machine's
states in parallel. This gives a check during part of the
cycle of the larger machine.
The Illiac I I arithmetic subsystem
Checking with an end code check
The arithmetic Subsystem of the Illiac II shown in
Figure 2 performs base 4 floating point arithmetic. The
input and output channels carry 52 bits in parallel.
A check on the control outputs is accumulated and
sampled at an end point.
79
80
Fall Joint Computer Conference, 1970
SPINDAC, a small delayed control
Core
Memory
Executive
Subs~m
4------ ---------_____ •
t
I
I
I
•
Arithmetic
Subsystem
- .........
- ................
-........
!,
I
........................
I
-....-
•
........
Interplay
CONTROL A6.TH - - - -
QA.TA A6.TH - - -
Figure l-ILLIAC II organization
The first 45 bits of the operand are interpreted as a fraction in the range -1:::; f < 1. The last 7 bits are interpreted as an integer base 4 exponent in the range:
-64:::;X<64. Both the fraction and the exponent have
a complement representation. The other input data
channel carries a six bit Delayed Control order which
specifies the operation performed by the Arithmetic
Subsystem;
The Arithmetic Subsystem is composed of three
principal units. The Arithmetic Unit (AU) contains the
computational logic and is divided into two maj or subunits as indicated. The Main Arithmetic Unit (MAU)
and the Exponent Arithmetic Unit (EAU) handle the
fractional and exponential calculations respectively.
The second principal unit of the subsystem contains the
Link Mechanism (LM) logic. This logic transmits commands from De]ayed Control to the Arithmetic Unit
(AU). It may further be divided into gate and selector
mechanisms and status memory elements. Delayed
Control is the third principal unit of the Arithme~ic
Subsystem. Delayed Control logic governs the data flow
in the AU via the LM.
The order being executed by the AU is held in the
Delayed Control register (DCR). A new order cannot be
transferred to DCR until the order presently held has
been decoded and initiated by Delayed Control. If the
order requires an initial operand, Advanced Control
(AC) determines whether Delayed Control has used the
operand presently held in FI(IN). If so, AC places the
new operand in IN; otherwise, it must wait. If the order
requires a terminal operand (i.e., a store order) AC
checks the contents of the OUT register before the store
order is completed.
Delayed Control is constructed with a kind of logic
known as "speed-independent". The theory of speed
independence holds that a speed independent logic array retains the same sequential properties regardless of
the relative operating speeds of its individual circuits. 3
The theory permits parallel operations while at the same
time precluding the occurrence of critical races .
A smaller version of Delayed Control called
SPINDAC (SPeed INDependent Arithmetic Control)
has been used as a model for the present study.
SPINDAC was designed by Swartwout4 to control a
subset of the Illiac II floating point arithmetic instructions. The relatively simple arithmetic unit which
SPINDAC controls performs thirteen arithmetic instructions including addition, multiplication, exponent
arithmetic, and four types of store orders. Iror the purposes of this study, SPINDAC has been divided into
eight subcontrols as shown in Figure 3. Each of the subcontrols has one or more states. The Add subcontrol,
for instance has five states Al through A5. In general,
there is one flip-flop in SPINDAC for each state. The
entire SPINDAC has 29 states.
The MAU, EAU, and LM
The essence of this description is due to Penhollow. 5
The Arithmetic Unit (AU) consists of the Main Arithmetic Unit (J\tIAU) and the Exponent Arithmetic Unit
(EAU). These two units operate concurrently, but are
physically and logically distinct. Both receive their
operands from the 52 bit IN register. The first 45
bits of this are interpreted as a fraction, -I:::;f < 1, and
is the l\1AU operand. The last 7 bits are interpreted as
~g~-+
________________________
5=2~its~
From
Advanced
Centro!
From
Advanced --Control
----..
Link
Mechanisms
4-
L ____ "- _______ ,
:
52 bits
F&~~T)--------------~--------------~
Figure 2-The arithmetic subsystem of the ILLIAC II
Application of Parity Checks
an exponent, - 64::; X < 64, and is the EAU operand.
The complete floating point operand contained by IN
may be expressed as p=f·4x • Floating point results
placed in OUT have the same form. Both f and x are
in complement representation.
The block diagram of the Illiac II MAU is shown in
Figure 4. Registers A, M, Q and R each have 46 bits,
while S has 48 bits. Since the two adders yield sums in
base 4 stored carry representation, A and S also contain
23 and 24 stored carry bits respectively.
81
To FO(OUT)
via RE5gFO
From
F1(iN)
F1gMEM
TheMAU
During the decode step of every Delayed Control
order, the gate FlgMEM transfers the first 45 bits of
IN to M even though the order does not use an initial
operand. The results of the previous operation are generally held in A and Q which represent the primary rank
of the double length accumulator. The Sand R registers
form the secondary rank of the double length accumulator which usually holds an intermediate result at the end
of an operation. During the store step of every store
order, the RESgRO gate transfers a modified copy of
R to the OUT register.
The two adders shown in Figure 4 are composed of
base 4 adder modules. The A adder has the contents of
the A register as one input and the output of the MsA
selector as the other. In either case, the selector output
in two's complement representation is added to the
stored carry representation held in A or S. A subtraction
is accomplished by causing 1\1 to appear at the selector
output and then adding an extra bit in the 44th position.
The selector mechanisms have memory. Once a particular selector setting has been chosen by Delayed Con-
Exponent
ADD
Arithmetic
Subcontrol SUBCONlROL
E1-E2
1
1
Clear.Ad:l
Subcontrol
mrmalize
ubcontrol
A1-A5
81-82
N1-N3
J
1
Isu~~~r~11
Su
~~01
!
I
51-56
M1-M8
ICorTeCt
Overflow
Detect Zero
Subcontrol
K1-K2
J-1
Decode II
Subcontrol
D1
I
Figure 3-SPINDAC (SPeed INDependent Arithmetic Control)
Figure 4-The ILLIAC II main arithmetic unit
trol it remains in effect until a new setting is made.
The settings shown in Figure 4 are easily interpreted,
provided the outputs of the A and S adders are used in
place of the register outputs.
The gate mechanisms do not have memory, so they
must be activated each time the contents of the associated registers are changed. If the gate is not activated, the register simply retains its old contents regardless of the bit configuration appearing at its inputs.
The EAU
The block diagram of the Illiac II EAU is shown in
Figure 5. The EA, ES, EM and E registers each contain
8 bits. The EAU does arithmetic modulo 256. An 8 bit
adder (D-adder) with an optional carry into the Oth
position provides the capability of doing exponent arithmetic and counting. It accepts the outputs of the EA
register and the sD selector as inputs, and yields a sum,
D, which can be placed in ES via gES or in E via DgE.
The selector sEA controls the input to EA via gEA.
The gate mechanism EMgE controls the input to E.
During the decode step the contents of Fl are transmitted to EM via FlgMEM. At the end of an operation the exponent of the result is left in E.
The EAU decoder is a large block of logic whose inputs are the outputs of the D-adder. Its purpose is to
detect specific values and ranges of the adder output.
Knowledge of these values is used in the execution of the
floating add instruction. Detection of whether the output is inside or outside the range -64::;x<64 is also
accomplished at this point. Since knowledge of the previous range or value of d must be remembered during
the time the inputs to the adder are changed, gES or
DgE will gate the outputs of the EAU decoder into a
82
Fall Joint Computer Conference, 1970
SPINDAC flow chart
A partial flow chart for the SPINDAC Add sequence
is shown in Figure 6. The actions in two of the five states
A3 and A4 are indicated. Inside each of the boxes are
the control outputs in the form of gating and selector
outputs. On the lines leading to each box are the conditional inputs in the form of decoder, status element and
selector outputs. They determine which of the control
outputs is to be energized. The signals in the boxes on
the center line preceded by ALL are always energized
when in that state.
The action effected by states A3 and A4 is the alignment of operands for floating point addition and subtraction. Rather than attempting to explain each of the
symbols in the flow chart, only the simple case for equal
exponents (i.e., no alignment required) will be explained.
to Delayed Control
MgE
sD
EMsD
EMsD
OsO
-2s0
2sD
-22sD
F1gMEM
Figure 5-The ILLIAC II exponent arithmetic unit
The Equal Exponent Case
register cal1ed ED. The memory elements of this register
are named according to the range of d they represent.
The Link Mechanisms (LM) include gates, selector
mechanisms, and control status memory elements. Delayed control directs the data flow and processing in the
Arithmetic Unit (AU) via the LM. Delayed Control
requests may determine the state of the LM directly or
indirectly through the outputs of decoders. The inputs
to these decoders may be the outputs of registers, adders,
or status memory elements. Selector mechanism and
status memory elements remember their present state.
The outputs of certain status memory elements influence the branching of Delayed Control. The setting
of one or more of these elements during the present
control step partial1y determines the sequence of future
control steps.
In Figure 7 the contents of A and Q are first right
shifted (74: AQsSR) then left shifted (4SRsAQ) so that
AQ remains with its original unshifted contents. The
exponent is gated into ES at A3 by gES in the ALL box.
The selector (with memory) El\1sD was initially set in
state Al (not shown) which sensitizes this path. In
state A4, the exponent is passed back to EA via gEA
and ESsEA. El\1gE gates the addend (subtrahend)
exponent to E. OMsS in A3 effects only a transfer.
Kl\1sA is always the final step before leaving the A3A4 loop. This is to assimilate carries which have been
in base 4 stored carry representation until the final pass
through the loop. XA controls the exit from the loop
(exit if XA= 1). The least significant carry into the
adder is cleared by C. All of these control signals are dependent on the various outputs of the exponent decoders such as d> 0, es = 2 etc. The actions 2sD and
es>O)
(d>O)
A3
to
A5
A4
'roml
A2 -__-1~A~LLL-__~~~~~y+~AL~L__~~~~~~~~to
• • A
A
A5
(clone)
hv(es>0)
(cr)vO)
Figure 6-SPINDAC add sequence partial flow chart
AOs
Figure 7-Partial add sequence for equal exponents
Application of Parity Checks
12 (setting status element 12) are meaningless for the case
of equal exponents.
EMsD,CR,gP3
(es>O)
Speed-independent hardware
r---------..
ALL
2sD,ByCR,gP2
--------------_1
(es> 2)
The logic design procedure used for Delayed Control
(and SPINDAC) employs Basic Logic Diagrams
(BLD's) developed by Swartwout and others at the
University of Illinois. 6, 7 A digest of this work as well as
the design for a new error checking BLD is in the Appendix.
In the logic design procedure, each state of the flow
chart such as A3 or A5 is associated with a control point
(CP). The CP in tum has some associated logic and a
flip-flop. Using this terminology, it can be said that the
Add sequence has five control points (five states) and
the entire SPINDAC control has 29 CP's. Using this
design procedure, the entire SPINDAC control can be
mechanized with 27 flip-flops and 346 gates.
83
-2sD, ByC R, gP1
gA,gQ,gEA,ESsEA,gPO
(done)
(done)
.n.(es>0)
Figure 9-Application of parity checks to simplified control
point A4
THE APPLICATION OF PARITY CHECKS
A general arithmetic control moAel is shown in Figure
8. Here a bit pattern at the output of the control represents a pattern of the gating and selector signals transmitted to the arithmetic unit. The pattern will be a function of: (1) the instruction presently being executed,
(2) the conditional inputs and (3) the current step of the
control. The control must be protected against two types
of errors: first, an erroneous bit pattern at the outputs,
and second, an incorrect sequence of the internal states
of the control. In a "speed-independent" control, the
internal states of the control change one memory element at a time. In most practical designs, this means
that the internal states of the control must be encoded
with a high degree of redundancy. One systematic way
of achieving a speed independent control, for instance,
Conditional
Inputs
~
Encoded {
Instruction
Being
Executed
Figure 8-An arithmetic control model
shifts the single active control point down a shift
register. If any two bits (control points) are true at the
same time, the control is known to be in an incorrect
state. A method is suggested here of applying one or
more parity check symbols to the outputs of the speedindependent control so that an erroneous output bit
pattern may be easily detected. If the control action
with faulty outputs can be detected before the effect
has been propagated, a replacement control may be
switched in or maintenance may be initiated.
Method
The method of applying single error detection parity
checks is explained with reference to simplified
SPINDAC control point A4 in Figure 9. In the flow
chart, some boxes are entered conditionally. These
conditional boxes are the ones which have gating or
selector outputs which are energized only if the appropriate conditions are true. The signals gPO, gP1, gP2,
and gP3 are gating parity checks which have been chosen
according to the following three rules:
1. If a conditional box has an even number of gating and/or selector signals, .add an odd parity
checking gate to each box (gP1, gP2 and gP3
in the example).
2. If a conditional box has an odd number of gating
and/ or selector signals, no parity checking gates
are added.
84
Fall Joint Computer Conference, 1970
RATIO OF
OfEO6
51 56 51 '>1
5H 51 58 5B
59 5~ ~9 59
~o 00
ao 00
~o 00
~o 00
~o 00
ao 00
~O 00
~O 00
dO OC
lB
18
18
18
18
18
1B
18
lB
BATCH
'lA 35 004C 04
4~
46 5A OOJO 00
~O
dO 00 SA SA
00
00
00
00
00
00
00
CO
00
~9
14 14 14
OA 01 OA
00 00 00
4~ Uti OH
30 08 liS
Jl 08 08
12 OY UH ~o
4M 08 08 dO
1~
0000
0000
0000
0000
00:)0
tlOOO
~6
UO?O
46 5~ 0000
46 59 0000
~9
1f'
OA 11 11 J4 l ' l ' 1F IF
OJ
OJ
OJ
OJ
OJ
03
OJ
OJ
OJ
52
5J
54
55
56
57
1P
1P
11
1P
1P
OA
HO
UO
00
00
80
HO
dO
24 0000
2~ Dono
26 0000
21 0000
2H 0000
24 0000
2A nooo
7B 0000
2C 0000
)0
J1
Jl
]]
jll
BATClI
BATCH
l'
1P
~o
]2
]2
J2
J2
12
12
12
12
32
J2
12
.12
12
J2
p9
~9
J4 O'j ,)8 oil) OA 1"1 11 J4 l'
32
12
32
J2
J2
004C
G04C
004C
004C
004C
n04e
n04C
D04e
0()4C
004C
~9
11
1F
1F
1F
l'
11
l'
1F
01
18 ~9 ~9 ~~ ~9 ~9
18 ~q 59 ~9 ~9 ~9
1B ~9 ~9 ~9 ~9 ~9
lH ~9 ~9 ~9 ~9 ~9
18 ~~ ~9 ~9 ~9 ~9
1B ~q ~9 ~9 ~9 ~9
1B ~9 ~9 ~9 ~9 ~9
1C 1J 1J 1 J 1 J 1J
lD 2~ 14 14 14 1 ..
1£ 14 1~ 1~ 1~ 1~
n4
04
04
04
04
01
07
01
01
07
17
01
07
01
1
P
R
J
4
T
rNTERACTIVE 10 )') 004C
INTERACTIVE J1 Of 004C
INTP.R,H:'!'[vF J2 05 !)04C
INT~RhCTrv~ 1] 0] n04e
INTERACTIVE IU OR 004C
40
41
42
41
44
INTER~crIVF 45
INTEPACTIVR 116
INTERACTIV~ 47
INTF.!HcrrvE 48
INTERJCTIVE 49
J
P
R
J
J
OJ 0000 01 00 00 00 00 00 01 16 16 21 00 00 00 00
01 UOOO 02 )4 34 OS 06 ~O O~ 17 11 J .. 1F IF l ' 11'
1F 00 nouc 04 23 '3 1F 0000 UU J4 t4 OH 08
WR rTE
LOGOFF
LOr-ON
BULK 1-0
SA Tr. ff
LEV~L
Q
5
CO fJ4
SYSOP~fi 0
TNTERACTIVE 01 04
T NTF-RACT IV P OJ. )4
INTERAC1'IV~ I) I 04
INTRRAC'l'IVE 04 all
INTFlnCTIV": 0') 011
IN T ER ACT IV ~ 06 04
INTERACTIVE 07 04
INTEUCTIVE 08 04
I NT ER ACT IV P. 09 04
SULK 1-0
OA 04
OB 1A
BATCH
OC 1A
BATCH
01) 1A
tUTCIi
OE 1A
SlTCK
OF 1A
BATCR
10 1A
aATCR
11 H
SATCK
llH
8ATCR
1 1 1.\
aATCR
LOGON
H v2
1, {I/~
LOGOFF
THIRD LEVEL BATCH
SECOND
P
R
I
T
F
V
~J
44
46 46
41 41
4H 48
51
52
~O
~1
~1
~1
52
~2
~3
~4
52
53
~4
~4
~~
~4
~5
~fi
5~
50
~J
~O
5]
~O
~O
IN'l'BLOCK
Figure 4-Schedule table T5-the best TSSj360 release 5.01 table
~A
1F
1F
1F
IF
1f
U' 1F· IF 11
49
49
2C
1F
1F
1P
1F
IF
1F
1F
1F
IF
1F
lF
1F
l'
l'
IF
1F
1F
1F
1F
1F
1F
1F
1F
1F
IF
1F
1P
1F
11
IF
IF
It
U'
1F
1F
1F
~o
~o
SO
~O
~o
4~
4'1
18
~1
~1
~1
~1
~1
1~
~2
~2
~2
~I.
~l
18 ~J 5] 5J
18 ~4 ~4 ~4
18 ~'> ~~ ~~
18 56 ,6 56
1B ~1 ~1 ~I
lB ~S 5M 5H
18 ~'I ~9 59
~o
53 ~3
54 ,4
"
~~
~6
5&
~1
~/
~8 58
59 59
'>0 ,0 50
~u
Scheduling TSS/360 for Responsiveness
SET
HOLDI'fG
INTERLOCK
SET
PliE1UDICE
POR
INT~RLOCK
SET
p
P
P
P
L
C
It
R
R
R
R
J
1
J
J
J
I.
J
1&
17
17
11
I.J 00 00 00
2 .. 11' 11' 11'
I. .. 11' 11' 11'
2 .. 11' 11' 11'
l .. 11' 11' 11'
1.4 11' 11' 11'
1 .. 11' 11' 11'
1.4 11' 11' 11'
211 11' 11' 11'
2 .. 11' 11' 11'
2l 01 OAOl
27 OB DB DB
21 OC DC DC
H OD 00 OD
U OJ! OJ! DB
21 or OF 01'
21 10 10 10
II 11 11 11
21 12 12 12
21 lJ 13 13
21 , .. 111 14
lO 15 15 15
00
11'
11'
11'
11'
11'
11'
11'
11'
11'
01
OB
DC
00
OJ!
I.J 00 00
2 .. 11' lP
I.~ IF IF
I.b lP 11'
22 lA 11
21 lB 18
28 lC lC
21 , .. , ..
lO 15 15
00
lP
IF
11'
11
lB
lC
, ..
15
00
11'
11'
lP
11
18
lC
, ..
15
1F 01 0013 01 2J F1' lP 0000 00 11' 11' O~ 08 00 OA 11 11 24 lP lP
lP
lV
15
14
01.
00
11'
11'
11'
OB
lJ
15
, ..
01
00
lP
11'
11'
08
lJ
3~T
I'iT~R'CTIVE
:,rAP'!'I!!G
20
10
10
10
10
10
10
10
10
10
20
10
10
10
10
10
10
10
10
10
20
20
PP
PF
1'1'
1'1'
Fl'
P'1'
1'1'
P'1'
1'1'
1'1'
P'1'
1'1'
20
10
20
10
20
Q1 10
01 10
~Ot3 01 20
0013 01 20
F1'
1'1'
FP
PF
FF
FF
PI'
FP
PP
LOG01'~
01
01
01
01
01
01
01
01
01
01
01
01
01
01
01
01
01
01
01
01
02
02
SYSOPEBO
INTER'CTJV!
TNTI!RICTIV!
IlITERACTIVE
SUL!{ 1-0
BITCR
BITC!f
LOGOIl
LOG01'1'
16
17
18
19
11
1B
lC
lD
lE
00
02
02
01
0)
04
04
01
03
0013
0013
0013
0013
0013
001]
001J
01
01
01
01
01
"RIT!
I!
0011
0013
0013
0013
0013
0011
00 13
0013
0013
01
01
01
01
01
01
01
01
20
20
20
20
10
20
10
10
)0
29 18 0026
21 03 0026
IB 18 0026
2C 11 002b
20 16 0011
2E 15 0013
2F 14 0016
'0 14 002~
it '" !I01"·
12 14 001J
n~
10
18
20
10
40
20
21
22
23
2 ..
IIITERACTIV~ 25
I NTERAC1' IV,. 26
27
81TCH
28
BITCH
06
06
06
06
06
06
06
06
06
00
01
02
01
04
05
06
07
OS
09
01
OB
rr OC
"1' 00
1'1' OE
1'1' or
1'1' 10
1'1' 11
1'1' 12
PI' 13
P'P 111
1'1' 15
0000
0000
0000
0000
0000
0000
0000
0000
0000
0000
0000
0121'
0121'
012,.
0121'
012'
0121'
012'
012'
0121'
0000
0000
D T I!
ESP
T
II
I
II
L
R
I
I
TilE
I
D
I
I
""
pp 0
T
T
T
00
00
00
00
00
00
00
00
00
00
00
01
01
01
01
01
01
01
01
00
00
00
16 0121' 00
17 0121' 00
1~ 0121' 00
19 OllP 00
11 012P 00
18 0111' 00
lC 011P 00
lD 0121' 00
lE 0121' 00
20
21
22
21
2.
25
26
21
PF
PF
PP
F1'
PP
~O PF
10 PP
10 PP
29
21
2B
2C
20
2E
2F
11
00 00 00
117 51 3D
117 51 3D
.. 7 51 30
In 51 30
47 51 JD
.. 7 51 3D
.7 51 ]D
47 51 30
.. 7 51 3D
01 01 01
IIC 35 35
4C 35 35
IIC 3') 35
I&C 35 35
IIC 35 35
I&C 35 35
"C 35 35
IIC 35 35
I&C 35 35
, .. , .. 111
15 15 15
00
08
08
08
08
08
08
08
08
08
01
OB
OC
00
OE
OF
10
11
12
13
, ..
15
00 16 00 00
28 11 Q~ 00
l8 1~ 08 00
2C 19 08 00
01 11 01 00
"c 35 18 UB 00
35 ]& lC 13 00
, .. 14 lD , .. 00
15 15 lE 1~ 00
01 16 1&
01 11 17
01 18 18
01. 19 19
01 lilA
01. lB lB
01 lC lc
01 lD lD
Oil! lE
0000
08
0000
02
0000
02
0000
01
0000
01
ooal
02
0000
01
0000
01 110' f f 11 0000
!Il 110 PF 32 0000
00
13
00
00
00
l3
2J
l3
l3
21
41
21.
2P
JO
31
liB
.. I
""
49
28
19
2C
lD
2E
32
28
2C
I.D
lD
08
08
08
08
08
08
08
18
00
80
00
00
00
00
80
80
Oil IlO
08 80
01
01
01
01
01
01
01
01
01.
01
11
18
18
19
19
19
19
19
19
19
11
18
18
19
19
19
19
19
'"
19
JJ 0121'
1 .. 0121'
0121'
Oll'
012P
012F
J" OllP
11 812F
3B 0121'
lr 012'
00
lJ
00
00
00
00
H
2J
21
13
34
4C
J3
39
3l
3B
50
"P
liE
.. E
]5
JJ
3b
31
38
3C
35
J6
34
3J
39
11
3B
3C
35
J6
J7 11
31 18
J9
II
J8
lC
JI)
JI
J8
3C
'4 00
80
00
00
00
00
ao
00
80
80
01
01
0&
01
01
01
01
01
01
01
18
lB
1B
lC
lC
lC
lC
lC
lC
lC
18
18
1B
lC
1C
1C
lC
lC
lC
1C
H
21
l"I
28
0121'
012P
011P
0121'
012F
012F
0121'
012'
012P
0121'
00
13
00
00
00
00
23
23
2J
21
21
41
21
21'
30
31
29
2B
2C
2D
lB
28
2C
20
2E
32
2C
2D
2E
21!
3E
lD
"3
....
.. 5
lib
3P
"0
41
"2
08
08
08
08
08
08
08
08
08
08
01
01
01
0&
01
01
OA
0&
01
01
11
11
18
19
19
19
18
19
19
19
11
11
18
19
19
19
18
19
19
19
lq
211
25
26
2&
08 00 08 11
08 80 08 11
08 00 0& 19
O~ 00 0& 18
08 00 0& 18
2~
ao
3D
3D
lP
40
41
112
J1'
40
111
III
1'1'
pr
P1'
SHRINKIN~
.. 7
liB
119
III
48
01
01
17
16
15
0026
0026
0026
0026
0026
08
oa
10
20
18
1'1'
pF
F1'
FF
1'P
III
.. 8
4"
41
.. 8
0000
0000
0000
0000
0000
00
13
00
00
00
48
.. 1
CIA
48
III
29
29
2C
28
29
1D
3D
40
JF
lE
,)HRl!IKING
DELAYING
SIIRINKING
5HR INK IN:>
SHRI!lKING
4C
liD
4E
liP
50
13
11
13
,.
10
0026 10 08
0016 10 08
11 JC
0016 02 20
0026 09 18
F1'
1'1'
1'1'
FF
P1'
IIC 0121'
40011'
.. E 0121'
4P 01l1'
SO 012F
00
21
00
00
00
.. 0
QC
111'
SO
11=
J]
31
37
3&
35
"D .. 0
IIC .. 0
Jl !A
J9 J9
34 14
1)1)1~
11
lB
1B
lB
lB
lB
lB
lB
lB
18
10
lE
n
1"1
11
17
11
17
lA
lB
1B
lB
lB
lB
lB
lB
lB
lB
10
11
15
14
OA
00
08
08
08
DB
13
III
.. 4
45
46
41
11
H
17
11
15
lQ
01
00
3D
28 30
20 1P
j j 35 27
33 J~ 26
]0
3E
lP
QO
.. ,
42
IIJ
4 ..
45
116
DELATIN!,;
,.ROIIIlIG
GROIiING
GROIiING
GROiltNG
DELATING
DELATING
DELUING
JELA YIKG
n
15
, ..
OA
00
2B
FP
1'1'
PI'
rl'
'I'
pp
3D
JE
11'
40
41
lb
17
,.,
11
11
15
, ..
01
00
47
41
2B
10
10
20
10
.. 0
.. 0
20
30
.. 0
110
3d
1'1
JA
JIl
)C
OA
01
01
01
01
OA
01
01
01
01
01
01
01
01
01
01
01
01
0&
01
01
01
C
2J
21
23
01
2J
23
2J
23
23
OS 0026 01
DB 0026 01
1~ 0011 01
11 0010 01
16 000 .. 01
15 000 .. 01
14 OOll 01
111 0010 01
14 000" 01
14 000 .. 01
31
00
8D
80
80
60
tiO
80
80
80
80
00
80
80
80
80
80
60
80
80
80
00
80
00
.. 1
QB
"I
01
1'F
1'1'
FI'
FF
t'1'
F'
1'1'
PF
1'1'
Ft'
U
311
)'}
16
RP"
CR R
0000
0000
0000
0000
0000
0000
0000
0121'
012P
at
PI'
1'1'
1'1'
1'1'
1'1'
1'1'
PI'
P1'
PI'
E
lJ 002" Ud 10
11 0026 08 18
lC 002& 02 20
ta 0016 02 10
1& DOll 01 "0
1'1 ~Oll 01 "0
11. 0026 01 20
11 0026 01 30
1A 0011 01 40
11 0011 01 .. 0
SHR!!IK ING
LO)PI'IG
DELAYING
B1'EPACTIYE SHRI!lKING
~Rr
SHRINKING
~G
X
0026
0010
0010
0010
0010
0010
0010
0010
0010
0010
0026
0013
0013
0013
Don
0013
0013
0013
0013
0013
0026
0026
';ROIII~G
'H1'
1
E
05
lA
18
18
18
18
18
18
19
19
0 ..
10
1D
10
lD
1D
lD
lD
10
lD
03
0 ..
DELHING
A.lITT
5
D
00
01
02
03
0"
05
06
07
08
09
01
OB
DC
00
OE
01'
10
11
12
11
, ..
15
IITlRACT.IVE
t1tTERACl'IVE
IITERICTI'E
TRTF.RACTIYF.
IIITP.RACTIVE
INTERICTI'E
IITlRACTIf1!
INTERICT!'"
IITERlCTIYP.
BULl{ 1-0
B1TCH
BATCR
BlTCR
BATCR
BATCR
BlTCR
BITCR
BITCR
BITCR
LOGON
';!lOIII'iG
DELAYING
GROIiING
GROIiING
G.BOilING
GROIiING
DELAYING
DELATING
JELlYT NG
JELlYI N!,;
RATSH
1/
•
L
~!lOIIT!fG
SET
C
R
!>ELlYIN::
DELI Y'I !f,;
DELlYI MG
Lv)"T NG
11
T
L
GROIiING
Lo')::>I'IG
llELAYIIG
GROIII'IG
TNT-P\CTIVE GROWING
GBOIII'lG
:lsr
II
C
H
L
LOG01'P
LOGOI
BULK 1-0
SYSOPERO
IlIT!PlCTIV E
WAIT! NG
LOO!'!
L
L
P I
"
I I U II
X X L T
oU
SYSOP~RO
ST18TIIG
H
I
L
P T
EllS
V I
V
P. 0 I
10
10
01
02
08
1'1'
3,}
36
17
38
60
80
80
80
00
Oil!
01 1D
OA 1&
01 16
01 11
~O OA 18
~O 01 19
80 01 18
80 01 lC
til
00
80
00
00
00
00
80
80
80
80
00
80
00
00
dO
08
08
01
01
01
lB
lB
lC
1C
18
lE
lD
11
16
11
18
19
18
lc
1.0
l~
1.1 , ..
21. 01
23 00
24 lP
2~ 11'
26 lP
l7 08
28 13
15
14
OA
00
11'
lP
11'
08
13
or
10
11
12
13
, ..
15
l" 11' 11' lP lP
l~
11'
11'
11'
11'
11'
1P
lP
.!b 1F
2b 11'
11'
IF
11'
11'
11'
11'
IF
11'
11'
11'
lP
IF
11'
11'
11'
1P
11'
lP
11'
11'
IF
lP
11'
lP
11
11'
11'
JII
311
J9
31
JB
3C
J9
JA
JB
JC
J4
JII
39
J&
JB
JC
39
JI
J8
JC
J4
3 ..
J9
J&
3B
3C
J9
JI
JB
JC
J"
JII
39
38
3C
lP
11'
lP
11'
11'
11'
2&
26
26
IF
11'
IF
11'
11'
lP
IF
11'
lP
IF
11'
11'
lP
11'
lP'
lP
11
lP
11'
11'
11'
11'
11'
lP
11'
11'
lP
"
"
11'
11'
11'
11'
11
11
19
18
18
2"
2Q
2b
25
25
11'
11'
1F
11'
11'
11'
11'
11'
11'
lP
IF
11'
1P
11'
11'
11'
11'
11'
11'
11'
lB
18
1C
18
lB
21 .. D
21 .. D
l8 16E
21 .. ,
1.1 50
4D
.. D
.. E
4P
50
.. D
.. D
Il£
Qp
50
.. D
liD
II!
.. P
50
25
I.b
i6
16
lb
lb
l8
211
28
III
2~
I.Il
l&
:i5
11'
Jl
J9
J1
JB
3C
IIITERACl'I'I E !>1 11 0008 01 20 FF 51 0000 00 28 '>2 JP Oil 00 01 18 llf i5 tF ,,. 11' 11'
INT!RICTIV~ ~2 16 0006 11 30 F1' 52 OODU 00 2C 53 40 08 00 01 19 19 l6 11' 1F lP 11'
INTERACTIVE 53 15 0004 01 110 1'1' 51 0000 00 2C 2D 40 08 00 01 19 19 2& 1P 1P lP lP
Figure 5-Schedule table T47-The table in use when we first ran without LOS
105
106
Fall Joint Computer Conference, 1970
crossing the 20 mark and building rapidly. The
average delay during the RUNOFF between
522 lines of type-out was 3.4 seconds. This
included four unusually high delays of 71.6,
85.4, 87 and 117.1 seconds. It turns out that
these unusual delays occurred because of a high
level of simultaneous load. I was the chief perpetrator of this load and was thus hoisted on
my own petard. I was doing a virtual memory
sort over 2.5 million bytes of data during the
interval of time when the four large delays
occurred. This table still had its weak moments.
This, however, was the only cloud on a perfect afternoon. No other user complained.
6. One user was on with an 1130-2250 doing
algebraic symbol manipulation with LISP.
7. Three users were on all afternoon using a medical
application program.
8. Two users were on editing using the REDIT
command with a 2741 for input and a 2260
scope for output. One of these two was the high
success story of the day .. He was on from 1 :08
until 2 :55 p.m. During this time he executed
622 editing commands. This was an average
interaction time of 10 seconds. This includes
type-in time, processing time, think time and
display time. And he is not a touch typist!
He averaged 5.1 seconds to respond to TSSj
360 with each new command. TSSj360, in turn,
averaged 4.3 seconds to process his request,
change the display and then open his 2741
keyboard for the next request. This includes
a single high peak of 104 seconds during my
2.5 million byte sort, similar to the RUNOFF
delays.
9. The remainder of the users were in various
stages of editing, compiling, executing, debugging, abending, and other normal operations.
Most of the users were on the system for one
or more hours of consecutive use that day.
10. Ninety per cent of the compilations completed
in less than one minute that afternoon.
11. To compound the issue, we were running with
what we considered to be a critically low amount
of permanent 2314 disk space available on that
day. There were between 4,000 and 5,500 pages
of public storage available out of a possible
48,000 pages, of on-line public storage. Thus
I assume higher than normal delays due to disk
seeking existed during this day.
12. The most quantitative evidence I can offer
from the contribution of the balanced core time
and working set size concepts was obtained
from the Level Usage Counters.
a. Of all task dispatches, 89 per cent required
less than 32 pages.
b. Ten per cent required between 32 and 48
pages. This could be even lower if the assumption is made that this simply reflects a
working set change and not a working set
size change.
c. The remaining one per cent of all dispatches
were for up to 64 pages.
d. Breaking this down by sets of table levels,
there were:
Starting set
Looping set
Batch
Holding interlocks
Waiting for interlocks
AWAIT
BULKIO
SYSTElV[OPERATOR
LOGON
LOGOFF
28 percent
30 percent
4 percent
5 percent
2 percent
5 percent
10 percent
5 percent
6 percent
5 percent
13. Since the BCU has not been available SInce
December 20, 1969, there were no BCU measurements made that day.
14. The table in use on that day was T47 (Figure
5), which is very similar to T48 (Figure 6). T48
was created to reduce the impact on other users
of people doing in core sorts of several million
bytes on a computer which only allocates them
several thousand.
Changes in indicative programs
The programs discussed here exhibit to a marked
degree improvements which are present to a lesser
degree in all programs. They are:
1. A tutoring program, using a 2260 display with a
2741 for some input formerly had the following
property:
If you asked it a question whose answer was
unknown it displayed a message to that effect.
Then after a few seconds the screen would change
to let you choose what to do next.
Once the first new table was put in use, the
first message was usually not seen by most
people. This was because the old normal system
delay no longer existed. The program's author
had to put in a PAUSE after the first message
to allow it to be read.
2. When the first new table was put into daily use,
only one user was slowed down. He was using
Scheduling TSS/360 for Responsiveness
L
I
V
I
L
ST1RTJlIG
SET
HOLDING
INTERLO'CK
SET
P
T
R
S
0.U
"A
"I
I
V
1
X
X
o A
H
C
B
L
T
R
P
A
U
II
R
L T
S I
D
I
X
D T
I
S
II
P
T
W
L
E
R
1
T
H
I
I
D
1
II
1
I
I
T
T
SYSOPIBO
IHTER1CTIYE
IRTERlCTlYI
IHTER1CTIYI
IRTP.R1CTIYE
IHTER1CTIYI
fIITED1CTIYF.
IRTIRlCTIYE
IHTIR1CTI'E
IHTIUCfIYE
BULK 1-0
BATCH
BITCH
BITCH
B1TCR
BITCH
BATCH
BITCH
BITCH
BlTCR
LOGOH
LOGOFF
00
01
02
03
0 ..
OS
0&
0'7
09
09
0'1
OB
DC
DO
OE
or
10
11
12
OS 0026
18 0020
18 0020
18 0020
HI.0020
18 0020
18 0'020
18 0'020
18 00'20
18 0020
011 00'26
lD 0011
10 0'0'13
lD 0013
lD 0013
10 0013
10 DOll
lD 0'013
10 0013
13 lD 001J
14 03 0026
15 Olt 0026
01 20
01 10
01 10
01 10
01 10
01 10
01 10
01 10'
01 10
0'1 10'
0'1 20'
01 10
01 10
0'1 10
01 10
01 10
01 10
01 10
01 10
0110
02 20
02 20
PP 00 0000
FF 01 0000
FP 02 0000
pr 01 0000
pr 0 .. 0000
FF 05 0000
FF 06 0000
FP 01 0000
FP 08 DODO
FF 0'9 0'0'00
FF 0'1 O'O'!)O'
FF DB 012r
FF DC 012r
FF OD D12r
FF DE 012F
rF OF 012F
FF 10' 012F
FF 11 012F
FP 12 012F
PF 11 012F
FF , .. 00'00
FF 15 0000
00
00
00
00
00
00
00'
DO
00
00
DO
FE
FE
FE
FE
FI
FE
FI
00
00
00 00 00 00
21 51 10 OK
21 51 10 OK
2~ 51 lD 08
21 51 JD OK
21 51 10 08
21 51 10 011
21 51 10 011
21 51 lD 0'11
21 51 10 OK
01 0'1 01 01
"C 15 15 OB
4C 15 15 DC
4C 15.15 OD
..C l!» 35 DE
4C 15 15 DF
4C 15 J5 10
4C 15 J!» 11
4C 15 J5 12
lie 151513
111 lit 14 14
15 15 15 1!»
SYSOPERO
IlITIR1CTIYE
IN'l'ER1CTIVP.
INTERACTIVE
RULK 1-0
BATCH
BITCH
LOGO II
LOGOFF
16
11
18
19
11
18
lC
10
lE
02
02
02
02
02
02
02
02
02
FF
FP
FF
FF
FF
FF
FF
FF
FF
00'
00
00
00
00
00
00
00
00
00 00 1&
47 2B 17
4B 28 lK
ItA 2C 1'1
01 OA 11
ItC J5 18
35 3& lC
14 lit 10
15 1~ It
00
02
02
0.1
OJ
Olt
0"
01
03
0026
0026
0026
0026
0026
0026
0026
0026
0026
20
10
20
30
20
10
]0
20
20
16
17
lK
1'1
11
18
1C
10
1E
OllF
012P
012F
012F
012F
012F
012F
012F
012P
FE
1'1
RP"
CR R
"" Q
PP
H
L
II
P
P
P
P
L
C
H
L
C
R
R
II
II
J
K
J
].
J
L
J
1
1
..
C
K
T
00 01
80 01
80 01
KO 01
KO 01
80 01
ItO 01
80 01
KO 01
KO 0'1
00 01
KO OA
80 01
80 01
KO 01
80 01
110 01
80' 01
80 01
8001
DO 01
KO 0'1
DO DO 01
OK 00 01
O~ DO 01
OK 00 0'1
0'1 DO 0'1
DB DO OA
1J 00 0'1
14 00 0&
1!» 00 01
1& 1& 2J 00 00 00 00
17 11 2" IF IF 1F lP
17 17 lit 1P IF 1P 1P
17 17 2 .. IF lP IF 1P
17 17 lq 1F 1F 1F 1P
11 1F 1F 1P
U' IF IF 1P
1F lP lP lP
IF IF lP lP
1F lr IF 1P
11 11 :lI. 01 01 01 01
1B 1B 21 OB OB OB OB
1 B 1 B 2'1 OC OC OC OC
lB lB 21 00 00 00 00
lB 1B 21 01 DE OE DE
lB lB 21 OF DP OF OF
18 lB 21 10 10 10 10
lB 1B l7 11 11 11 11
lB lB 21 12 12 12 12
1B lB 27 1J 1J 1J 1J
10 lD 21 , .. , .. , .. , ..
11 lE 20' 1~ 1~ 1~ 1~
11 17 lq
11 17 lq
17 17 lq
17 11 2q
17 11 2q
1 b l j 00 DO 00' 00
11 17 2" IF 1F IF 1F
lK 18 2!» IF IF 1F IF
1'1 1'1 if> 1F 1F 1F lP
lllAl.l.ll111AlA
lB 18 n 1B 1B lB lB
1C lC 2H lC lC lC lC
10 lD 21 , .. 14 111 , ..
lE 1£ 20 1!» 1~ 1~ 1~
1b
WRITE
IF 01 0026 02 23 FP IF 0000 00 IF IF 08 08 00 0'1 17 11 lq IF IF 1F IF
LOGOFF
LOGOIl
BULK 1-0
SYSOPBRO'
IIITIRlCTIY I
IH TERlCTIYE
IIiTIRACfIYP.
BATCH
BITCH
20
21
22
23
21t
25
26
27
28
06
06
06
06
06
06
0&
06
06
02
02
02
02
02
02
02
02
02
20
20
20
20
10
20
]0
10
30
FF
FF
FF
FP
FF
FF
FF
FF
FP
20
21
22
2]
2 ..
25
000'0
0'000
0000
0000
0000
oooa
2~ 0000
27 012F
2a 012F
FE
FE
FE
FE
FE
FI
PE
PE
FE
1!»
, ..
01
00
47
47
2B
JJ
31
14
01
00
2B
2B
20
35
J5
15
, ..
01
00
JD
JD
3F
27
28
15 KO O~ lE
111 80 01 10
01 KO 01 11
00 80 OA 1&
OK 00 0'1 17
OK KO 01 lK
08 KO 01 19
DB KO 01 lB
lJ 80 01 lC
GROIIIIIG
DILATING
G801llllG
INTER1CTIVE GROIlING
GROIIIIlG
SET
r.ROIIIIIG
DILlfUIG
DiLl TIlIG
DILlYIIIG
DELI fING
29
21
2B
2C
20
2E
2F
10
11
]2
08 0026 08
08 001& O~
18 0016 02
17 ·0026 02
16 .0013 01
15 0011 01
lit 002& 02
14 0026 01
111 0026 01
, .. 0013 01
10
18
20
10
itO
40
20
30
qO
40
FF
FF
FF
I'P
FF
FF
FF
FF
FF
FF
2'1
21
2B
2C
20
2E
2F
3D
11
J2
0000
0000
0000
0000
0000
0000
0000
0000
0000
000'0'
00'
FE
00
UO
00
DO
FE
FE
FI
FE
21
q1
21
2F
JO
Jl
liB
itA
4'1
1t9
2B
29
2C
20
2E
J2
2B
2C
20
20
10
10
1F
40
.. ,
42
3F
qo
.. ,
42
0'8
OK
08
08
08
08
0'8
OK
08
08
GROIlING
DELlflNG
GROIIIIlG
GROIlIIIG
GROWIIIG
GROVIIIG
DJ!tUIIiG
DIL1TlNG
DILATIIiG
OILUIIG
])
JIt
)5
16
)1
)8
19
31
lB
lC
13 0026
110026
lC 002&
lB 0026
11 001J
19 001)
11 0026
11 0026
11 0013
11 DOll
08
08
02
02
01
01
02
01
01
01
10
18
20
10
40
40
20
30
itO
.. 0
FF
FF
FF
Fr
FF
FF
FF
FF
PF
FF
13
1 ..
J'>
16
37
18
19
31
1B
lC
01lF
OllF
012F
012F
012F
012F
012F
00
FE
00
00
00
00
FE
8111 FE
012F FE
012F FE
JIt
4C
JJ
39
31
3B
!»O
4F
4E
4£
J5
33
J6
37
18
3C
14
J.i
J9
11
38
)C
J~ 35
J& J6
37 17
17 18
JIt 00 0'1 lB lB 27 Jq
2-' Jq
00 01 lB lB 21 3'J
Jl 00 01 lC lC 28 Jl
JB 00 0'1 1C 1C 2K J8
3C 00 01 lC lC 28 3C
.i'l 110 01 1C lC 2K 39
Jl 00' 0'1 lC 1C III JA
1B 80 01 1C lC 28 JB
iC 80 01 lC lC 28 JC
GROWING
DIL1TIIIG
GROIIIIIG
IIITER1CTI'E GROIIING
GROIIIIIG
SET
GROIIING
DELATING
DILAYI NG
DELlTlNG
DILlYIIiG
10
lE
3F
40
Itl
42
.. 1
41t
itS
46
DB
OB
18
17
16
15
, ..
lq
, ..
lq
0026 01
O~26 01
0013 01
0010 01
0004 01
0001t 01
0013 01
0010 01
00011 01
lOOIt 01
10
10
20
10
itO
110
20
10
110
itO
FF
FF
FF
FF
'F
FF
FF
FF
FF
FF
JD
lE
3F
.. 0
Itl
.. 2
1t1
.. 4
It'>
4&
012F
012F
012'
012F
012F
01lP
0121
012'
012P
012F
DO
FE
00
DO
00
00
FE
FE
FE
FE
21
47
21
2P
10
11
29
2B
2C
20
2B
2B
2C
20
2E
12
2C
lD
2E
2E
3E
10
q3
44
q5
1t6
1F
itO
41
42
08
08
08
08
08
08
08
0'8
OK
JK
00
80
00'
00
00
00
80
80
0'1
01
01
01
01
01
OA
DA
ao 01
60 01
17
17
lK
19
19
19
111
19
1'1
19
17
17
18
19
19
19
18
19
19
19
SRRIllltitiG
LOOPIIiG
DILAYIIIG
INTER1CTIVE SHBIIKIIIG
SET
S8R tNK ING
SHRTIIKIRG
1t7
1t8
1t9
ijl
ItS
07
07
17
16
15
ry026
0026
0026
0026
0026
10 08 FF 47
10 08 FF 1t8
01 30 PF 49
~2 20 FF 4&
08 18 FF ItB
0000
0000
0000
0000
0030
00
FI
00
00
00
1t8
1t1
.. 1
4B
47
29
29
2C
lB
29
3D
10
qo
3F
08
08
OK
08
IF. 38
00
80
00
00
00
OK
08
OA
DA
DA
17
17
19
18
111
17 lq IF IF IF IF
17 2_ 1F IF IF lP
19 2& IF IF IF lP
18 2~ IF IF 1F 1F
1M 2~ IF IF IF IF
LOOPING
RITCH
SET
'>HtlIIIKIIiG
DIUTING
SHlIINKlllr.
<;H!lIIIKINr.
SHRINKIIIG
ItC
.. 0
.. B
4F
11
11
18
11
19
0016
0026
0026
00'26
0026
10
10
01
02
OS
.. C 012F
.. D012F
ItE 012F
ItF D12F
SO 012F
00
FE
00
00
00
.. D
ItC
rtF
SO
IIC
13 4D
H 4:
31 3A
J6 19
35 3q
00'
110
00
00
00
0'8
DK
01
OA
01
lB
lB
lC
lC
lB
lB
lB
lC
lB
1B
ST1RTlIIG
SET
IIlT£R1CTIVE ~1 17 0010 01 18 FF 51 0000 00 2F 52 3F OK 00 OA 111 111 2~ IF 1F IF IF
tllTER1CTIVE '>2 16 OOOC 01 20 FF 52 000'0 00 2F 53 itO OK 00 DA 19 19 26 1F IF IF IF
IIIT£R1CTIVF. ~j 15 ~OOq 01 JO FF 5] 0000 00 30 30 .. 0 08 DO 0'1 19 19 26 IF IF lP "
PREJUDICI
llAI'l'IIIG
FOR
IN.TERLOCK
SET
LOOPING
LOOPING
BITCH
SIT
lWAIT
~O
0026
0026
0026
0026
0026
0026
002&
0026
0026
08
08
10
20
18
FF
FF
FF
FF
FP
1~
lE
10
11
1&
17
lK
1'1
lB
lC
DO 01 17 17
80 0'1 lK lK
DO 01 18 lK
00· 01 1'1 19
DO 0'1 19 1'1
00 0'1 19 1'1
80 01 19 19
~o 0'1 1'1 19
80 DA 19 19
80 0'1 19 19
20' 15 1~ 1~ 1~
21 lq , .. lq lit
l2 0'1 0'1 0'1 0'1
23 00 00 00' DO'
lq IF IF 1F "
l~ IF IF 1F 1F
2& IF IF
l1 OB OB DB DB
2K lJ lJ H l J
"
l .. IF 1F IF IF
l~
l5
2f>
26
2&
26
26
26
l6
IF IF IF IF
IF IF " IF
1F IF IF "
IF
1F
IF
IF
IF
IF
IF
IF
1P
IF
IF
IF
IF
IF
IF
IF
lY
lY
jq
J/W)[aW(T)/ax]}
The usual procedure is to choose oa (t) so as to cause
the greatest diminution in 0
(8)
to
dW =0= [aW(T)/ax], dx(T) +[aW(T)/aT] dT
and the uniform sensitivity direction is
oa(t) = -p'(t)G(t)/a(t)
where
a
/W) (aW lax) ]}'t=Tox(T) ="-k'ox(T)
(6)
where k is a vector constant (defined explicitly) for the
nominal x (t), and
It remains to determine a (t) such that the sensitivity
of (1) to oa(t) is uniform over the entire trajectory.
Assuming that a nominal control aCt) and trajectory
x(t) on [to, T] are available, the time interval [to,·T]
is partitioned into small increments of width fl.t. Any
small control perturbation oaT at time r, to~r~ T, of
the type shown in Figure 1, with amplitude A (r),
duration fl.t, and fixed norm II oaT II is required to effect
an equal change in
= a
(T, s)G(s)A(r) ds
T
where if> is the transition matrix of (5). The norm of
oaT, from Figure 1 and (8) is
In place of (6), the penalty function variation can
be expressed as an integral
d(T, s) G(s) ds A (r) = constant (11)
[J
Trajectory Computation
131
Eliminating A (r) from (10) and (11) gives
[f
X k'
T
T+~t
cf> ( T,
s) G (s) ds
]2
(12)
I
T
The original steepest-descent gradient direction
-p'(t)G(t) is modified by aCt) (see (9)) at r=t to
produce uniform sensitivity in the penalty function.
The optimum step size A, as before, minimizes
=---O---C>--~-~----(l_-o
-0.1
0
Kl
0.1
Figure 5-Simple analog circuit for real time simulation and fast
time predictions using same integrators
Minimization method
In order to distinguish between local ffilmma and
absolute minima the search in the X j parameter space
is performed in two phases:
1. Systematic Grid Search
All possible parameter combinations within a
region of specified limits and a grid of specified
fineness are evaluated for their performance J.
Such a complete survey is feasible as long as the
parameter space is of low dimension as in present
applications (Figure 6).
2. Gradient Search
The Fletcher-Powell-Davidon gradient method3
uses the grid search minimum as a starting point
to precisely locate the minimum.
Example: Booster load relief controller design
The practical features of the optimization scheme are
best illustrated using the following example. The peak
bending loads at two critical stations, Xl and X2 (Figure
7) of a Saturn V launch vehicle shall be minimized
during powered first stage flight while the vehicle is
subjected to severe winds with a superimposed gust
(Figure 8, top strip) and to an engineout failure at the
time of maximum dynamic pressure.
The major variables are:
a
vehicle angle of attack
control engines gimbal angle
Figure 6--Parameter optimization performed in two phases:
(1) Systematic grid search (0) for complete survey of parameter
space; Grid point of minimum J ( 0) serves as starting point for
(2) gradient search which locates the minimum more precisely
(D). From grid search contour plots (Lines of J = Const) can be
displayed at CRT for better insight into J-topology.
generalized displacement of bending mode
at nose of vehicle
cP
vehicle pitch attitude error
X
commanded pitch attitude relative to
vertical at time of launch
z
drift, normal to the reference trajectory
~
slosh mass displacement, normal to reference traj ectory
Y (x), Y' (x) bending mode normalized amplitude and
slope at station x
1/
Disturbance terms due to engine failure:
cPF pitch acceleration due to engine failure
ZF
1/F
lateral acceleration due to engine failure
bending mode acceleration due to engine failure
Control law
The attitude controller to be optimally adjusted has
feedback of attitude error, error rate and lateral
acceleration:
(4)
138
Fall Joint Computer Conference, 1970
Rate Gyro Output:
(Ji= cb+ Y' (XRG) 7j
Accelerometer Output:
Ti=Z+A l 4>-A2cJ>-A 31i+A 47J
Gimbaled Engine Dynamics:
Shaping Filters:
Attitude Error Filter: cJ>s=-i/V+aw
aw= tan-1(Vwcosx/V - Vw sinx)
Figure 7-Minimax load relief performance criterion to minimize
peak bending loads at two critical locations, Xl, X2:
~ =max/MBi(t) /M Bi /
~=1,2
+q
tv+To
jtv
()2RG(t) dt--+min
(6)
tv~ti = cJ>+ Y' (xPG)7J
; , / \ _ Peak Moment for
~
Constant Gain Case
50% higher than peaks
I~ of optimized system
70
80
90
Figure 8-Typical Saturn V S-IC optimization results. Three
gain schedules are optimally adjusted to minimize the peak
bending loads among two stations (1541 and 3764 inches) for the
disturbance and failure history of the top charts. Peak loads
are substantially reduced compared with nominal Saturn V
performance (without accelerometer feedback). Weighting
factor q=O.05; floating optirilization time interval To=20 sec in
performance criterion (6)
Hybrid Computer Solutions
139
Engine Failure Switching Function:
+1windward engine out
o=
{
Wind
Disturbance
0 no failure
- lleeward engine out
Failure
Mode
Only one bending mode and one slosh mode was included in this study. The bending moment at station
Xi is
M Bi = M' aia+ M' /lit3+ M';;~
100~
aw
Engine No.
a
o
3{~t
o
~_
~
-----,...Jr==
Windward Engine Failure
l:
+-r
~~
I
I
Optimized
Gain
Schedules
l
a
(sec)
~~t~~==~I~r===
I
~ t+--.,.....-~.-.,--
Complete numerical data for all coefficients used in the
simulation are compiled in Reference 4.
Pitch
Angle
Engine
Deflection
Selection of performance index
(dtg )
fl
(deg)
r
50 [
~ r[~--""""",,,,,,,,,,I~-+--=
,~
I
I
In earlier studies4 quadratic performance criteria
such as
Bending
Moments at
Station 2
MB2'5~,
M B2
0
•
Peak MOIllent for
Constant Gain Case
22% Higher Than Peaks
of Optimized System
\ .
Flight Time -sec
70
80
90
Peak Moment for
Constant Gain Case
25% Higher Than Peaks
of Optimized System
I~
I
At Station 1
(5)
MBI
M
- :
'5~
0
-+- _.. __ .+--
BI
60
were-used. They allow a straightforward physical interpretation and at the same time can still be loosely
related to linear optimal control theory. Neglecting
external disturbances (aw ~ 0), Equation (5) can be rewritten in the more familiar form
~
Figure 9-8aturn V 8-1C optimization of Figure 8 repeated
for assumed windward engine failure under otherwise identical
flight conditions. Optimal gain schedules are strongly dependent
upon assumed failure condition
Results
where a is an n-dimensional coefficient vector, q3, q4
are constants depending upon ql, q2, M a' and M / and
superscript T denotes transpose.
The results from optimizations where Equation (5)
was minimized were disappointing insofar as peak
bending loads were reduced by a few percent only,
whereas the major reductions were in the RMS values
of the bending loads.
Since peak loads are of major concern to the designer,
a more direct approach was made to reduce peak loads
by using the minimax criterion (6) of Figure 7. During
each run bending load peaks at both critical stations
were sampled and compared. Only the greater of the
two peaks was included in J. This peak amplitude
normalized with respect to the structural limit M B was
the major term in J. The only additional term, the mean
square of measured error rate, was included to ensure
smooth time histories and trajectory stability. This
performance criterion reduced the number of weighting
factors to be empirically adjusted to one, whereas n
such factors must be selected in linear optimal control
theory for an nth order system.
A typical optimization result is shown in Figure 8.
Drastic reductions in bending moment peaks result
from the minimax criterion compared with the constant
gain case. It should be noted, however, that perfect
predictions 20 seconds ahead were used in the optimization including the anticipated failure.
In Figure 9 the results of a similar case ar.e shown.
All flight conditions are identical to the previous case
except for the failure mode: a leeward engine fails in
Figure 8,a windward engine in Figure 9. Again, peak
bending loads are substantially reduced in magnitude
compared with a case with nominal constant adjust~
ments of the controller. However, two of the three optimal gain schedules (ao(t) and g2(t)) differ drastically
for the two failure modes. In view of the lack of any
a priori knowledge about time and location of a possible
engine failure no useful information can therefore be
gained from the two optimizations concerning load
relief controller design. This basic shortcoming of all
strictly deterministic optimization schemes must be
relieved before the method can be applied to practical
engineering design problems characterized by parameter
or failure uncertainties.
140
Fall Joint Computer Conference, 1970
A or B. The performance index evaluated for each
failure may be of the form of Figure 10. Neither K optA
nor K oPtB would be optimal in view of the uncertainty
concerning the failure mode. Performance might be
unacceptably poor at the level I Au if Failure A occurred
and the control parameter were adjusted at the optimum for Failure B. The best tradeoff in view of the
failure uncertainty is the minimum of the upper bound
of J A and J B (solid line in Figure 10). In the example of
Figure 10 this optimum which is the least sensitive to
the type of failure lies at the lower intersection of the
two curves.
-
J
Upper Bound J of
Performance for
Failure A ~ B
Extension of the optimum-seeking computing scheme
B
Failure A
KoptA or B KoptB
Figure lO-Optimum adjustment of scalar control parameter K
considering possible occurrence of failure A or B
The most direct way to locate the minimum of the
upper performance bound is to simulate all possible
failure modes for a given set of control parameters in
order to determine the upper bound I. A gradient dependent minimization technique can again be applied
to seek the minimum. One might expect convergence
difficulties around the corners of these I-functions.
However, only minor modifications were necessary to
the basic Fletcher-Powell-Davidon gradient scheme and
to the preceding grid search to locate comer-type
minima. The changes included a relaxing of the gradient
convergence test (I VJ I ~~, where }; is a small
specified number). If all other convergence tests are
passed, then ~ is doubled in subsequent iterations. In
OPTIMAL REGULATOR DESIGN INSENSITIVE
TO FAILURE UNCERTAINTIES
Previous work to reduce parameter sensitivity has
centered around inclusion of sensitivity terms aJo/aK
in the performance index to be minimized, where J 0
denotes performance under nominal conditions and K
is the uncertain parameter vector.5 Substantial additional computational load would arise if such an approach were implemented on the hybrid computer.
Moreover, in the case of possible failures the uncertain
parameters may vary discontinuously from one discrete
value to another like the engine failure switching function in the preceding example:
I for Failure A
0=
0 for Nominal Case
{
-1 for Failure B
q1M B1
:T")
~j.B4\1J
I
Flight Condition A
(Windward Engine Out)
Flight Condition B
(Leeward Engine Out)
MAxlMBil
MBi
Figure ll-Generalized load relief performance criterion to
minimize upper performance bound J for two possible
operating conditions
} =
Another approach is therefore chosen: The hybrid
optimization method is extended to account for such
failure uncertainties even if no partial derivatives exist.
Consider the case of two possible failure conditions,
-:IJ
max IMBi/MBd +
t,,+To
jt"
82RG(t) dt~min
CaseA,CaseB
i=l,2
t,,erand lengths, the LA and LB fields are also decimal
quantities.
The AC and BC bits indicate whether the fields
addressed by A and B respectively, are located in the
common partition or in the user partition. Thus, a
maximum of 20K characters of memory are available
to the System Ten programmer, 10K in common
and 10K in his partition.
The IA and IB fields of the instruction are used
for index register selection. They are two bit binary
fields; IA = 0 indicates that the A address is not indexed, IA = 1 indicates that the effective address is
A plus the contents of the first index regis~er, and
so on.
The System Ten instruction set is given in Table 1.
(A) denotes the contents of the field address by A.
When a branch instruction is encountered, control
passes to the instruction addressed by A if the condition
specified by LA is met. If this condition is not met
the condition specified by LB is checked and if met,
control passes to the instruction address by B, otherwise the next instruction in sequence is executed.
In addition to specifying conditions related to the
outcome of arithmetic and input/output operations,
the LA and LB fields may specify that a subreutine
branch is to be taken or that a branch is to be taken
when a device has a pending SERVICE REQUEST.
In this latter case, the address of the device requesting
service is stored at the location specified by B.
One form of unconditional branch allows the programmer to give up a portion of his allotted processing
time. This is the branch and switch instruction. When
this instruction is encountered, a branch is taken and
partition switching occurs. For example, if a program
is waiting for a request for service from a terminal, it
can be designed to relinquish processing time to other
partitions until the -request occurs.
In disc input/output instructions, the B field is
the address of a six character disc address rather than
a character count. No character count is required as
System Ten
disc records have a fixed length of one hundred characters.
A disc file has fifty records per track. Record addresses are interleaved by five so that there are four
sectors between sequentially addressed sectors. This
permits the programmer to modify disc addresses
and do a limited amount of housekeeping between
sequentially addressed sectors. Thus, random access
file organizations which employ some form of scrambling can be implemented very efficiently. There is,
however, a penalty when purely sequential access
methods are used.
b1
b6
b5
0
o
0
0
0
0
0
0
0
0
I
o
0
0
I
I 0
I I
0 0
I 0 I
I I 0
0
0 I I
I 0 0
I 0 0
I 0 I
I 0 I
I 1 0
1 I 0
I I I
I I t
I
0
I
0
I
0
1
0
I
0
0
0
0
10
II
VT
12
13
14
15
FF
CR
SO
SI
8
9
0
I
0
NUL
SOH
STX
ETX
EOT
ENQ
ACK
BEL
BS
HT
LF
I
2
3
4
5
6
1
0
I
0
I:::S:
0
2
3
B
LB
ADDRESS
4
5
ADDRESS
6
7
8
9
CHARACTER
System Ten demonstrates the feasibility of providing
multiprogramming capabilities, without the need for a
Row
A
o
CONCLUSION
b4 b3 jb2 bl
2
LA
186B
I
I
I
0
I
0
I
I
I
0
I
0
I
2
3
4
5
6
DLE SP
!
DCI
DC2
DC3 -#
DC4 S
NAK %
SYN a
ETB ~
CAN (
)
EM
SUB
ESC +
FS
•
GS
RS
I
US
0
•A
P
Q
R
S
T
U
•
I
.
*
.
I
2
3
4
5
C
1
B
C
D
E
F
G
H
•f
v
W
9
w
h
V
I
:
J
Z
;
-
K
L
M
N
!
0
Figure 5-Character set
b
c
u
•
[
i
j
k
{
]
I'
m
1.
,
A-
complex software executive. Adoption of a system
design philosophy oriented toward application requirements rather than unlimited generality made implementation of the hardware executive a straightforward
and inexpensive task.
P
q
r
•t
X
Y
>
a
1
d
8
9
<
I
0
Figure 6--Instruction format
J
z
ACKNOWLEDGMENTS
We would like to thank the many individuals who
contributed to the development of System Ten.
Worthy of particular mention are D. Neilson, E.
Poumakis, and H. Schaffer whose ideas provided the
framework for the system as it exists today.
:
n
~
0
DEL
REFERENCES
1 T B STEELJR
Multiprogramming--Promise, performance, and prospect
Proceedings FJCC Vol 33 p 99 1968
On automatic design of data organization
by WILLIAM A. McCUSKEY
Burroughs Corporation
Paoli, Pennsylvania
INTRODUCTION
of these relationships, of their representations in the
IPS, of the representation of the data in the IPS
storage, and of the logical access and storage assignment
proc;esses which will operate on the data organization.
The term process is used here to mean an operation or
set of operations on data, whether that process is
described by the problem definer or defined by the
system designer. The system design procedure is itself a
process and will be referred to as such.
The procedure for organizing data for an IPS may be
thought of ideally in terms of four operations. First,
a problem definer interprets a problem in his environment and defines a set of requirements which are as
complete and concise as possible and which any solution
of the problem, manual or automatic, must satisfy.
A problem definition is complete if, in order to solve the
problem, a system designer needs no further information
from the problem definer. The problem definer defines
the information processing problem in terms of sets of
data, membership relationships among· these sets of
data, processes operating with the data, time and
volume requirements on the processing, other constraints, and a measure of effectiveness for the solution.
In order that the best possible design be produced,
relative to the given measure of effectiveness, the
problem definer should place as few restrictions as
possible on the number of alternatives the system
designer may consider.
Second, the system designer develops a specification
of logically ordered structure for the data and the logical
access processes which may be used to find any element
in the structure. This structure will be called the logical
organization of the data. An example is a binary tree,
array, or any directed graph.
Third, the system designer specifies for these logically
structured data the corresponding representatio1;ls in the
storage and the strategies for storage assignment. The
resulting structure will be called physical organization
of the data.
And fourth, the implementor of the system converts
A number of research efforts have contributed to the
beginning of a methodology for the automatic design
of large-scale information processing systems (IPS). See
for instance Nunamaker.1 One facet of study in these
efforts is the design of data organization.
Such a study was undertaJmn in the context of
Project ISDOS,* now at the University of Michigan.
The purpose of the study was to develop a model of the
data organization design process and to create from this
model a method for generating specifications of alternative data organizations. The first step of the study was
to obtain a view of data organization uncomplicated by
data usage. To this end the design of data organization
(DOD) was divorced from the total IPS design process.
A method for decision-making, which relates data
organization to data usage and a measure of effectiveness, was to be a second phase of the study.
The purpose of this paper is to outline some initial
results and implications of a set-theoretic approach to
DOD which was developed for ISDOS. The assumed
framework of the DOD process is described briefly.
Within this framework concepts of data are defined in
terms of sets. The DOD process can then be described in
terms of set-theoretic operations. Finally some implications of the approach are given.
ORGANIZATION OF DATA-A FRAMEWORK
The term data is used here to mean the IPS representation of objects which are used as a basis for decision or
calculation. The term data organization is used here to
mean the set of relationships among data established by
the problem definer or created by the system designer,
as well as the representations of these relationships in
the IPS. A design of data organization is a specification
* Information System Design and Optimization System
187
188
Fall Joint Computer Conference, 1970
the actual data from its present form to a form which
meets the new specifications.
Within this framework the approach was to view all
concepts of data in terms of sets and then to define the
design process, steps one through three above, in terms
of set-theoretic operations on these sets. The settheoretic details may be found in McCuskey.2 The
following attempts a more narrative description.
CONCEPTS
The concepts of data organization described below
must be viewed in the context of an ideal automated
design system such as ISDOS. The problem statement,
written in a formal problem statement language, is input
to a system design program. This program specifies how
processes should be organized into programs, how data
should be structured logically and physically, and how
the programs and data should be managed as a complete system. The system design is then automatically
implemented.
The goal of this description of data concepts is to
provide a framework within which to formulate a
precise, simple algorithm. The algorithm must operate
on a problem definition of data to produce a specification
of IPS storage organization for the actual data.
Because of this goal the sets of data which the
problem definer describes are viewed here as settheoretic sets related by unordered cross-product
relations. The algorithm must then establish what
redundancies to keep, specify how the data should be
ordered and then specify how this logical structure
should be represented in storage.
The goal requires that the distinction between logical
and physical data organization be defined precisely. The
logical structure discussed below is the structure which
is directly represented in storage. It incorporates some
features, like redundancy specification, which are generally considered in the realm of "storage structure".
Problem description
From the problem definer's point-of-view an IPS
operates on symbolic representations of conceptual or
physical characteristics such as name, age, address, etc.
The elementary object used to build such IPS representations will be called a symbol. The problem definer
must specify an alphabet, the set of all symbols which
are valid for the problem he is defining. One such
alphabet is the EBCDIC character set.
Each occurrence of a characteristic, such as sex,
amount, or title, may be thought of as an ordered pair
of symbol sequences. The first component of the pair is
the data name; the second component is the data value.
The ordered pair will be called, generically, a data item.
A data item will be denoted by its associated data name.
An instance of a data item is a specific data name/data
value pair. Thus (NAME, JONES)* is an instance of
the data item NAME. Common usage abbreviates this
statement to "JONES is an instance of NAME". A
data item has sometimes been referred to as an attribute, data element, or datum. In common high-level
programming language usage the data value is the
"data" stored while the data name is "data about data"
which appears in the source program and enters a
symbol table during compilation.
.
From the problem definer's point-of-view the IPS at
any point in time will contain representations of many
different occurrences of a given characteristic, say
warehouse number. Disregarding how warehouse numbers are associated with other data in the IPS, one can
describe a set of all distinguishable instances of a data
item, named WHNO, existing in the IPS at the given
time and having the same data name. Instances are
distinguished by data value. The set WHNO contains
no repeated occurrences of warehouse number. Such a
collection will be called a data set at level 0 (henceforth,
data set/O). The data set is referenced, like a member
data item, by the data name common to all its elements.
Context determines whether a data name refers to a data
item or a data set.
Associated with a data set/O is a number, called the
cardinality of the set, which specifies the anticipated
number of elements (unique data item instances) in the
data set. Among data sets/O exist cardinality relationships such as:
"at any given time approximately three unique
instances of ITNO and exactly one unique instance
of CITY will be associated with a unique instance
of WHNO".
The anticipated cardinality and cardinality relationships among data sets, as defined here, are characteristics of the information processing problem and must be
specified by the problem definer. The elements of a data
set represent unique occurrences of an object, such as
warehouse number, used in the problem as a basis for
decision or calculation. What objects are used and how
many unique occurrences of each must be represented in
the IPS at anyone time depend on how the problem
definer interprets the problem.
These cardinality specifications eventually will help
the system designer determine how much storage space
* A pair of right-angle brackets, ( ), will be used to indicate an
ordered n-tuple (here a 2-tuple).
Automatic Design of Data Organization
may be required for any data organization design which
he considers.
The concept of data set may be extended to higher
levels. Data sets/O may be related by a named set
membership association. The problem definer then
describes processes in terms of operations on these
associations as well as data items. For example, an
updating process might be defined for INV (inventory)
where INV is the data name associating the data items
WHNO (warehouse number), ITNO (item number),
and QTY(quantity). Nothing is said about ordering or
logical structure on INV except the specification of set
membership. In set-theoretic terms INV is a subset of
the unordered cross-product of the three data sets/O.
INV names the data set/l (data set at level one), the
next level above its highest level component.
Such set membership relationships may be visualized
in a non-directed graph as a tree in which data set names
are associated· with vertices and dotted arcs represent
membership relationships. A graphic representation of
the data set/l INV is given in Figure 1.
A data set/n (data set at level n) (n;?: 1) may be
thought of as a set of (distinguishable) ordered pairs.
Each ordered pair is unique within the data set/no The
first component of the pair is the data name of this data
set/no The second component of the pair is an unordered
m-tuple. Each component of the unordered m-tuple is an
element (itself an ordered pair) of a data set/j
(05::j5::n-l). At least one component of the unordered
m-tuple is from a data set/(n-l). The term data set
component refers to a component of this unordered
m-tuple. A data set component is referenced by its data
name. Data set element refers to a unique member
element of the data set/no Component instance refers to
the instance of a data set component in a given data
set element. Figure 2 gives an instance of the data set
•,
:oN
It'
•
,
DBO
,
,
,
,
,
,
,
,
,
I
,
,
"
"
"
"
"
"•
•
l'1'lfO
Figure I-Graph representation of data set INV
"
•
qI'Y
}>
}>
,
(IftO,2>1>
, }>
Figure 2-Instance of data set INV
INV. * The data set contains five data set elements. The
data set components are WHNO, ITNO, and QTY.
(WHNO, 3) is a componentinstance of WHNO in three
data set elements.
The concepts of cardinality and cardinality relationships, described above for data sets/O, are extended to
data set/no As with data sets/O cardinality specifications for data sets/n must be given by the problem
definer.
According to the above definitions a data set/n
element is unique within its data set. However, multiple
instances of the same data set element may appear as
component instances in a data set at a higher level. In
Figure 2 (WHNO,3) is a unique data set element of
WHNO but is a component instance in three data set
elements of the data set INV. This multiplicity of
occurrence of the same data set element is referred to
here as redundancy. The amount of redundancy-the
multiplicity of occurrence of the same data set element
-in a data set/n is determined by cardinality relationships among the component data sets, by the cardinality
of each component data set, and by the association
of data sets defined by the problem definer.
The design of logical data organization may be viewed
as a specification of the amount of redundancy and
ordering of data set elements and component instances.
For the design process to consider as many alternative
logical structures as possible, as little structure-redundancy reduction and ordering-should be implied by
the problem definition. The above view of data sets
admits as much redundancy and as little ordering as the
problem definition can allow and still be complete and
concise .
Logical data organization
The first problem for the system design process is to
take a specification of these data sets and, by performing
* A pair of braces { }, will denote an unordered m-tuple.
190
Fall Joint Computer Conference, 1970
,.,
, , ..
INV
,
•
WHNO
•
,.,
STOCK
CITY
•
ITNO
•
QTY
Figure 3-Graph representation of revised data set INV
a sequence of operations, obtain a specification of logical
data organization for the data set. Logical structure is
provided for two reasons. First, the logical structure
maintains in some form the membership associations
established and referred to by the problem definer in his
problem statement. Second, the logical structure provides a path or sets of paths to any element of the
structure. Logical access processes, for example binary
search, depend on such paths.
The logical structure of data may be visualized as a
directed graph and will be called a data structure. Each
vertex of the graph represents either a data item or a
data structure. A data item or data structure repre~
sented by a vertex will be called a data structure
component. An arc of the graph then represents a logical
ordering relationship between two data structure
components. Such a directed arc is an ordered pair of
data structure components and will be called a connection. The logical connection described here is the
connection which will be represented directly in storage
by a fixed or variable distance in the address space of the
storage. A data structure can then be viewed as a set of
connections-that is, a set of ordering relations among
its data structure components. A series of contiguous
connections, called a logical access path, may be formed
between two data structure components. Logical access
processes use these paths to access components in the
structure. A specification of data structure is a pattern
which when applied to an instance of a data set yields
an instance of the given data structure.
Consider the data set INV, revised and described by
the non-directed graph given in Figure 3. INV has been
redefined to be a data set/2. An instance of data set INV
is given in Figure 4. To avoid the confusion of mUltiple
brackets, the depiction of the data set instance in
Figure 4 omits the bracket symbols of Figure 2 and
factors the data names to the heading of the figure. Each
circled single data value represents a data item instance.
Data set membership relationships are represented by
bounding lines in the heading. Each entire row represents a data set element of INV. Each column represents
instances of the specified data item. While a horizontal
ordering of data items has been introduced in the figure
for ease of reading, it must be remembered that this
ordering is only artificial: the data set components
WHNO, CITY and STOCK actually form an unordered
3-tuple and ITNO and QTY form an unordered
2-tuple .
In the development of a data structure from the data
set INV the system designer might specify the connections (WHNO,CITY), (CITY,STOCK) and
(WHNO,STOCK). Similarly the connections (ITNO,
QTY) and .(QTY,ITNO ) might be specified within the
. data structure developed from STOCK. The data
structure· components of the data structure developed
from INV are WHNO and CITY, which are data items,
and STOCK which is itself a data structure. The
structure indicated so far is depicted in Figure 5a. For
convenience, INV and STOCK will temporarily be the
names given to the data structures developed from the
data sets INV and STOCK.
Consider now the connection from WHNO to
STOCK. This connection creates an ambiguous
reference because there are t.wo data structure components in STOCK. If a logical access path is to be
constructed from, say, WHNO to the data structure
,
,
DV
r - - S'l'OCIC~
lIDO
Cl'l'Y
I'l'110
Cll'Y
G)
®
®
®
CD
@
@
G)
®
Q)
(j)
(!)
®
@
®
®
G)
®
Q)
(j)
CD
®
@
@
®
@
@
®
Figure 4-Instance of revised data set INV
Automatic Design of Data Organization
(a>
,.
. ,"
..
•
.. .. • •
,
I
DV
••
•
STOCIC
,
(b)
(0)
(el)
Figure 5-Development of a data structure for INV
191
192
Fall Joint Computer Conference, 1970
STOCK, then through STOCK to QTY, the questions
can be raised: At what point or points, ITNO and/or
QTY, can the path enter the data structure STOCK and
at what point or points can the path exit STOCK? What
is the precise path from WHNO to QTY and out to
another component?
It is important that this ambiguity be resolved. When
the data structure is represented in storage, the programs which represent 'the logical access processes will
operate on the storage representations of the logical
access paths in order to access a given component
representation. The ambiguity in the path from
WHNO to QTY must be resolved if the program
representing the logical access process is to reference the
representation of QTY from the representation of
WHNO.
The ambiguity is resolved here by designating one or
more of the data structure components as entry
components and one or more components as exit
components of the given structure. A data structure
component may be an entry component, an exit
component, both, or neither. The set of entry and exit
components will be called the boundary of the data
structure. Since a data item may be considered an
elementary data structure, the boundary of the data
item is the data item itself. A data item is its own entry
and exit component.
Thus, the connection to a data structure means a
logical reference to its boundary; that is, to each of its
entry components. A connection from a data structure
means a logical reference from each of its exit components. This interpretation of. connections makes no
assumptions about the storage representation of the
connection or of the boundary. When the boundary
consists of multiple entry and exit components the
logical access process must contain the logic for deciding
through which entry and exit component the logical
access path should go.
In the graph depiction of a data structure the
boundary may be represented by broken arcs from the
vertex representing the data structure to the vertices
representing entry components; and by broken arcs
from the vertices representing exit components to the
vertex representing the data structure. The graph
representation of the data structure then has a vertex
denoted by the name of the data structure and a
sub-graph representing the logical relationships among
the data structure components. The arcs representing
the boundary specify which subgraph is associated with
which data structure vertex.
In the data structure INV, Figure 5b, WHNO has
been designated as the entry component of the data
structure INV and STOCK as the exit component.
ITNO has been designated as both an entry and an
exit component of STOCK. QTY occurs also as an exit
component of STOCK. The boundary of INV is the
component set consisting of WHNO and STOCK.
One piece is still missing from the picture of a data
structure. An instance of a data set may contain
multiple instances of its components. For example, for
each WHNO there may be one CITY but many
STOCKs. In the data set INV the same WHNO
instance and CITY instance, for example (WHNO,3)
and (CITY,A) in Figure 4, were associated redundantly
with each of three different STOCK instances. The
logical design of the data may specify that for each
STOCK instance the corresponding WHNO and CITY
instances will be repeated and maintained in the logical
structure. In other words full redundancy of data will be
maintained. If this design is implemented in storage, the
same values of WHNO and CITY will be stored for
each related instance of STOCK. On the other hand the
logical design may specify that only one occurrence of
the redundant WHNO and CITY will be maintained
and with that occurrence of WHNO and CITY will be
associated a new data structure each of whose components is one of the related instances of the data structure
STOCK. The redundancy of WHNO and CITY has
been reduced. This structure is depicted in Figure 5c.
A structure of multiple instances of the same data
structure is sometimes called a repeating group.
Within this newly created structure the instances of
STOCK for a given WHNO/CITY combination are
given some ordering, e.g., ascending numerical order by
ITNO value. In addition, a boundary is specified for
this new data structure; for instance, the entry component is the numerically first STOCK (f(ITNO» and
the exit component is the numerically last STOCK
(l(ITNO». In the graph these ordering and boundary
specifications can be attached to the arcs to and from
the STOCK vertex. The system designer may give a
name to this new structure, as nS(1) in Figure 5c.
Assuming the given redundancy reduction, one can
apply similar reasoning at the level of INV. According
to the cardinality relationships given earlier, several
instances of the data structure for INV will occur in an
instance of the data structure, one for each instance of
WHNO. Each instance of INV will have the logical
structure described in Figure 5c. This new structure has
three components: WHNO, CITY, and nS(1). In each
instance of INV, WHNO and CITY appear once and
are connected to a data structure whose components are
instances of STOCK. The data structure, nS(O),
combining all instances of INV structure will be an
ordering of instances and will have a specified boundary.
The complete specification of the data structure is
given in Figure 5d. The design gives a specification of
both ordering and redundancy and establishes the
Automatic Design of Data Organization
network by which a data structure component may
logically be accessed. Note that the membership
relationships given by the problem definer have been
maintained.
Associated with a data structure is one or more
logical access processes which function to find or access
the relative logical position of a component instance in
an instance of the data structure. A logical access
process uses contiguous connection instances to construct a path to the relative position of the desired
component instance. For example, to find the data value
of CITY for a given data value of WHNO, an access
process for the above structure might create. a path
which starts at the entry component instance of the data
structure DS(O) and courses through each instance of
INV until it finds the given WHNO value which
connects to the required CITY value. In each instance
of INV the path leads from WHNO to DS(l) and exits
via the DS(l) vertex. The access path does not course
logically through the instances of STOCK.
From the point· of view of the system designer a
logical access process is like a problem-defined process.
The system design process must incorporate it with the
problem-defined processes into the program structure.
Any data which the logical access processes need in order
to function properly are designer-defined data sets which
themselves must be organized logically and physically.
At this point the system designer becomes a problem
definer.
Physical organization
Physical organization of data means here the IPS
storage representation of the given data structure. Two
degrees of physical organization should be recognized:
relative organization and absolute organization. Relative
organization involves the manner in which the data
structure components, connections, and boundary of a
data structure will be represented in IPS storage. Such a
specification involves questions of numbers of cells of
memory required, sequential or non-sequential storage
of components, header cells, etc., but not the actual
locations of the data in storage. Absolute organization
involves the actual locations of the components,
connections, and boundary representations in storage.
Absolute organization is specified by a set of storage
assignment processes and must maintain the specified
relative storage organization. In the following discussion
major consideration is given only to the relative
organization.
For the design of relative physical organization a
relative storage area is defined here. This conceptual
storage area is an ordered set of cells. Each cell is
36 y - Length
Poai tion
I
+--
'0. , . . . . .
2.
5.
6.
,.....
b1ta-
1,
!:
.........
J
~---~r"''''~",
I. . . . . . . . ~ I:--__---!l
~
r----.,;.----:O
...- ... ...
r'" ............
1
...
Ai
I
~-.........."..
... -... -...~L
I ......... . .
7.
8.1~-"'-"'-.. --~I ......... ...-r-------..;;:...
9'1
. . . .J ...... "'1'
I
10. :.........
... _ r[
. .~~ . . . . . . . . . . . )t------!l ~
11.
193
I ......... >
-.
.....
-
-
1
Bode A
.....
..............
... ... ... : :
.....
~'T-I...-..;.... ""'------.>I
J
Figure 6-Storage node A in relative storage
uniquely identified by an order-relative position and a
length. Cells are non-overlapping. The length of a cell is
measured in common units, such as bits.
Looked upon as elements of a set, and regardless of
what they will represent, the cells in relative storage
may be grouped together conceptually in many different
ways. A storage node, or simply node, is defined to be a
collection of elements each of which is a cell or a storage
node. The cells in a storage node need not be contiguous
relative to the ordering. In Figure 6 node A consists of
three elements: two nodes and a cell. A single cell may
be regarded as an elementary node.
For convenience in referencing a node relative to
another node a measure of separation between the two
nodes is defined. A separation between two nodes will be
defined as the number of units of length, bits or words
for instance, which, according to the given order-relative
positions of the cells in relative storage, separates a
reference cell in one node from a reference cell in the
other node. The ceJl from which reference is made in the
given node to another node will be called an exit cell
of the given node. The cell to which reference is made in
the given node from another node will be called an entry
cell. The reference cells of a node will be called the node
boundary. An elementary node or single cell is its own
entry and exit cell.
Specification of entry and exit cells for a node is
required for much the same reason that entry and exit
components are specified for a data structure. If
particular boundary cells were not specified, then
reference to or from a multi-cell node would be ambiguous. In Figure 6 cell 0 has been designated the entry
cell of node A (denoted by Ai). Cell 7 has been designated
the exit cell (denoted by A 0).
It should be noted that the choice of the boundary
194
Fall Joint Computer Conference, 1970
3.
1
4:
Node B
8:
B.~
9:
J
Figure 7-Storage node B
of a node in the conceptual relative storage is arbitrary.
Multiple entry and exit cells may be designated in a
node. Several different separations can occur between
two nodes if one or both have multiple entry and exit
cells. In Figures 6 and 7 only a single separation has
been defined between nodes A and B. This separation is
one cell-Ao to B i . Figure 6 and following assume
that all cells have the same length and that separation
is measured in number of cells.
The system designer must specify first how to
represent a data structure by a node in the conceptual
relative storage and then specify a storage assignment
process for mapping the node into absolute storage. The
relative storage representation of the components,
connections, and· boundary of a data structure will be
called here a storage structure.
A data structure component is represented in the
relative storage by a node. If the data structure
component is a data item, this node may be a set of cells
which are contiguous relative to the ordering of relative
storage. In Figure 8a the designer has decided to
represent the data item WHNO by a two-cell node with
the first cell being both the entry cell,WHNO i , and the
exit cell, WHNO o• The system designer has decided that
the first cell of the node will be the reference cell in any
future separation specifications. The specific orderrelative position of this node in relative storage is
unimportant. Only the separation between it and other
element nodes of the given storage structure is important. Figure 8a also represents data items CITY,
ITNO, and QTY. The number of cells required to
represent the data item is determined from Hie problemdefined size of the data value. This representation
assumes that only the data value is to be represented in
the node.
If the data· structure component is a data structure
itself then the storage structure maybe defined
recursively by representing the components, connections, and boundary of this component.
A connection in a data structure may be represented
in one of two ways:
1. by a fixed separation between an exit cell of the
node representing the first component and an
entry cell of the node representing the second
component;
2. by a variable separation which will not be given
actual value until storage assignment takes place.
In either case the IPS will maintain a record of' the
separation. In common practice the fixed· separation is
recorded as a fixed address offset in program instructions. To' handle variable separation the system
designer may define another data item, a pointer, to be
associated with the data structure component from
which the connection is defined. The system designer
also defines maintenance processes to update the pointer
and perhaps other associated data sets, such as headers
and trailers,· to aid in maintenance.· In Figure 8b the
connection (WHNO,CITY) has been represented by a
variable separation in the form of a pointer. A fixed
(a)
'lHN°l
I'l'NOi
[
I
[
I
WHNO
ITNO
]
I
]
WDOo
CITyil
ITNOo
qI'Yi
I
I C1TYo
CITY
I qI'Yo
qI'Y
(b)
'lHN°i
OITYi
[
'lHNO
]
~
I
CITY
WHNOo
I'l'NOi [
qI'Yi
I
I
ITNO
Ql'Y
, CITYo
(c)
STOCK1
[
I
I
ITNO
qI'Y
J
STOClCo
r
I, STOCK
o
Figure 8-Development of storage structure
]
I'l'NOo
I
I Q'l'Yo
Automatic Design of Data Organization
separation of two cells has been specified to represent
the connections (ITNO,QTY) and (QTY,ITNO).
The data structure boundary is represented by a node
boundary developed in the following way. The designer
may specify that the boundary of the node representing
the whole data structure consists of the entry cells of
nodes representing the data structure entry components
and the exit cells of nodes representing the data
structure exit components. Alternatively, the designer
may incorporate additional cells in the node and define
them to be the entry and exit cells of the node. He then
defines a fixed or variable separation between these cells
and the respective boundary cells of nodes representing
the data structure entry and exit components. The
additional cells and the boundary cells of nodes representing the data structure entry and exit components together represent the data structure boundary.
In terms of the graph representation of a data
structure, for instance Figure 5d, the use of additional
cells corresponds to treatment of the broken arc, say
from DS(l) to STOCK, as a true connection; DS(l) is
represented by the additional cells and the connection is
represented by fixed or variable separations between
these additional cells and the ENTRY and exit cells for
the first and last instances of STOCK, respectively. If no
additionaJ cells are used, the broken arc is not viewed as
a true connection and is therefore not represented
explicitly in relative storage.
In Figure 8c the data structure boundary of STOCK
has been represented by the entry. cell of the entry
component ITNO and the exit cells of the exit components ITNO and QTY.
Associated with a storage structure is one or more
storage assignment processes. A storage assignment
process will apply the relative storage structure design
to an instance of the data structure and assign actual
physical hardware memory locations. The storage
assignment process is responsible for maintaining all
"data about data" which is necessary for assignment of
positions and all positional information which is
necessary for use by the implemented logical access
processes. The anticipated number of length units, e.g.,
cells, required by a node to represent a data structure
instance may be developed from the size of data item
nodes, the cardinality relationships given by the
problem definer, the amount of redundancy defined by
the system designer, and the requirements of pointers
and related additions. See McCuskey3 for details.
A storage assignment process, like logical access
processes, must be incorporated with the problemdefined processes to create program structure, whether
at the operating system level or elsewhere. Any "data
about stored data" which the storage assignment
process requires is, from the point of view of the system
-
r-
-- -
195
--I
DlISIGlf PROCBSS
I
I
I
I
I
I
DA.TA.
STRUCTURE
I
DESIGlIBR
I
I
I
I
I
DESIGNER
I
I
I
I
I
I
STRUCTURE
I
DESIGNER
I
L ________
r - - - - - - - - - - - --.J
I
~I----~
--l
Figure 9-Data organization design process
designer, just like problem-defined data-data sets
which must be given logical and physical structure.
DESIGN PROCESS
The goal of the concept descriptions above is to
provide a framework within which .to formulate an
algorithm which, given a specification of problemdefined data, would specify how the actual data will be
stored and accessed in the IPS. Figure 9 gives a very
general flow chart of a design process for data
organization.
In the design process the data structure designer
accepts a specification of data sets and generates a
specification of data structure (components, connections, and boundaries) and of logical access processes.
While generating a specification of data structure, the
designer acts itself as a problem definer; the problem is
logical access to components of the data structure. The
196
Fall Joint Computer Conference, 1970
decision-maker has been developed. How a decision
should be made at each point depends on the relation
between the designed structure, the processes operating
on it, and the performance criterion. As yet this relation
is not understood .
Consider the specification of data structure for set
INV (Figure 3). Suppose first that the given redundancy
is to be retained. Then a general, recursive data
structure design procedure might be:
' \ DS(O)
f'(1IBRO) I
I
1(1UIIO)
\/
./
,;
,/
BY
...........
"-
"-
'\.
,/
/
"\
//
t
\
/
\
Process D
.-----...-.~.~ ~
1IBRO
/ ~
/ /
erl'Y
I
/
/
/
/ /1
,
'\
\
\
\
~~\
;.~
Figure 10-Result of process D
definition of logical access processes must be input to
the process structure design in order to be incorporated
in the program specification. The structural information
must be specified in terms of data sets and then input to
the design algorithm.
The storage structure designer accepts the specifications generated by the data structure designer and
produces a specification of storage structure (relative
storage representation of data structure components,
connections, and boundaries) as well as the storage
assignment processes which will map the storage
structure into absolute storage. Like the data structure
designer, the storage structure designer is a problem
definer; the problem is storage assignment. The storage
assignment processes and information required by those
processes must be defined and run through the design
algorithm.
The process structure designer organizes the original
problem-defined processes, the logical access processes,
and the storage assignment processes and generates
program specifications. How the logical access processes
are represented in programs depends on how the storage
structure and storage assignment processes have been
designed. How the storage assignment processes are
represented in programs depends on the characteristics
of the absolute storage of the IPS.
In the context of this general picture of the design
process only the specification of data structure and
storage structure is considered below. An initial attempt
at a method of generating alternative designs is
described. The purpose of this attempt was to gain an
understanding of what decision points are involved. No
1. For each component of the given set, if the
component is not a data item then apply Process
D recursively.
2. Define connections among the components of the
given set.
3. Define a boundary from among the given
components.
The process assumes all instances of a component are
structured alike. A component may be a data set
component or, in a repeating group, a data structure
instance. The result of an application of Process D to
INV, yielding a structure similar to that in Figure 5d,
is given in Figure 10. Note that redundancy ofWHNO
and CITY will be maintained here while in Figure 5d it
is not retained.
Suppose now that Process D has not been applied to
INV. Suppose one wishes only to reduce redundancy.
Reduction of redundancy may be accomplished in the
following way:
Process R
1. Partition the original set according to the data
values of instances of one or more components.
A partition element is a subset of the original set.
In a partition element each criterion component
maintains mUltiple instances of the same data
value.
2. Replace the partition element by a new element
in the following way:
a. one instance of each criterion component
replaces the multiple instances;
b. the remainder of the original subset is grouped
by itself as a separate element.
The replacement operation will be called here
truncation. The remainder will be called the truncated
set. Figure 11 develops from Figure 4 a partition and
truncation of INV according to the values of WHNO.
The deleted component instances are blacked out. As in
Figure 4 rows represent (unordered) data set elements
and columns represent (unordered) data set components.
Automatic Design of Data Organization
In Process R step one establishes which redundancies
may be reduced in step two. The partition in Figure 10
establishes the redundancy of WHNO by definition;
redundancy of CITY is established because the problem
definer specified only one CITY instance per WHNO
instance. The truncation operation performs the actual
redundancy reduction. Neither, one, or both of WHNO
and CITY may have redundancy reduced. In Figure 11
both were chosen.
These operations may be extended. A sequence of
partitions leads to several levels of redundancy reduction. The sequence of partitions establishes a set of
candidates for redundancy reduction at each level. The
candidates are the criterion components established at
that level or above and other components which are in
one-to-one correspondence to criterion components.
Starting at the deepest level and working upward, the
design process can decide which candidates to choose
for redundancy reduction. For a given candidate to have
its redundancy reduced to a minimum its redundancy
, must be reduced at each level from the deepest up to the
level at which it originally entered the set of candidates.
If its redundancy is not reduced at the deepest level then
its full redundancy is maintained. Partial redundancy
for a component is established by not selecting the
component for reduction at some level in between. Once
the component fails to be chosen it drops out of the set
of candidates; its redundancy is fixed.
This expanded redundancy reduction scheme at each
level factors out selected components to the next higher
level and leads to a hierarchical form of organization.
The scheme may be combined with Process D above to
form Process DS:
Process DS
1. Define n-Ievel partition.
2. For level n, n-l, ... , o.
a. Define a truncation at this level.
b. In the truncated set.
1. apply Process D with data set components
and, possibly, truncated sets as
components.
ll. apply Process D with truncated set
elements as components.
Operation 2.b.i specifies the structure of an element
of a repeating group or data set. Operation 2. b.ii
amounts to specifying the structure of that repeating
group. Once a component or truncated set has been
structured it is a data structure component.
Figure 5d shows the pattern resulting from one
application of Process DS to INV. Figure 12 shows the
197
,
~----------DN
r--- S'1'OCJ( ~
WHNO
parti tion
I~
element " -
I~_"
205
rO l
til
k=l
'---v-----'
'----v-"
Retrieval of Retrieval of
index record data record
If the top level is not contained within a single block,
the mean retrieval time will be a function of the number of blocks comprising said level, and the search
strategy employed. Under these circumstances, the
results of Equations 3 or 7 may be applied, together
with Equation 9, to obtain an expression for Tr •
.-
05=t-
az=l -
j
,
I
!
I
r~som3Hi-TvL
CASE STUDY
The results derived in the preceding section may be
used to establish the relative merits of the several
techniques. To illustrate this procedure, a hypothetical
application is presented in the form of a brief case study.
It is assumed that the file in question consists of m
records. The index file (s), with the exception of the
top level (Case III), are maintained on a drum while
the main file is kept on disk. The block size is fixed (for
all devices) at 1024 bytes. It is further assumed that
the data records are 512 bytes in length; a retrieval thus
involves a single disk access. Index records are 16 bytes
in length (12 bytes for the key plus 4 bytes for the
address). Therefore each block has a capacity of 64
index records (b = 64). The drum and disk are characterized by the following parameters:
Drum
Mean Latency
Data Transfer
OO&=!.-----
11 = 17
Xl
msec
.43 msec
Figure 6-Number of index levels (Case III)
or more, the advantage of the binary search
considerable.
IS
Case II: Calculated index
In this case, the index file is organized as a random
file. Where linear probing is employed, the m records
are distributed over n blocks. With block chaining,
n' = n+ tl.n blocks are allocated. Figure 8 describes the
variation in Tr as a function of m/nb. The utilization
factors, U (Linear Probing) and U' (Block Chaining)
are likewise plotted in Figure 8. For a utilization factor
of .80, the mean time to retrieve a record, assuming
Linear Probing, is 109.1 msec. With Block Chaining
(and a utilization' of .80) the retrieval time is 115.2
msec. Note that in either case, the retrieval time is independent of the size of the file, dependent instead on
the ratio m/nb where n is controllable via T.
Disk
Mean Seek
Mean Latency
Data Transfer
82
12
X2
msec
=75
=12.5 msec
= 4.16 msec
Case I: Spatial index
In this case, the index file is organized as a sequential
file-a physically contiguous string of blocks containing
the m index records, ordered by key. We assume for
the sake of example that the mean occupancy of a
block is 50 records. This corresponds to a utilization of
roughly 80 percent (U ~ .80). Under these circumstances, the mean time required to retrieve a record is
described in Figure 7. For files of 30,000 records
Case III: Tabular indices
In this case, K sequential index files are maintained.
It is assumed here that K is selected so that the top
level index is contained entirely within a single block.
Assuming a utilization factor of .80, K is obtained as
the solution to the following inequality:
50K -
1
< m ~ 50 K
(10)
We further assume that the top level index (a single
block) is kept in core. The time spent searching the
top level may therefore be neglected. Hence, the mean
retrieval time is given by
Tr= (K-1) (ll+Xl) +
(82+12+ x 2)
(11)
206
Fall Joint Computer Conference, 1970
v
,.
J
/
~
-" ~
~
~
~
/
r.r
~
~
~
~SEMCH
~H
b=84
U~.•
,e'
,t'
,t'
m NUM8ERCJ= RECatOS
Figure 7-Mean retrieval time (Case I)
Figure 9 describes the variation in Tr as a function of
m. For example, when 2,500
!!!
a:
I-
w
a:
o
CylinderN
100
I-
w
~
~::~: ~~--,<--'<;----;
i=
~::~; ~~~.>,----,<---;
Number of Records = 50,000
~::: 1 p...,"'--r'-T~"""'--i"-T.>....j
Cylinder Overflow
Index
No Master Index
l--'-1--'--'--'L.LJ-.LJ
U = random keys
S = sorted keys
IC = insertion (write-checks included)
CC = change (write-checks included)
10T--r---------~-----,------------~----
100
1000
NO. OF RECORDS TO BE RETRIEVED
Master Index
Figure 1
211
212
Fall Joint Computer Conference, 1970
50
I8
40
~
~
........
....
--.....
-- --- -
- - _ _ U,I
II:
8w
II:
§
............
(a) number of index levels, (b) device placement of index
levels, (c) device placement of data, (d) block size of
data, .(e) amount of overflow, (f) device placement of
overflow, etc. Parameters which are fixed for a specific
. file design include (a) actual method of access-direct or
buffered sequential, (b) number of buffers, (c) type and
number of transactions, (d) file size, (e) record size, etc.
The paper is divided into three sections and an
appendix. The sections are:
a. The characteristics of direct access through the
indexes;
b. The characteristics of sequential search of the
data;
c. A comparison of the two methods.
30
w
>
w
C
t;
II:
e
w
!
20
Number of Records .. 50,000
Cylinder Overflow
No Master Index
U .. random keys
S .. sorted keys
0" retrieval
I - i~
C - change
---------
~ __ - - -
---------U.Q
_---
_----
~
S.C
S.Q
The appendix of the paper presents comparisons of
model runs with actual computer runs to illustrate the
accuracy attainable with the model's approach.
10
o+-----~------r-----.------,------~--50
40
30
20
10
50
PERCENT OVERFLOW
.............
Graph 2
.gives, for the first time, an indication of the complex
behavior of an actual data management access program.
FOREM I, which was used for the study, contains
300-500 FORTRAN statements dealing with the
analytic evaluation of access time and storage layout for
different parameter values. Each run consumes on the
average about 10 seconds of machine time and a few
minutes of designer set-up time.
40
I
~
................
-
.......- - _
---------
.......ndex
Cylindar Overflow
30
II:
8w
II:
§
Number of Records = 50,000
I -h:tsert
C'"' c:hange
0- retriewl
S .. sorted keys
U" r.ndom keys
III
>
W
...wC
...wo
20
---------
U,C _ - - - -
----------S,C
U,Q
II:
The indexed sequential access method is one of the
few fundamental, qualitatively different access methods
(sequential, direct, and perhaps chained access being
other possibilities). It is based on data and a hierarchy
of indexes that are sequenced on a particular identifier.
The method has been programmed by manufacturers
and users in a number of specific implementations. In
Figure 1, we present the physical storage layout of one
specific implementation. Its variable parameters include
_---
s,o
:IE
i=
THE INDEXED SEQUENTIAL ACCESS
METHOD
U,I
10
o+------.------.------.------~----~--10
20
30
40
50
PERCENT OVERFLOW
Graph 3
Analysis of Complex Data Management Access Method
213
DIRECT INDEXED ACCESS
In direct indexed access, the data management
routine is presented with the identifier of a particular
record. The identifier is compared sequentially ~gainst
the key entries in the highest level index. When the
identifier is matched, equal or low, descent is made to a
section of the next lower level index by means of an
address pointer associated with the appropriate key. At
the track level index, for every prime track* there are
two index entries: one containing the highest key in the
prime track and one containing the highest key of the
overflow associated with the prime track. Search of the
prime track involves sequential processing of blocked
records on the track. Search of the overflow involves
following chains through the records that have been
pushed off the prime track by insertions. The critical
500
---
..... -------
Cylinder Overflow
Master Index
Number of Records '" 1,000,000
U" random keys
S '" sorted keys
a '"retrieval
I .. insert
C = change
w
>
w
ii:
~
e
200
w
------~'£...------
------s:-C-U,Q.
:I;
..... . . -
--
_----
s,a
j::
100
o+-----~----~------~----~------
600
jg
-_
----
10
20
30
40
__--__
50
PERCENT OVERFLOW
................. .!!:.,I---
500
--Graph 5
z
8w
S!!
~
400
~
~
________
~----
U..Jl. - - - - -------s,C
8
~
I _________________~~~a~-------300-1-
w
>
w
Cylinder Overflow
No Master Index
Number of Records = 1,000,000
U = random keys
S = sorted keys
I = insert
C = change
a = retrieval
~
Gi
a:
200
~
w
:i
i=
100
Ol+-----.-----.------.-----r----~--------
10
20
30
40
50
PERCENT OVERFLOW
Graph 4
* A prime track is a track dedicated during the loading process
to contain data records whose keys fall within a particular value
range. When inserts are made and no space is available, records
will be pushed off the track into an overflow area. These records
are said to be overflow records.
parameters which we studied were:
1. File size (two files: 50,000 and 1,000,000 records);
2. Number and placement of index levels (Master
Index (MI = 1\1), no master index (None), and
master index in core (MC»;
3. Overflow configurations:
a. Overflow in the same cylinder as the prime
track or cylinder overflow (IE);
b. Overflow in the same pack (I B) ;
c. Overflow on a separate pack (IS);
4. Percent of overflow (eleven values: 0-50 percent
at 5 percent intervals);
5. Transaction types (query (Q), change (C or CC),
and insert (I or IC». (The second C indicates that
a write check is made.)
6. Input key stream (random SU = U or sorted
SU = S);
7. Number of records retrieved.
The records were 725 bytes long and were stored in
unblocked form on an IBM 2314 disk storage device.
The indexes were on separate packs from the data and
214
Fall Joint Computer Conference, 1970
Index structure
400
............
'
........ ...............
----
- - - . _ U,I
en
a
z
o
(,J
w
~
U)
a
300
u:
8w
u:
~w
>
w
~
I-
,--
200
~----
U,Q_-----
u:
o
w
:E
--- .....
Cylinder Overflow
Master Index in Core
Number of Records = 1,000,000
S = sorted keys
U = random keys
I = insert
C = change
Q = retrieval
w
I-
......
Index structure tradeoffs can be considered by
consulting Graphs 2, 3, 4, 5 and 6. Graphs 2 and 3
indicate that a master index* is not useful for a small
file while Graphs 4 and 5 indicate that the opposite is
true for large files. This in itself is a relatively obvious
conclusion, however, the location of the decision point
between the two file sizes is of more interest. This
decision point depends on whether index entries are
placed in full track blocks (for performance) or in
smaller blocks (to conserve core storage). Forfull track
blocking with reasonable key sizes, a master index
becomes useful only after the cylinder index exceeds four
tracks in length (for an IBM 2314, this is equivalent to
seven disk packs). At the other extreme, where each
-------~
i=
S,Q
",
70
Ol+------.------.-------r------r------~--50
40
30
20
10
-------
U,I _ . . . - " "
60
PERCENT OVERFLOW
Graph 6
,.,. . /
.,/
./
en
0
z
0
50
(,J
w
~
U)
0
u:
processing time for the qualified records was assumed to
be negligible. Even though it was apparent that a large
number of model runs were involved, it is also clear from
the immediately previous .statements that all possible
parameters were not varied.
0
(,J
w
40
u:
8
w
>
w
~
Overflow in same Disk Pack
No Master Index
Number of Records = 50,000
U = random keys
S = sorted keys
I = insert
C = change
Q = retrieval
30
I-
w
u:
0
I-
w
:E
N umher of records retrieved
Graph 1 indicates the general behavior of various
transaction types as the number of records retrieved in
a transaction is varied. In the unsorted key case, the
average time per record remains constant, independent
of number of records; the· sorted key case diverges from
this curve because the access .arm requires smaller and
smaller steps to transverse the data disk pack as more
records are retrieved. In these runs, index blocks were
not buffered so the divergence is not as great as it would
be if the access arm on the index pack could march
across the index files .also. Insert requires more time
than change because records must normally. be moved
to make room for the inserted record.
i=
u,.,S...-
20
-
---- -- --
----~.-_-sC
...-"'-
,...
...
,... ......... ..".
10
O+------.-------r------~----~------_r_
10
20
30
40
50
PERCENT OVERFLOW
Graph 7
* Master index is an index to the cylinder indexes (Figure 1).
Analysis of Complex Data Management Access Method
entry occupies a separate physical block, the decision
point lies at two cylinder index tracks (corresponding to
about one-half of a 2314 disk pack). For the large file,
the differences between these choices can be quite
significant:
a. master index, full track index blocking 1'-'130
seconds;
b. no master index, full track· index blocking 1'-'300
seconds;
c. no master index, one index entry per block
1'-'1600 seconds.
.,..,. / /
700
------
U.I,,"""
-'-'~
600-r--------
500
ii:i
o
z
oo
w
The permanent storage of the master index in core
provides an additional 20 percent improvement over
case (a) (Graph 6).
215
~
(I)
o
~
ow
400
Overflow in same Disk Pack
Master Index
Number of Records = 1.000.000
U = random keys
S = sorted keys
I = insert
C = change
= retrieval
a
a:
~
w
>
w
a:
/
/
50
/
,.,..,..,.",
300
/
I-
/
w
a:
~
w
::?!
/
i=
U.I//
200
---------~
--- ----
U C..,,"""
.",..
'''./
__ -- ....,.,-"
U.q......."..,
__ _ ' - -
,.,.
..--"
""
S.O
-S.C
40
ii:i
100
0
z
0
0
w
~
(I)
0
a:
30
0
0
w
a:
8
w
>
w
a:
~
w
a:
20
Overflow in different Disk Pack
No Master Index
Number of Records = 50.000
S = sorted keys
U = random keys
I = insert
C = change
a = retrieval
------
10
/"
20
30
40
50
PERCENT OVERFLOW
//
/
.",/
U.C,,/
./
O~""" . /
Graph 9
_ ..,,""G."
___----'
0
04-------~------r_------r_----~r_----~
....,.,""
S.C
~
w
::?!
Overflow configuration
i=
10
O+-------~------r------,------~------_r_
10
20
30
PERCENT OVERFLOW
Graph 8
40
50
Graphs 7-10 supplement Graphs 2 and 5 (the most
desirable index configuration for IE) to provide a picture
of performance behavior by overflow configuration. In
all overflow cases, the numbers of logical and physical
records per track are significant parameters in predicting
performance.
All operations are affected·by the number of ·logical
records per track; even small percentages of overflow
result in long overflow chains when there are onehundred or more reCords per track. On the other hand,
the number· of physical records per track primarily
216
Fall Joint Computer Conference, 1970
advantage is somewhat compromised by the sensitivity
of this configuration to insertions that are not uniformly
distributed over all the cylinders. Since enough space
must be reserved in every cylinder to hold the maximum
number of inserts per any cylinder, there can be
extreme space wastage in those cylinders which have
little insertion activity. This problem can, of course, be
eliminated by combining IE with one of the other
overflow configurations, on same pack (IB) or on
separate pack (IS), to handle unusually dense insert
activity.
The differences between same pack and separate pack
are less significant than their differences with respect to
cylinder overflow. In general, performance will be worse
than separate pack for small amounts of overflow, but
500
400
iii
c
z
0
u
w
~
en
C
a:
0
u
w
300
Overflow in different Disk Pack
Master Index
Number of Records = 1.000.000
U = random keys
S = sorted keys
I = insert
C = change
= retrieval
a
",
a:
~
U.~'"
w
>
w
a:
~
w
a:
0
./
250
/
200
~
w
:E
i=
----
"
" ,,'"
" ", "
..".," u.a....... '"
........
..".,"S.C
'"
Number of Records = 50.000
----- -----
----
200
iii
c
z
ou
100
w
!e
en
c
a:
o
u
w
a:
10
30
20
40
50
8
w
PERCENT OVERFLOW
>
~
150
~
w
a::
Graph 10
~
w
:E
OVERFLOW IN SAME CYLINDER
j::
infiuences insertion behavior. When room must be made
for inserts on the prime tracks, the following records
must be rewritten block by block until the last record is
pushed into overflow. The penalty for rewriting large
numbers of physical blocks on the prime track is so
drastic that performance generally improves as overflow
initially increases, because insertion into overflow is less
costly. The surprising fact is that insertion performance
will normally improve until the number of blocks in the
overflow chain is twice the number of blocks on the
prime track.
As expected, cylinder overflow (IE) generally provides
the best performance because no additional arm motion
is required to access the overflow area. This performance
100
o
L-____~~--__~------~------~----~
10
20
30
PERCENT OVERFLOW
Graph 11
40
50
Analysis of Complex Data Management Access Method
217
small. In the case of separate pack overflow, the initial
and subsequent arm motions will average one-half the
number of cylinders in the overflow. For amounts of
overflow exceeding one-half pack in size, these longer
subsequent motions will dominate performance.
1,000
iii
o
z
8w
100
~
en
Designing a file with overflow
o
a:
8w
a:
w
>
w
a:
~
w
a:
~
10
Cylinder Overflow
No Master Index
Overflow =0%
w
:E
i=
Number of Records = 50,000
100
10,000
t,OOO
100,000
NO. OF RECORDS RETRIEVED
It is generally believed that overflow hampers
performance. In fact, since insertion performance often
improves with increased overflow, optimum total
performance may be obtained when there is a certain
amount of overflow in the file. The optimum can be
determined by weighting each of the individual curves
for retrieval, update, and insertion by the percentage
of transactions of that type. When the curves are added
together, the minimum on the total curve will lie at the
optimum overflow percentage.
For example, in the case of the small file without a
master index, we will assume that all transactions
Graph 12
15~----
_____________________________
eventually "will be better for very large amounts. This is
because the initial arm movements to overflow for same
pack overflow will be across half the prime area and a
portion of the overflow. Arm movements for chain
following inside the overflow area will be relatively
(2)
en
o
z
8
w
1,000
~
(4)
10
en
o
It:
o
U
w
It:
~
(8)
«
(16)
en
a:
w
iii
0
z
w
>'
w
0
()
w
!!!
100
~
0
It:
0
o
()
w
a:
w
>
w
~
w
5
:I
i=
a:
~
w
a:
0
~
Cylinder Overflow
No Master Index
10
Cylinder Overflow
No Master Index
Overflow = 25%
w
:E
i=
Number of Records =50,000
Number of Records = 50,000
100
1,000
10,000
NUMBER OF RECORDS RETRIEVED
Graph 13
100,000
0+------,-------r------.------,------'25
o
5
10
15
20
PERCENT OVERFLOW
Graph 14
218
Fall Joint Computer Conference, 1970
15(2)
30
15(4)
15(8)
15(18)
IB (2)
iii
o
z
o
~. 20
IB (4)
fh
18 (8)
IE:
IB (18)
~
o
8
w
IE:
~
w
>
w
a:Iw
IE:
~
~ 10
t=
Number of Records .. 50.000
Number of BufferS in bnckets
No MISter Index
IS .. Overflow in different Disk PlICk
IB .. Overflow in same Disk PlICk
expensive if there are a large number of blocks on the
prime track. Nonetheless, it is especially needed in
insertion to protect the correctness of the rewritten data.
THE BUFFERED SEQUENTIAL ACCESS
PROCESS
In this process,. the ·system is presented with an
identifier and finds, by means of an index search, the
location of the record having that identifier or the next
highest identifier. At this point, it begins a buffered
sequential search of the data, pausing at the end of each
prime track overflow area to access the track index.
For this study, we have assumed a particular implementation. That is, on the prime track, one-half the
total number of buffers may be active in a chained read
or write operation at anyone time. If the total number
of buffers is equal to twice the number of physical
blocks on a track, then a complete track can be read or
written in one revolution. Overflow tracks, on the other
hand, are accessed one physical block at a time. When
there is contention for reading and writing services, the
principle of first-in-first-out is applied.
15(2)
o+-----~------.-----~------._----_.------~
o
10
20
30
40
300
50
15(4)
PERCENT OVERFLOW
15(8)
15(18)
Graph 15
involve 100 qualified records, and transactions are
evenly distributed among updates, retrievals, and
insertions with random as well as sorted keys. Graph 11
presents total performance curves for the three types of
overflow allocation in the small file. Cylinder overflow
(IE) performance is optimum with 25-45 percent
overflow and separate pack overflow (IS) performs best
at 10-15 percent overflow. The optimum for same pack
overflow (IB) generally occurs at zero percent overflow.
IB(2)
iii
o
z
8w
IB(4)
200
IB(B)
~
en
o
IB (16)
IE:
8w
a::
§
.n
w
>
w
ii:
Master Index
Number of buffers in brackets
Number of Records = 1,000,000
1S .. OVerflow in different Disk Pack
IB .. Overflow in same Disk Pack
I-
w
General
e
In all test cases, the indexes and data were on
different disk packs; and record accesses driven by
random key input strings took significantly longer than
accesses driven by sorted key input strings. These
differences would be marginal if the indexes and data
were located in the same pack.
While update-in-place characteristics with or without
write-check are very similar to retrieval characteristics
since they involve only one or two added disk rotations,
the use of write-check in record insertion creates
entirely different characteristics. It can be extremely
w
2!
a::
100
t=
O+-----~------~-----r----~r-----~
10
20
30
PERCENT OVERFLOW
Graph 16
40
50
Analysis of Complex Data Management Access Method
219
Number of records retrieved
Graphs 12 and 13 indicate the general performance
behavior of the access process for various numbers· of
records retrieved. For a given number of buffers and
large numbers of records retrieved, it is an unexceptional
linear function. These curves will, however, become
more horizontal for fewer numbers of records, because
the initial index search will be a more important factor
in average access time per record. For similar reasons,
the device placement of the indexes is only significant
when small numbers of records are accessed.
While the effect of the number of buffers will be
discussed later, it. is interesting to note that large
numbers of buffers are most useful for small· amounts
of overflow.
28
24
22
20
iii
0
z
18
~
18
8
en
0
c
8
'"
'">
'"
i:
'"c
0
~
~
'"2
t=
Overflow configuration and overflow percentage
Graphs 12 and particularly 13 and 14 indicate that
sequential performance is significantly affected by the
amount of overflow present in the file. Arm motion to
and in the overflow area is primarily responsible for the
rapid change in performance characteristics.
The slope of the cylin4er overflow (IE) curves is
determined by the differences in access time between
14
c
12
10
No Master Index
Overflow in same· Disk Pack
Overflow = 25%
Number of Records = 50,000
8.
8
4
2
0
100
200
300
400
500
NO. OF RECORDS READ (100 UPDATED)
Graph 18
No Master Index
Cylinder Overflow
Overflow = 25%
Number of. Records = 50,000
I
100
I
I
I
I
200
300
400
500
NO. OF RECORDS READ (100 UPDATED)
Graph 17
prime area records and overflow area records. This,
in turn, is determined by the number of records that can
be retrieved in one revolution from· the prime area
because accessing in the overflow area is always at one
record per disk revolution. The primary factors in this
determination are prime area record blocking and
buffering. The slight downward slope of the·· cylinder
overflow (IE) curve for two buffers is due to the fact
that larger numbers of overflow records reduce the
necessity for reading index tracks.
The knee in the pack overflow (IB) curves will occur
at the overflow percentage where there is one overflow
record per prime track. In these tests we have assumed
that the overflow records are uniformly distributed over
the. prime tracks; if we had not, then the knee in the
curve would be less sharp. As can be seen for the present
experimental configuration, pack overflow begins to
outperform separate overflow· (IS) when each prime
track .has about three overflow. records associated
with it.
Buffers and update performance
In ,the case of retrieval discussed above, any increase
in the number of buffers always causes the timing curves
to shift downward, but parallel to their prior locations
220
Fall Joint Computer Conference, 1970
·22
20
18
en
0
.z
0
16
0
w
!e
en
0
14
a:
0
0
w
12
a:
w
>
w
10
w
8
a:
Ia:
0
I-
w
:E
No Master Index
Overflow in different Disk Pack
Overflow = 25%
Number of Records = 50,000
6
t=
4
file, the designer may use either basic direct or buffered
sequential search. We provide here an example
situation.
If the overflow for the small file is organized on a
cylinder overflow (IE) basis and the input keys are
sorted, the basic direct access method will require 10
seconds to access 100 records. (See Tables I and II.) The
queued sequential access method, using 10 buffers, can
retrieve about 1,000 records in the same time. In this
case, if better than one record in 10 is pertinent to the
query and processing time is insignificantly small, then
sequential access will provide better performance.
Generally speaking, if p is the number of records
which must be read sequentially to find a qualified one,
tq , the average time to read a record in buffered
sequential mode and tb, the average time to read a record
in basic random mode, then the queued mode is more
efficient if tb > P etq • (This formula is most appropriate
2
0
100
200
300
400
500
Retrieval & Update Time (sec.)
NO, OF RECORDS READ (100 RECORDS UPDATED)
Table I
Graph 19
(Graphs 12 and 13). When some fraction of the records
are updated, and therefore rewritten, there need not be
a regular increase in performance as the number of
buffers is increased.
In Graphs 17, 18 and 19, as the number of buffers is
increased from 2 to 8, the time to read x records and
update y ~ x of them decreases regularly. However,
a further increase up to, but less than, 16 buffers reduces
overall performance. The reason for this phenomenon
lies in the interference of seeks for reading and writing
of data. When the capacity of the buffers available is
less than, or equal to, one-half of a track (in this case,
8 buffers or less), the access system can both write and
read n/2 blocks in a single revolution (n is the number
of buffers available). These two operations cannot be
smoothly interspersed when ~ track < the capacity
of the buffers < 1 track.
In the above runs, the record processing time was not
a significant factor. If processing time is significant, then
instances will occur where the 2 buffer configuration will
perform better than the 8 buffer one. A detailed analysis
of these situations is quite involved and is best
performed by simulation models.
GENERAL CONSIDERATIONS
overflow
0
5
10
25
0
5
10
25
s
QISAM
BISAM
retrieve 500 records
retrieve 100 records
IE
IS
IB
4.2-15
4.2-15
4.2-15
IE
IS
IB
10(s)
10(s}
10(s}
15(u)
15(u}
15(u)
lO(s)
10(s}
l1(s)
4.7-15
5.7-16
8.4-18 15(u)
I
15(u}
161u)
10(s)
10(s}
l1(s)
5.1-15
7.3-17
13-23
15(u}
15(u}
16(u}
10(s)
12(s)
14(s}
6.4-15
12-21
15-23 '16(u)
17(u)
19(u)
retrieve 500 records
update 100 records
update 100 records
13(s}
13(s}
4.7-15
4.7-15
4.7-15 13(s)
18(u)
18(u)
18(u)
13(s)
13(s}
13(s}
5.4-15
6.5-16
9.9-19
18(u)
18(u}
18(u)
13(s)
13(s}
14(s)
6-15
8.5-17
19-25
18(u)
18(u)
19(u)
13(s)
l4(s)
16(s)
7.8-15
15-22
21-26
18(u)
19(u)
21(u)
= sorted
i
!
keys
u - unsorted keys
No Master Index
number of records = 50,000
IS - Overflow in different Disk Pack
IB - Overflow in same Disk Pack
IE - Overflow in same Cylinder
Choice of access method
In certain special cases, particularly when the records
relevant to a search are confined to a small area of the
Table I
Analysis of Complex Data Management Access Method
when there are many· records to be read because the
initial reading of the index in buffered sequential mode
can affect tq substantially.)
To approximately determine tq , let b be the number
blocks per data track and T the track revolution time.
Assuming the minimum number of buffers,
Retrieval.
overflow
ro.J4T+2Te
(cylinder index and data on
separate packs)
(cylinder index with data)
40-146
5
44-146
64-190
85-189
10
49-148
92-190
: 138-237
25
61-149
160-242
I 155-237
0
45-146
45-146
45-146
5
51-146
95-190
!I 101-193
10
59-148
152-241
1199-256
25
76-149
191-264
1
Master Index Exists
(cylinder index with data)
s ,. sorted keys
Variation of hardware parameters
The results presented in this paper are for a particular
device; it is, however, of interest to understand the
effect of changes in hardware parameters, such as access
arm speed, track size, rotational speed and processor
speed.
Of these parameters, access arm speed is the most
independent of the others in its effect on performance.
In the basic access method for typical configurations,
a 100 percent increase in arm speed will result in about
a 20 percent improvement in total performance. While
increased arm speed will, significantly narrow the
difference in performance between the direct indexed
access processes for various overflow schemes, sequential
performance will only be affected when large amounts
of overflow exist in pack and separate overflow
configurations.
Track size, rotational speed, and central processor
speed do, however, interact in a complex fashion with
regard to the loss of revolutions. Increases in CPU speed
generally will result in no performance deterioration and
they may improve performance by saving previously
IE
13O(s)
176(u)
13O(s)
176(u)
13O(s)
177(u)
133(s)
180(u)
222-267
I
IS
I 13O(s)
176(u)
132(5)
:
180(u)
138(s)
183(u)
156(5)
: 204(u)
IB
13O(s)
176(u)
136(s)
180(u)
143(s)
190(u) .
169(s)
214(u)
update 1000 records
\
154~s)
202(u)
154(5)
202(u)
154(5)
202(u)
158(s)
205(u)
I
154~s?
202(u)
1 157(5)
. 204(u)
161~s)
208(u)
181(s)
229(u)
154~s)
202(u)
161(s)
208(u)
168(s)
215(u)
194(.5?
240(u)
number of records - 1.000.000
(cylinder index and data separate)
where Tee is average cylinder search time in the cylinder
index. For the small file, we have N e = 1. Thus,
T~2X25+75+12.5~138. Reading 100 records in the
basic direct mode requires approximately 14 seconds as
confirmed by our measurement (Table I). Thus, if
p~5 to 10, then the buffered mode and the basic direct
mode provide similar performance.
IB
40-146
retrieve 5000 records
update 1000 records
i
t~4T+Te+Tee
IS
40-146
ms.
where Te is average cylinder search time of the file, and
N e is the number of cylinder index tracks.
BISAM
retrieve 1000 records
0
If the file has no master index, tb can be estimated by
~2T+2Te+(Ne·T)/2
QISAM
retrieve 5000 records
IE
The factor of 0.5 represents the cost of possible revolutions. Thus, in the case of the sample files, the time to
read a record is
t~2T+Te+(Ne·T)/2
Update Times (sec)
Table II
tq~(1.5XT)/b+T.
tq~(1.5X25)/8+25""30
&
221
u ,. unsorted keys
IS = Overflow in different Disk Pack
IB = Overflow in same Disk Pack
IE = Overflow in same Cylinder
Table II
lost track revolutions. Track size and rotational speed·
will normally result in gradual improvements in
performance, except in the cases where the CPU can no·
longer complete processing in time to access the next ..
record. These cases will result in major discontinuous
deteriorations in performance through lost revolutions.
Other parameter changes
The size of the records in a file influences performance
considerably. For smaller record sizes, the timing curves
will have a larger slope at all points and the intersections with the time axis will be lower. If the record
size is very small, a slight increase in overflow percentage will degrade performance tremendously. A
larger record size shows exactly the opposite effect. Here
the performance curves will intersect the axis at a higher
point and they will have less slope.
The number of records in a block or the blocking
factor also affects performance. A large blocking factor
will decrease storage space but it increases transmission
time. Small blocking factors decrease transmission time
but increase arm movement time. A thorough analysis
is again needed to determine optimum blocking.
222
Fall Joint Computer Conference, 1970
CONCLUSION
In this paper, we have presented a prototype parametric
study of the type that is almost mandatory for knowledgeable design of a complex file organization. This
study, which includes thousands of data points, would
not have been possible without a fast, accurate simulation model such as FOREM I. The results are presented
to give the reader an. indication of the intricate interdependence of the many parameters that he must
consider if he wishes to produce an excellent file design.
REFERENCES
1 F o'NrUJ,tted file organization techniques
Final Report Air Force Contract AF 30(602)-4088 May
1967
2 M E SENKO V Y LUM P J OWENS
A file organizatum evaluation model (FOREM)
IFIP Congress 1968
APPENDIX
This section presents comparisons of the model runs
with actual computer runs to illustrate the accuracy
Mode of
Retrieval
Overflow 2
Handling
Percent*
Overflow
Hodel
Result
(secs.)
Measured
Result
(secs.)
Model
Error
(percent)
File
creation
Sequential
retrieval
Sequential
ret=rieval
Sequential
retrieval
Sequential
retrieval
Sequential
retrieval
Sequential
r"':rieval
Sorted keyl
retrieval
Sorted key
retrieval
ind
0
cyl
0
10.9***
cyl
5.
16.6
16.1
3.11
cyl
16.1
30.0
27.9
7.52
~:~~~:v~? 'j
Sorted key
retrieval
Sorted key
retrieval
Sorted key
retrieval
Rand...
retrieval
Randoa
retrieval
Randoa
retrieval
Randoa
retrieval
Randoa
retrieval
Randoa
retrieval
Randoa
IIDdate
186.
ind
0
10.9***
ind
5.
45.5**
ind
16.7
82.1**
159.
8.51
8.64
17.0
28.1
26.1
36 •.9
23.3
69.2
18.6
cyl
0
422.
414.
cyl
5.
419.
414.
1.21
cyl
16.7
448.
451.
9.67
2.43
ind
0
422.
412.
ind
5.
457.
464.
ind
16.7
613.**
544.
1.93
1.51
12.7
cyl
0
790.
732.
7.92
cyl
5.
787.
744.
5.77
cyl
16.7
816.
773.
5.56
ind
0
781.
715.
9.2
ind'
5.
802.
752.
6.64
ind
16.7
922.
846.
8.98
915.
970.
6.01
cyl
0
1 - The keys of the records to be retrieved are sorted in ascending order and
retrieval carried outiq the order of, this reference.
2 - cyl means cylinder overflow (overflow records in same cylinder as prime
records). and
ind means independent overflow (overflow records in different cylinders
as prime records).
Appendix insert 1
Mode of
Retrieval
Random
update
J"ll threats to privacy, presently
available counter-measures, and the current operational environment.
3. Altering or destroying files.
4. Obtaining free use of system resources.
The nature of deliberate infiltration will be discussed
within the framework presented by Peterson and
Turn, l who established the following categories:.
A. Passive Infiltration
1. Electro-magnetic pickup (from CPU or peripheral devices).
2. Wiretapping (on communications lines or transfer buses).
3. Concealled transmitters (CPU, peripheral devices, transfer buses, communications lines).
B. Active Infiltration
1.
2.
3.
4.
5.
6.
7.
8.
THREATS TO PRIVACY
The challenges to the privacy of information in a
computer system may be accidental or deliberate; this
discussion relates specifically to deliberate challenges,
although the software developed may afford some
protection against the undesired consequences of
accidental compromise.
Browsing.
Masquerading.
Exploitation of trap doors.
"Between-lines" entry.
"Piggy back" infiltration.
Subversive entry by centre staff.
Core dumping.
Theft of removable media.
Browsing is defined as the use of legitimate access to
the system to obtain unauthorized information.
111asquerading consists of posing as a legitimate user
after obtaining proper identification by ~ubversive
means.
Trap doors are hardware or software deficiencies that
assist the infiltrator to obtain, information having
once gained access to the system.
Between-lines entry consists of penetrating the system
* Support of the Defence Research Board (Canada) and the
Canada Council, Social Sciences and Humanities Division is
gratefully acknowledged.
** Now with the Univac Division, Sperry Rand of Canada, Ltd.,
Ottawa, Ontario, Canada.
223
224
Fall Joint Computer Conference, 1970
when a legitima.te user is on a communications channel,
but his terminal is inactive.
Piggy-back infiltration consists of selectively intercepting user-processor communications and returning
false messages to,the user.
Directed
! Threat
Against
~
Passive
LINES,
Browsing
SYSTEM
..
Masquerade
Between-Lines
Methods to enhance privacy are roughly classified
as follows:
1.
2.
3.
4.
5.
Access control.
Privacy transformations.
Processing restr.ictions.
Monitoring procedures.
Integrity management.
Coun ermeasure
Privacy
Process. Threat
Integritl
IControl Transform Restrict Monitor "anage.
DEVICES
EXISTING COUNTER1\tlEASURES
,
IAccess
.
i
Nmo
•
•
NONE
.
GOOD
.
.
NONE
NONE
·
·
GOOD'
GOOD
GOOD
~NE
: FAIR
FAIlr
FAIR
GOOD
IFAIR
'NONE
GOOD'
FAIR
FAIR
~ONE
'NONE
FAIR
FAIR
FAIR
~ONE
~ONE
I
.
Trap-Doors
CPU
NONE
NONE
~ONE
FAIR
DEVIC,ES
FAIR
GOOD
IFAIR
·
Systems
CPU
NONE
NONE
INONE
NONE
Entry
DEVICES
FAIR
..
FAIR
Theft
CPU
IDEVIC,ES
..
~ONE
iGOOD
Piggy-Back
Core Dump
FAIR
.
..
~D
..
' NoNE
NONE
~ONE
GOOD
~D
,NONE
GOOD
!NONE
FAI,R
FooD
Figure 1-Threat-countermeasure matrix
Access control consists of authorization, identification,
and authentication and may function on the system
or file level. Authorization to enter the system or files
is generally established by possession of an account
number or project number. The user may be identified
by his name, terminal, or use of a password. The user
may be required to perform a privacy transformation
on the password to authenticate his identity. Peters2
recommends use of one-time passwords.
Passwords may also include authority codes to
define levels of processing access to files (e.g., read
only, write, read-write, change protection).
Privacy transformations include the class of operation
which can be used to encode and decode information
to conceal content. Associated with a transformation
is a key which identifies and unlocks the transformation to the user and a work factor, which is a measure
of the effort required of an infiltrator to discover the
key by cryptanalysis.
Processing restrictions include such functions as provisions to zero core before assigning it to a second user,
mounting removable files on drives with disabled
circuitry that must be authenticated before accessing,
automatic cancellation of programmes attempting to
access unauthorized information, and software which
limits access privileges by terminal.
lJIlonitoring procedures are concerned with making
permanent records of attempted or actual penetrations
of the system or files. Monitoring procedures usually
will not prevent infiltration; their protection is ex post
facto. They disclose that a compromise has taken place,
and may help identify the perpetrator.
Integrity management attempts to ensure the competence, loyalty, and integrity of centre personnel.
In some cases, it may entail bonding of some staff.
EFFECTIVENESS OF COUNTERMEASURES
The paradigm given in Figure 1, grossly abridged
from Peterson and Turn, characterizes the effectiveness of each countermeasure against each threat.
We independently investigated each cell of the
threat-countermeasure matrix in the real-time resourcesnaring environment afforded by the PDP-I0/50 at
Western (30 teletypes, 3 remote batch terminals).
Our experience 1eads to the following observations:
Passive Infiltration: There is no adequate countermeasure except encipherment and 'even this is effective only if enciphered traffic flows on the bus or
line attacked by the infiltrator. Competent, loyal
personnel may deter planting wireless transmitters
or electromagnetic pickups within the computer centre.
Browsing: All countermeasures are effective; simple
aCcess control is usually adequate.
Masquerading: If the password js compromised, most
existing countermeasures are rendered ineffective. Use
of authentication, one- time passwords, frequent change
of password, and loyalty of systems personnel help to
preserve the integrity of passwords. Separate systems
and file access procedures make infiltration more difficult, inasmuch as two or more passwords must be
compromised before the infiltrator gains his objective.
Monitoring procedures can provide ex post facto analySIS.
Between-Lines Entry: Only encipherment of files, or
passwords applied at the message level rather than for
entire sessions, provide adequate safeguards. 1\10nitoring may provide ex postfacto analysis.
Fast Infinite-Key Privacy Transformation
Piggy-Back Techniques: Encipherment provides protection unless the password is compromised. Monitoring may provide ex post facto analysis.
Trap-doors: There is no protection for information
obtainable from core, although monitoring can· help
in ex post facto analysis. Encipherment can protect
information contained in auxiliary storage.
Systems entry: Integrity management is the only
effective countermeasure. There is no other protection
for -information in core; even monitoring routines can
be overridden. Encipherment protects information in
virtual storage only to the extent that passwords are
protected from compromise.
Core dump: There is no effective protection except
integrity management, although monitoring procedures
can help in ex post facto analysis.
Theft: Encipherment protects information stored in
removable media.
Our initial study persuaded us that privacy transformation coupled with password authentication would
afford the best protection of information. Integrity
management procedures were not within the scope of
this research.
PRIVACY ENVIRON1VIENT: MANUFACTURERS
Our next task was to investigate the privacy environ-·
ment of resource-sharing systems. Five manufacturers
of equipment, doing business in Canada, participated
in our study. Their contributions are summarized in
the following points:
1. The problem of information security is of great
2.
3.
4.
5.
6.
7.
concern to all manufacturers of resource-sharing
equipment.
lVlost manufacturers are conducting research
on privacy; only a small minority believes that
the hardware and software currently suppli.ed
are adequate to ensure the privacy of customer
information.
The password is the most common vehicle of
system access control; dedicated direct lines
are recommended in some special situations.
At least two manufacturers have implemented
password authentication at the file level.
There appears to· be no customer demand for
implementation of hardware or software privacy
transformations at this time.
l\![ost manufacturers stress the need for integrity
management.
Two large manufacturers emphasize the need
for thorough log-keeping and monitoring procedures.
225
RESOURCE-SHARING SYSTEMS
Number
of .Systems
4
j
II
A.utho.ri.zation
Ident.ification
A.uthority
A.ccount t
Name
Password
Project f
3
A.ccou,nt t
3
Account t
Name
Password
-
Project .f
2
Account t
-
-
1
Account t
Name
Password
1
Project t
Name
-
-
Password
-
-
1
1
Project f
I
I
I
Figure 2-Access control in 16 Canadian resource-sharing systems
8. Communication links are seen as a major security weakness.
We next surveyed 25 organizations possessing hardware that appeared to be suitable for resource-sharing.
Sixteen organizations participated in our study, representing about 75 percent by traffic volume of the
Canadian time-sharing industry. From information
furnished by them, we were able to obtain a "privacy
profile" of the industry.
The average resource-sharing installation utilizes
IBM equipment (Univac is in second place). The typical system has over 512 thousand bytes of core storage
and 175 million bytes of auxiliary storage. The system
operates in both the remote-batch and interactive
modes. It has 26 terminals communicating with the
central processors over public (switched) telephone
lines.
In seven systems, authorization is established by
name, account number, and project number. Five
systems require only an account number. Nine systems
require a password for authority to enter the system;
the password is protected by either masking or printinhibit.
Identification is established by some combination of
name, account number, project number, or password;
in no case is identification of the terminal considered.
No use is made of one-time passwords, authentication,
or privacy transformations. In no system is a password required at the file level; seven systems do not
even require passwords. Access control prOViSIOns of
16 Canadian systems are summarized in Figure 2.
226
Fall Joint Computer Conference, 1970
Only two systems monitor unsuccessful attempts
to gain entry. In nine systems, both centre staff and
other users have the ability to read user's files at will.
In six systems, centre staff has unrestricted access to
user files. Only three organizations have implemented
integrity management by bonding any members of
'
staff.
The state of privacy, in general, in the Canadian
resource-shariIig industry, can be described as chaotic
and, with few exceptions, the attitude of systems
operators towards privacy as one of apathy.
PRIVACY TRANSFORMATION: FUNCTIONAL
SPECIFICATIONS
It was decided, therefore, to begin development of a
software system for privacy transformation that would
be synchronized by an authenticated password, anticipating that sooner or later some users will demand
a higher degree of security in resource-sharing systems
than is currently available. Such an authentication·privacy transformation procedure would afford the
following advantages:
1. Provide protection for the password on com-
munications channels.
2. Implement access control at the file level.
3. Obviate the need for storing passwords as part
of file headings.
4. Afford positive user identification since only
authorized. users would be able to synchronize
the keys of the privacy transformation.
5. Furnish "work factor" protection of files against
browsing, "between-lines" entry, "piggy-back"
infiltration, "trap doors" to auxiliary storage,
entry of systems personnel to auxiliary storage,
eavesdropping on transfer buses, and theft of
removable media.
The technique of privacy transformation that
seemed most promising was a form_ of the Vern an
cipher, discovered in 1914 by Gilbert S. Vernan, an
AT&T engineer. He suggested punching a tape of key
characters and electromagnetically adding its pulses
to those of plain text characters, coded in binary form,
to obtain the cipher text. The "exclusive-OR" addition
is used because it is reversible.
The attractive feature of the Vernan cipher for use
in digital systems is the fact that the key string can
readily be generated by random number techniques.
For maximum security (high work factor) it is desirable that-the cipher key be as long as the plain text
to be encrypted. However, if the flow of information
is heavy, the production of keys may place extreme
loads on the arithmetic units of processors-the rate
of message processing may then be too slow to be feasible. Two solutions have been proposed.
In the first, relatively short (e.g., 1,000 entries) keys
are produced and permutations of them used until
repetition is unavoidable. A second approach is to use
an extremely efficient random number generator capable of producing strings that appear to be "infinite"
in length, compared to the average length of message
to be transformed.
PRIOR WORK (SHORT-KEY METHOD)
An algorithm for a short key method presented by
Skatrud3 utilizes two key memories and an address
memory. These are generated off-line by conventional
random number techniques. Synchronization of an
incoming message and the key string is' achieved by
using the first information item received to address
an address memory location. The contents of this
memory location provides a pair of address pointers
that are used to select key words from each of the key
memories. The key words are both "excJusive-OR'ed"
with the next data item, effectively providing double
encryption of it. The address memory is then successively incremented each time another data item arrives. Each address location provides two more key
address pointers and each key address furnishes two
key words to be "exclusive-OR'ed" with the current
data item. Key word pairs are provided on a one-forone basis with input data items until the entire message has been processed. For decoding, the procedure
is completely reversible.
PRESENT WORK ("INFINITE" I(EY l\tlETHOD)
We decided to use the infinite key approach because it would:
1. Reduce storage requirements over those required by short key methods. This will tend
to reduce cost where charges are assessed on
the amount of core used; and, more importantly,
will permit implementing the transformation
on small computers (e.g., one having a 4096word memory) located 'V\1 f::; .. ;.;.
~1.1
47. "
~:..)
~
3
36. -3
B
3
J;J
':ECrlSEL3E;; GE'"
59.:::
5')
3
4
6
:;t}. '5
7J
I
4
:3
52.·~
5'3
~.•I:_{J
rr:,.J •
TE,·{. L.
-) I::
Y IU
ij"::
I
STJC-J
Ij~~5
H~~ DlSmI'1lJfI )'J .I? ::;C.)I'E!:; FH P·)ST-fESf
6 I -7:3
71-'5"1
) 11:>?]- 13:3
Figure 2-The output for section 1005 is shown to illustrate the
output produced by Program XN1 when the weekly post-tests
are scored
On Line Computer Managed Instruction
80 REt-l
TH I 5
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
720056,
720133,
721799,
722835,
723934,
724165,
724872,
725390,
725425,
725196,
726699,
726811,
721539,
727945,
728561,
728659,
728925,
117 73e921,
QUALITY EDUCATIONAL DEVELOPMENT
IS THE :XS F'ILE
3,
5,
1,
5,
5,
5,
5,
5,
5,
1,
5,
1,
5,
1,
1,
5,
5,
5,
43.4, 1,2,1,1,2,2,1,1,1,1
57.8, 2,2,1,1,1,2,2,2,1,1
47.3, 2,2,1,1,1,1,1,1,1,1
74.5, 2,2,1,2,2,2,1,2,1,2
28 , 1,1,1,1,1,1,1,1,1,1
39.2, 1,1,1,1,1,1,1,2,1,2
66.3, 1,2,1,2,2,2,1,1,2,2
64.8, 2,1,1,2,2,2,1,2,1,2
52.9, 2,1,1,1,2,2,1,1,1,1
91.9, 2,2,1,2,~,2,2,2,2,2
54.8, 1,2,2,1,1,1,2,1,1,2
63.8, 1,1,2,2,2,1,1,2,1,2
42. , 1,1,1,1,2,1,1,1,2,1
71.4, 2,1,2,2,2,2,1,2,1,1
59. , 2,1,1,2,2,2,1,1,1,2
53.6, 2,1,1,2,2,2,1,1,1,1
49.4, 2,1,1,2,2,1,1,1,1,1
39.8, 1,1,1,1,1,1,1,1,2,1
Figure 3-0ne of the section data files created by Program
XNl is shown. These files contain each student's I.D. number,
confidence score, and his response to each question on the test
COMPUTER ANALYSIS OF STUDENT PERFORMANCE
POST-TEST K
STUDEfH I D NUMBER
I
I
j
103
QUESTION 5, CORRECT
QUESTION 7 HROflG
Figure 4-A line from one of the data files (XI-X12) is annotated
to indicate the items stored
CURRENT AND RESISTANCE
ANALYSIS OF SCORES BY MEDIA
GROUP
0-60
61-70
SG
0
0
IB
0
1
AV
2
0
SO
0
2
TB
1
L
71-80
5
81-90
91-100
MEAN
2
13
91.1
6
12
89.7
3
6
8
87.
5
5
11
87.4
2
5
12
87.3
1
1
8
7
87.4
L/SG
a
2 •
4
11
88.8
CNTR
1
1
2
7
17
90.2
1
3
2
6
82.2
0
1
7
6
88.8
CAI-I
data files (Table II, data files XI-X12) for each section (Figure 3) which contained the student's identification number, group number, confidence score, and
his response to each question in coded form (Figure 4).
The identification or I.D. number is used to uniquely
identify each student's responses. This number is
stored along with the data and checked whenever
programs manipulate these numbers to ensure that
the responses of one student are not attributed to another student. These data files could then serve as
input for any variety of analysis programs.
235
CAl-II
1
Figure 5-The results of the analysis of scores by media group
is shown for Post-test K. This output is produced by
Program XN2
Two of these programs will be described here. The
first program (,fable I, Program XN2) accessed the
data files to produce an analysis of performance by
media group (Figure 5), and an analysis of performance
by question (Figure 6). It should be recalled that the
tests were scored by section since the section professors were responsible for student grades but the media
groups were randomly assigned independent of the
sections. It was thus necessary to perform analysis
both by section and by group. The data in the section
files (files Xl-X12), therefore, had to be analyzed or
sorted to determine the effectiveness of the different
media-mixes. The "analysis by group" sorted the student confidence scores by media-group. On a weekly
basis, the difference in performance by group was
generally small. Conclusions on the effectiveness of the
media-mixes must await an analysis of variance of
group performance during the semester. In addition,
the response of each student to each question was
sorted by computer· to determine the percent of the
students in each media group who missed each test
question. This "analysis by question" or item analysis
often showed distinct differences in performance by
the various media groups. As an example, consider
the results of the twenty-question test given at midsemester (Figure 7). Question one which tested an
236
Fall Joint Computer Conference, 1970
QUALITY EDUCATIONAL DEVELOPMENT
COMPUTER ANALYSIS OF STUDENT PERFORMANCE
POST-TEST K
CURRENT AND RESISTANCE
ANALYSIS: PERCENT OF STUDENTS WHO MISSED A QUESTION
QUES.
1
5G
15.
IB
4.35
0
AV
10.5
10.5
50
o
TB
4.35
L
o
L/5G
4.76
CNTR
CAI-I
3
9
10
20.
15.
21.7
13.
o
10.
25
15.
21.7
4.35
17.4
21.7
8.7
15.8
10.5
10.5
21.1
10.5
0
36.8
10.S
4.35
17.4
26.1
39.1
0
o
43.5
17.4
4.35
4.35
17.4
47.8
8.7
4.35
~O.4
17.4
4.76
14.3
19.
42.9
4.76
0
33.3
14.3
0
14.3
9.52
0
57.1
0
o
33.3
9.52
25
3.57
14.3
3.57
14.3
7.14
7.14
3.57
0
35.7
21.4
28.6
21.4
28.6
7.14
21.4
21.4
0
CAl-II 13.3
0
13.3
6.67
20.
26.7
13.3
6.67
0
26.7
TOTAL
4.49
12.9
10.7
16.9
36.
9.55
1.69
26.4
22.5
4.35
0
system. Several other programs (see Tables I and II)
must be executed to T-Score the exams and to produce
the data files read by this program. The order of
execution is XN9, XN10, and XN8. The output for
each section (Figure 8) lists each student's name, his
current weeks raw confidence score, the equivalent
T-Score, the cumulative average of all T-Scores to
date, and his percentile standing in the class. This
program reads data from four different data files,
three of which were written by computer programs.
The M4 file (Figure 9) contained the master list of
students in the course. This file contained the list of
student names, identification numbers and group numbers and it was grouped by section. After the post-test
and prior to executing Program XN8, the M 4 file
was copied into the J file and absentees were indicated
in the J file. In this manner, the master list (M4 file)
remained unaltered. This file is created at the beginning of the semester and is altered only when a student
35.7
QUALITY EDUCATIONAL DEVELOPMENT
11.2
COMPUTER ANALYSIS OF STUDENT PERFORMANCE
POST-TEST H
Figure 6-Program XN2 also analyzes student responses to
determine the percent of students missing each question as a
function of media group. A sample output is shown
ANALYSIS: PERCENT OF STUDENTS WHO MISSED A QUESTION
QUES.
objective on the manipulation of vectors was correctly
answered by more than 95 percent of the students
taking the exam. In contrast, question 19 was answered incorrectly by 28 percent of the students. If
the breakdown by group is scanned for this question,
the individual group percentages vary from 14 to 48
with a low of 3.7 percent for the CAl group. It should
be noted that all of the course objectives were not
treated by all of the media. 8 The behavioral objective tested by question 19 (electric field/superposition)
was treated by the lecture, study guide, and CAl
material of week G, and by a review study guide
made available to all groups during the review week.
If we can assume that all media were of equal content,
it would appear that CAl best enables the achievement
of this objective in general. Further analysis could well
refine the conclusion in terms of individual student
characteristics.
The second program which will be discussed (Table
I, Program XN8) provides the cumulative output of
the weekly bookkeeping. This program illustrates the
scope of data manipUlation possible using only simple
BASIC statements and a file oriented time-shared
REVIEW EXAM
A
B
C
D
E
F
G
CAl
1
o
o
4.76
0
4.76
0
o
o
1.13
2
20.
21.7
19.
27.3
28.6
28.6
45.5
29.6
27.7
40.
39.1
47.6
63.6
57.1
28.6
54.5
63.
49.7
o
4.35
0
4.55
0
o
o
o
1.13
5
40.
21.7
33.3
63.6
28.6
28.6
27.3
44.4
36.2
6
70.
43.5
76.2
63.6
61.9
57.1
59.1
77.8
63.8
7
5.
13.
4.76
4.55
0
19.
9.09
3.7
7.34
8
10.
13.
14.3
13.6
4.76
19.
4.55
11.1
11.3
9
10.
17.4
28.6
27.3
19.
19.
36.4
25.9
23.2
10
5.
8.7
4.76
4.55
4.76
4.76
18.2
11.1
7.91
11
15.
8.7
19.
0
9.52
9.52
13.6
11.1
10.7
12
75
69.6
71.4
72.7
66.7
66.7
77.3
81.5
72.9
13
20
21.7
33.3
4.55
47.6
19.
36.4
18.5
24.9
14
25
26.1
19.
40.9
28.6
23.8
36.4
40.7
30.5
15
75
82.6
95.2
95.5
85.7
81.
81.8
63.
81.9
TOTAL
16
20
8.7
23.8
13.6
19.
19.
22.7
22.2
18.6
17
10.
8.7
19.
22.7
4.76
9.52
18.2
7.41
12.4
18
50
30.4
71.4
68.2
52.4
57.1
54.5
74.1
57.6
19
25
43.5
14.3
36.4
47.6
19.
36.4
3.7
27.7
20
75
69.6
95.2
59.1
85.7
90.5
86.4
74.1
79.1
Figure 7-The analysis of the percent of students missing each
question is given for the mid-semester review exam to illustrate
the feedback this output provides
On Line Computer Managed Instruction
ON-SITE COMPUTER MANAGED DIRECTIVES
CURRENT GRADES AND CUMULATIVE AVERAGE T-SCORES
SECTION 803
POST-TEST M
MAGNETIC FIELD I
RAW SCORE
(M)
T-SCORE
(M)
CAS
(A-M)
PSM
(A-M)
BRILLA,R.
68.5
53
55
86
CASKEY,H.
63.8
49
43
8
DRAWNECK, R.
83.6
63
5},
63
HINSON,L.
67.8
52
56
91
34
N~
HOPPER,W.
71.7
55
48
HORNE,B.
88.1
67
50
53
JOHNSON,G.
75.6
58
56
91
KENNEDY,T.
89
68
52
69
KRATOCHVIL
79.8
60
49
44
MARTIN,A.
64.1
49
51
63
MC DEVITT,R.
63.9
49
45
14
OSBORN,D.
63
48
50
53
SCHULER,T.
ABSENT
ABSENT
48
34
SHEARER,G.
67.7
52
48
34
SMITH,D.
82.6
61
56
91
SZOKA,M.
91.2
72
50
53
TOMLIN,E.
79
59
59
96
VAUGHN,D.
61.9
48
50
53
WOOD,C.
46
38
41
5
WILKENSON,J.
40.5
34
39
2
Figure 8-The output from Program XN8 for one section for
week (M) is shown
drops the course. All programs which access data files
check the I.D. numbers to ensure that there is no
possibility of using the wrong data for a student's
record.
The other files accessed by XN8 were the Kl, T3,
and Ml files (Table II); the Kl and Ml files were
grouped by section. The Kl file (Figure 10) contains
each student's I.D. number, the sum of his T-Scores,
and the number of exams involved. This file can be
used to calculate the cumulative average T-Score since
that is the sum of the T -Scores divided by the number
of exams. The Kl file is updated weekly by computer
(Table 1, Program XNI0) in the following manner:
the program reads the cumulative information from
the Kl file, reads the current T -Score from another
file (file Ml), checks I.D. numbers to ensure a match,
then adds the current T -Score to the sum, increments
the number of exams by one, and outputs this information to the K2 file. Thus after executing XNI0,
the Kl file contains the previous weeks cumulative
237
data and the K2 file contains the updated cumulative
data. The Kl file is then deleted (a paper tape of the
file can be saved) and the K2 file is renamed to Kl
before executing XN8. This minimizes the amount
of data stored in the computer.
The XN8 program also reads data from the Ml file
(Figure 11) which contains student I.D. numbers,
the raw confidence score, and the equivalent T-Score
for the current week. The fourth file read by program
XN8 is the T3 file (Table II) which contains the data
necessary to determine a student's percentile standing
in the class.
A listing of program XN8 (Figure 12) is given to
show the simple BASIC statements which are involved.
For example lines 400-480 check that the I.D. numbers
for all data refer to the same student. Should a mismatch occur, the program is written to print (lines
420-430) the name of the student (A$) from the master file, his section (T), and the files involved. The
program reads the student data one student at a time,
and prints the results to avoid excessive use of subscripted variables since this would affect the permitted
100801.,1.,1
102 "BENHAM.,~1.".,720490.,5
104 "BLAKEY.,B."., 720651., 5
106 -BRUCKEH.,B.-.,721029.,1
108 -CROOK.,K.-.,721694.,1
110 -DIX.,S.-,,722079.,1
112 -ENGLUND.,R.-.,722380.,1
114 "GALLI.,W.".,722702,1
116 -GILLOOLy.,J.-.,722863.,5
118 -HEDRICK,M.-.,723584.,5
120 -KEITHLY,T.-.,724410,5
122 -KING.,M.-.,724571.,1
124 "MOFFATT.,W.".,725978.,5
126 "NEUPAVEH.,A.-.,726356.,1
128 "NIELSEN.,J.-,726412.,1
130 -PRINCE.,T.-,727014,1
132 "ROUND,H ... .,724399,5
134 -SCHUBB1T.,J.-,727700 1 1
136 .. SHOElVlAKER., J. -,727896., 5
138 .. SNYDER.,W ... .,728155.,5
140 -SPRINGYAN,R.-.,728232.,5
142 -VANMAELE.,J.-.,728932,5
144 .. VANOHSDEL.,R ... .,728939,1
150 0,0,0
Figure 9-The Master File of student names (M4 file) is listed
for one section to show how the names, J.D. numbers and group
numbers are stored
238
Fall Joint Computer Conference, 1970
lOa
101
102
103
104
105
106
101
108
109
110
111
112
113
114
11 5
116
11 7
11 811 9
120
121
122
1 ,
720490
720651
721029
721694
722079
722380
122102
722863
72358 /1
724410
124571
725978
726356
726412
727Q 14
72L1399
727730
127896
728155
728232
728932
728939
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
855
616
641
661
482
612
481
704
5Ll1
617
676
663
804
742
716
618
635
661.1
604
602
614
673
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
14
12
13
13
11
14
10
14
13
12
14
14
13
14
13
14
14
13
12
13
i3
13
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
Figure IO-The data stored in the Kl tile are listed for one section.
This file contains the cumulative sum of each student's T-Scores
and the number of exams involved
length of the BASIC program. The initial information
on the heading for each section is read and printed
(lines 210-360), while the data for each student in the
section is read and printed in a loop (lines 390-600).
Program XN8 will always run error-free since three
input files (Kl, ]\1:1, T3) are created by computer and
the fourth file (M4) is checked during the execution
of Program XN9.
CONCLUSIONS
The CMI programs described were successful from two
points of view: the dead time between the student's
responses and the analysis of results was kept to a
minimum and the flexibility of the system was maintained. Both of these advantages accrue from the fact
that the system was operated on.:..line in a time-sharing
mode. There is no doubt that the use of a batch-processing system increases the dead time between collection of data and output since turn-around time
for even efficient data centers can range from 3-24
hours. In contrast, time-sharing provides almost im-
mediate responses with a limiting factor being speed
of input and output. The modular design of this system,
with an emphasis on easy access to data and results,
allowed a flexibility which is often lacking in large
CMI programs where the sheer size and complexity
of the program often precludes changes. In turn, this
flexibility ensures user satisfaction since the system is
responsive to individual requirements. Furthermore,
the use of an easy conversational language (BASIC)
allows direct access to the system by teachers, educators, and students.
As noted above, a major area of consideration for
on-line CMI is which remote terminal to use. In this
experiment, a relatively large amount of time was
required for input and output because the rate of
transmission of the teletype is 10 characters/second.
This time can be cut considerably simply by using one
of the faster remote terminals available which transmit at rates of 30 characters/second and are compatible with most time-shared systems. Furthermore,
if the course design utilizes multiple-choice exam questions, students can mark their answers on a card and
a mark-sense card reader can be used. This eliminates
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
11 5
116
11 7
118
119
120
121
122
1 ,
720490 ,
720651
721029 ,
721694
722079 ,
722380
722702
722863 ,
723584 ,
724410
724571
725978 ,
726356
726412
727014 ,
724399 ,
727700
727896 ,
728155 ,
728232 ,
728932 ,
728939 ,
,
,
,
,
,
,
,
,
,
70.2 , 5'!
73.3 , 56
56.8 , 45
84.2 , 63
65.2 , 50
26.8 , 22
0 , 0 ,
53.6 , 43
52.1
41
84.6 , 65
55.2 , 44
43.3 , 36
85.4 , 65
75.3 , 57
69.5 , 54
0 , 0 ,
67 , 51 ,
57.1
45
76.3 , 58
69.2 , 53
31.4
28
49.8 , 40
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
Figure ll-The MIfile, which contains a student's raw confidence
score and the corresponding T -Score for the current exam, is
listed for one section
On Line Computer Managed Instruction
100
200
210
220
230
240
245
250
255
256
260
270
280
290
310
320
322
324
326
330
340
350
360
370
380
390
395
400
410
420
430
435
440
450
460
470
480
490
SOO
510
520
530
540
550
560
570
580
590
600
610
620
630
640
6SO
660
700
REM .... PROGRAM XNS ....
DIM C (l00)
FILES T3. H5. J. I'll. K1
R~D Il.X1.N.C(N)
IF,N=X1 THEN 245
60 TO 220
READ 12.VS.LS.KS
READ 13,T,X,P
R~D 14.Y
READ 15,Z
PRINTON-SITE COMPUTER MANAGED DIRECTIVESPRINT
PRINT
PRINTCURRENT GRADES AND CUMULATIVE AVERAGE T-SCORESPRINT
PRINT TAB(26);-SECTION -;T
PRINT
PRINT
PRINTPOST-TEST - ;VS,LS;KS
PRINT
PRINT
PRIN'CNAME- ,-RAW SCORE- ,-T-SCOHE- ,-CAS- ,-PSMPRINT TAB (16);- (N)-; TAB (32 H- (N)-; TAB(44);- (A-N)-; TAB (59 >;- (A-N)PRINT
PRINT
READ 13,AS, 0, U
IF 0=0 THEN 610
READ 14,U1,G,T1
IF Ul =D l'HEN 440
PRINT-l.D'S FOR -;AS;- OF SECTION -;T;- DO NOT MATCH 'PHINT-! IN THE J AND 1"1 FILESGO TO 660
READ IS.U2,S,N
IF U2=U1 THEN 490
PRINT-I.D'S FOR -;AH- OF SECTION -;T;- DO NOT MATCHPHINT- IN THE J AND K1 FILESGO TO 660
IF 6>0 'CHEN 540
LET M=INT< C!)/N)+.5)
LET W=CCCM)/C(XI »"100
PRINT AS,ABSENT-.M.INTHJ+.5)
GO TO 590
LET S=S+T1
LET N=N+1
LET l'!l=INTCCS/N)+.S)
LET W=CCCMI )/CCX1 »"100
PRINT AS.G.T1.Ml.INT(W+.S)
PRINT
GO TO 390
FOR 1= 1 TO 10
PRINT
NEXT I
IF X<13 THEN 250
PkINT- THIS COMPLETES THE OUTPUT FOR THIS PROGRAM!)IOP
END
Figure 12-A copy of Program XN8 is listed to show the simple
BASIC statements which can be used to manipulate student
data files
the time and personnel required to punch student
responses on paper tape. Nothing in the system design
precludes each user from choosing the terminal best
suited to his needs.
In summary, the implementation of CM! is essential if teachers are going to effectively manage the
learning process to provide individualized instruction.
On-line CMI satisfies the needs of educators for a rapid,
flexible, easily accessible system. On-line CMI can
currently perform the tasks of diagnosis, testing,
"
239
record keeping, and analysis. Such a system is also
capable of elucidating, validating, and imp1ementing
algorithms which provide individualized learning prescriptions.
ACKNOWLEDGl\1ENTS
The authors wish to acknow1edge the many helpful
discussions and suggestions contributed by Dr. A. F.
Vierling, Manager of the Honeywell Educational
Instruction Network (EDINET), and Dr.A. T. Serlemitsos, Staff Physicist at Quality Educational Development, Incorporated.
REFERENCES
1 H J BRUDNER
Computer-managed instruction
Science Volume 162 pp 970-976 1968
2 Revised listing of objectives
Technical Reports Numbers 4.3a and 4.3b United States
Office of Education Project Number 8-0446 November 3
1969
3 A F VIERLING
CAl development in multimedia physics
Technical Report Number 4.30 United States Office of
Education Project Number 8-0446 November 3 1969
4 W A DETERLINE R K BRANSON
Evaluation and validation design
Technical Report Number 4.7 United States Office of
Education Project Number 8-0446 November 3 1969
5 W A DETERLINE R K BRANSON
Design for selection of strategies and media
Technical Report Number 4.9 United States Office of
Education Project Number 8-0446 November 3 1969
6 E H SHUFORD JR
Confidence testing: A new tool for management
Presented at the 11th Annual Conference of the Military
Testing Association Governors Island New York 1969
7 W C GARDNER JR
The use of confidence testing in the academic instructor course
Presented at the 11th Annual Conference of the Military
Testing Association Governors Island New York 1969
8 A F VIERLING A T SERLEMITSOS
CAl in a multimedia physics course
Presented at the Conference on Computers in
Undergraduate Science Education Chicago Illinois 1970
Development of analog/hybrid terminals for
teaching system dynamics
by DONALD C. }\iARTIN
North Carolina State University
Raleigh, North Carolina
enthusiasm. As pointed out by Professor Alan Rogers at
a recent Joint SCI/ ACEUG Meeting at NCSU, this
intimate student-professor relationship simply cannot
be achieved in today's large classes unless the instructor
learns to make effective use of the modern tools of
communication, i~e., movies, television, and computers.
In effect, we turn students off by our failure to recognize
the potential of these tools, especially the classroom use
of computers.
The material which follows points out the need for
interactive terminals, describes the capabilities of
prototype models already constructed, and then outlines
the classroom system which is presently being installed
for use in the fall of 1970.
INTRODUCTION
A recent study completed by the School of Engineering
at North Carolina State University brought to light a
very serious weakness in our program to employ
computers in the engineering curricula, i.e., the inherent
limitation on student/computer interaction with our
batch, multiprogrammed digital system. The primary
digital system available to students and faculty is the
IBM SYSTEM 360/Model 75 located at the Triangle
Universities Computation Center in the Research
Triangle area. This facility is shared with Duke
University and the University of North Carolina at
Chapel Hill. In addition, the Engineering School
operates a small educational hybrid facility consisting
of an IBM 1130 interfaced to an EAI TR48 analog
computer. We use some conversational mode terminals
on the digital system but it has been our experience that
they are of limited value in the classroom and, of course,
only accommodate on the order of two students per hour.
It is our feeling that terminals based on an analog or
hybrid computer would materially improve student/
computer interaction, especially aiding the comprehension of those dynamic systems described by ordinary
differential equations. This paper has resulted from our
attempts to outline and define the requirements for an
analog computer terminal system which would effectively improve our teaching in the broad area of system
dynamics. The need for some reasonably priced dynamic.
classroom device becomes apparent when we consider
the ineffectiveness of traditional lecture methods in such
courses as the Introduction to Mechanics at North
Carolina State University. This is an engineering
common core course in mechanical system dynamics
which has an enrollment of about 400 students per
semester. This is a far cry from early Greek and Roman
times when a few students gathered around a teacher,
who made little or no attempt to teach facts but instead
attempted to stimulate the students' imagination and
THE NEED FOR INTERACTIVE TERMINALS
Classroom demonstrations
The computer has long held great promise both as a
means for improving the content of scientific and
.technical courses and as an aid for improving methods
of teaching. While some of this promise has been realized
in isolated cases, very little has been accomplished in
either basic science courses or engineering science
courses in universities where large numbers of students
are involved. It is certainly true that significant
improvement in course content can be achieved by using
the computer to solve more realistic and meaningful
problems. For example, the effects of changing parameters in the problem formulation can be studied. With
centralized digital or analog computing facilities, this
can be accomplished only in a very limited way, e.g.,
problems can be programmed by the instructor and used
as a demonstration for the class. Some such demonstrations are desirable but it is impossible to get the student
intimately involved, and at best they serve only as a
supplement to a text book. At North Carolina State
241
242
Fall Joint Computer Conference, 1970
Figure 1
University we have developed a demonstration monitor
for studies of dynamic systems which seems to be quite
effective. We recently modified our analog computers so
that the primary output display device is a video
monitor which can be used on-line with the computer.
Demonstrations have been conducted for other disciplines, for example, a Sturm Liunville quantum
mechanics demonstration for a professor in the Chemistry·Department. This demonstration very graphically
illustrates the concept of eigenfunctions and eigenvalues
for boundary value problems of this type. A picture of
the classroom television display is shown in Figure 1.
The instructor's control panel makes several parameters,
function switches and output display channels available
for control of the pre-patched demonstration problem.
Switches are also available to control the operation of
the analog computer . The direction we are proceeding in
the area of demonstration problems is to supply the
instructor with a pre-patched problem, indicate how to
set potentiometers, and how to start and end the
computation. Since the display is retained on a storage
screen oscilloscope with video output, he can plot
multiple solutions which will be stored for up to an hour,
or he can push a button to erase the screen at any time.
Some demonstrations have been put on the small video
tape recorder, shown in Figure 1, but we find the loss
of interactive capability drastically decreases the effectiveness of the demonstration.
Student programming
In addition to classroom demonstrations, the student
can be assigned problems and required to do the pro-
gramming. While we believe this to be an excellent
approach for advanced engineering courses, such as
design, systems analysis, etc., it has proven less than
satisfactory for the first and second year science and
engineering courses. Even when the students have had
a basic programming course, valuable classroom time
must be spent in techniques for programming, numerical
methods, and discussions of debugging. The students
tend to become involved in the mechanics of programming at the sacrifice of a serious study of the
problem and its interpretation. With inexperienced
students, even when turnaround time on the computer
is excellent, the elapsed time between problem assignment and a satisfactory solution is usually much too
long.
We have tried this student programming approach
for the past four years in a sophomore chemical engineering course. While it has been of some value, we
are now convinced that it is not a satisfactory method
of improving teaching. The teaching of basic computer
programming does, however, have a great deal of merit
in that it forces students to logically organize their
thoughts and problem solving techniques. Also it helps
to provide an understanding of the way computers
can be applied to meaningful engineering problems.
Thus, we intend to continue the teaching of basic
digital computer programming in one of the higher
level languages at the freshman or sophomore level,
and then make. use of stored library programs for
appropriate class assignments. In addition, we will
continue to assign one or more term problems in which
the student writes his own program, especially in
courses roughly categorized as engineering design
courses.
Digital computer terminals
It is appropriate at this point to emphasize why we
feel time-shared or conversational mode terminals are
not the answer to our current problem. It has been our
experience that the conversational te~minal is an outstanding device for teaching programming, basic capabilities of computers, and solving student problems
when the volume of data is limited. However, if the
relatively slow typing capability of students is considered, we have found that a class of 20 or 30 students
can obtain much faster turnaround time on the batch
system. To be sure, the student at the terminal has
his instantaneous response, but the sixth student in the
queue is still waiting two hours to run his program and
use his few tenths of a second CPU time. One can certainly argue that this is an unfair judgment since the
solution is to simply buy more terminals for about
Development of Analog/Hybrid Terminals
$2500 each. Unfortunately, these terminals are like
cameras and their use involves a continuing expense
often greater than the initial cost. Connect time and
communication costs for a sufficient number of terminals have discouraged such terminal use on the campus
at the present time. The experience of the North
Carolina Computer Orientation Project, which essentially provided a free terminal for one year at
have-not schools, has been similar in that it proved
very difficult for these schools to utilize the terminal
in any science course other than a course in programming.
Present limitations on classroom use of computers
It is reasonable to ask why, in a university that has
had good computing facilities for some time, computer
use in the classroom is so limited. We feel there are
several reasons why the majority of instructors do
not use this means of communication to improve instruction techniques. The first of these reasons must
be classed as faculty apathy. There is no other explanation for the fact that less than 25 percent of our
engineering faculty use the digital computer and less
than 5 percent avail themselves of our analog facility.
Admittedly, it is extremely difficult for a physicist,
chemist or engineer who is not proficient in computing
to program demonstration problems for his classes.
Because such demonstrations, while a step in the right
direction, do not really make use of the interactive
capability of the computer to excite the students'
imagination, there is often little motivation for the
professor to learn the mechanics of programming.
Fortunate indeed is the occasional instructor who
has a graduate student assistant competent to set up
and document such demonstrations.
The second reason, closely coupled to the first, is
that computer output equipment for student use in
the classroom is either not available or just too expensive for large classes. Digital graphics terminals, for
instance, sell for between 15 and 70 thousand dollars,
depending on terminal capability, and an analog computer of any sophistication at all will cost 5 to 10
thousand d,ollars with the associated readout equipment. In our basic introductory mechanics course,
with ten sections of forty students, a minimum of
twen ty such terminals would be required if we assume
two students per terminal as a realistic ratio. Even if
such analog or digital computer terminals were available, we would then be faced with the problem of
teaching the students (and faculty) a considerable
amount of detailed programming at the expense of
other material in the curriculum. We feel that analogi
243
hybrid computer terminals designed to accomplish
a specific, well-defined task, will provide an economical
interactive student display terminal for many engineering courses. Such a terminal is described in this
paper.
CLASSROOM TERMINAL SYSTEM
We have recently received support from the National
Science Foundation to study the effect of student interaction with the computer in courses which emphasize
the dynamic modeling of physical systems. It is a well
known fact that interaction with a computer improves
productivity in a design and programming sense. The
question to which we are seeking the answer is: Will
computer interaction also improve the educational
process effectively without leaving the student with
the impression that we are using a "magic black box"?
To accomplish this goal, we are installing sixteen analog/hybrid terminals in a classroom to serve thirtytwo students. The classroom in which these terminals
will be placed is about 150 feet from the School's analog
and digital computer facility.
At this point, we should place some limits on terminal
capability and function. If we accept the premise that
the student need not learn actual patching to use the
analog computer terminal and eliminate the traditional concept of submitting a hard copy of his computer output as an assignment, the desirable features
of a terminal might be as follows:
1. Parameters: The student must have the capa-
bility of varying at least five different parameters in a specific problem. Three significant
digits should be sufficient precision for these
parameters and their value should be either
continuously displayed or displayed on command.
2. Functions: The student should have access to
function switches to perform such operations
as changing from positive to negative feedback
to demonstrate stability, adding forcing functions to illustrate superposition, adding· higher
harmonics to construct a Fourier approximation of a function, introducing transportation
delay to a control system, etc. Three to five of
these function switches should be sufficient.
3. Problems: The student should be able to select
several different problems, say four, at any of
the individual terminals. Depending on the size
of the analog computer, the student could use
the terminal to continue a study of a problem
used in a prior class, compare linear and nonlinear models of a process, etc.
244
Fall Joint Computer Conference, 1970
4. Response Time: The response time for each of
twenty terminals should be about one to three
seconds, i.e., the maximum wait time to obtain
one complete plot of his output would be something like one second plus operate time for the
computer. Computer operate time has been
selected as 20 milliseconds for our equipment
although a new computer could operate at
higher speeds if desired.
5. Display: The display device for each terminal
must be a storage screen oscilloscope or refreshed display for x-y plots. Zero and scale
factors must be provided so that positive and
negative values and phase plane plots can be
plotted. Scaling control must be presented in
a manner which is easy for the student to use
and understand.
6. Output selector: The student should be able
to select from four to five output channels for
display on the oscilloscope.
7. Instructor display: The instructor should have
a terminal' with a large screen display which
the entire class can observe. His control console
should have all the features of the student
terminals and should also have the capability
for displaying anyone of the student problem
solutions when desired. He should also have
master mode controls to activate all display
r--'
~-.--'-
I
! ,~~'I..
i---.-
~~I ?-_~~;
to
_T!t_,mK_s- '
I ~ i~, -,"~.-:~..--.--,
I
~
'.~;,_
;?".---
~ ~
U'
;t
::hl
J=>
~--'
I----,ril....
Given a terminal system with these features, we
have then defined the primary objective as being a
study of the use of this classroom in some specific
courses. We are initiating this evaluation with one
course in Engineering Mechanics, Introduction to
Mechanics (EM 200) and two courses in Chemical
Engineering, Process Analysis and Control (CHE 425),
and Introduction to System Analysis (CHE 225). Thus,
we start our evaluation with one sophomore engineering
core course with three to four hundred students per
semester and two courses with thirty to forty students
per semester at the sophomore and senior level. In
addition to these two courses, we are attempting to
schedule as many demonstrations of the system as
possible for other departments in the hope of stimulating their imaginative use of the terminals.
A flow sheet for the classroom terminal system is
given in Figure 2. The system includes a small digital
mini computer which is to be used for control, storage,
and scaling of terminal information. The system consists of the following components:
a. Sixteen student terminals
b. One instructor terminal
c. Digital mini computer with I/O device for
programming
d. Control interface to analog computer
t \~ L____~___)
b ~I~t
~~
~~~~.I)
,~~~-----------
;;,~, !, I CONI'ROI.
~.;-UNG
AI)
1.:~ING
terminals. It would be advantageous for the
instructor to have a small screen display to
monitor student progress without presenting
the solutions to the class on the large screen.
9>!HL VIGIl'Pi GOMP'?j'ER FOR
CONI'ROl. PlID SCALING O}
'!'EHMlNALS
Figure 2-Flow sheet for proposed analog/hybrid terminal
system
The inclusion of a small digital computer in this
terminal system opens up some very interesting future
possibilities such as using the terminals for digital
simulation as well as analog. As will be seen in the next
section, the digital computer provides scaliilg so that
parameters can be entered in original problem units.
It also acts as temporary storage for each terminal as
it awaits service and controls the terminal system. The
system is designed to operate in the following manner.
The instructor informs the computer operator that he
wishes to use problem CHE 2 during a certain class
or laboratory period. The operator places the proper
problem board on the TR-48 and then sets the servo
potentiometers which are not controlled by the student
terminals and static checks the problem with the hybrid computer. He also sets up the program CHE 2
on the mini computer just prior to class. From this
point on the system is under the control of the instructor and students.
Development of Analog/Hybrid Terminals
245
FUNCTIONAL DESCRIPTION OF TERMINAL
I+\yisi·ioisiul
General
D!'~:rAl.
Dl;':r'LA:t
fHoiOl
~
The basic terminal configuration is shown in Figures
3 and 4. All display functions are located on the upper
display panel and control or data input is provided on
the inclined control panel.
a
.-- -- -- --- - --- ----------t
Control
I
I
The controi functions available to the student include power on-off, store, non-store, erase, and trace
intensity. Th~se controls are located on either side
of the oscilloscope display as shown in Figure 4. Indicator lights are also provided in this area for terminal identification, error and terminal ready status.
The erase function is used quite often by the student
and thus is also available on the keyboard.
In addition to the basic operating controls, the
student can request either a single solution or repeated
solutions on his display unit. For the single solution
mode, he displays one solution as soon as the sequencer
reaches his terminal address. In the repeat solution
mode, his oscilloscope is unblanked and displays a
solution each time the sequencer reaches his address.
DBDEB
Display Scaling
I
I
RESERVED P'OR fWURE ALPHAl4ERIC
I
I
KlTOCAiW EXf'ANSlVt.
I
I
I
I
I
I
I
I
I
I
I
I
I
~--------------------
I
I
J
EJ
El
0
0
III[!]!!)
ffi@lill
CD0[I1
EJ
~
B
EI
Ikj@]~
§
GB~
~
Figure 4-Terminal display and control panels
The worst case response time for either mode would
be on the order of one second, even if all other terminals
had solution requests pending.
Output display and scaling
The primary output display device is a Tektronix
type 601 storage screen oscilloscope. This oscilloscope
is mounted directly behind the vertical front display
panel as shown in Figures 3 and 4. These oscilloscopes
are modified to provide for s~aling as shown below.
The operating level circuit is modified to provide a
switched store and non-store operation for the user.
Output scaling is automatically selected when the
student depresses anyone of the four push buttons
on the left hand side of the display panel. The picture
which indicates the normalized scaling is printed on
the face of the lighted push button switch.
The left hand switch scales the output signal to
display positive X and Y values. The second switch
. displays positive X and allows for both positive· and
negative values of the Y variable. Phase plane plots
can be displayed by selecting the right hand switch
in this set. We have been using this type of output
scaling for oscilloscopes in our laboratory for over a
year with very satisfactory feedback from student users.
The student must have the option of selecting from
several X and Y analog output lines. This option is
provided at the terminal by depressing either
or
Figure 3
III
[!] then the appropriate number on the keyboard,
and then the
1ENTER I
key. For example, if
246
Fall Joint Computer Conference, 1970
the student is instructed to plot Xl versus Y4, he would
actuat~ the following keys on the terminal keyboard
as shown below:·
This system allows the student to enter parameter
values in the actual problem units, e.g., if the input
temperature for a heat exchanger simulation is 150°F,
he sets this value rather than some normalized fraction.
IENTER I is depressed,
the register can be cleared with the ICLR Ikey. The
If an error is made before
The digital software sets up the linkage between the
requested output line and the control unit which
switches variable outputs for specific problems to the
two analog output lines leading to the classroom. All
analog outputs are on the two X and Y lines, but each
terminal Z line is energized only at the appropriate
time, i.e., in answer toa solution request for that
terminal.
Parameter entry
There are many ways in which parameters can be
set frOIn an analog or hybrid computer terminal. In
the first terminals we constructed, parameters were
simply multiplexed potentiometers connected to the
analog computer with long shielded cable. Thumbwheel switches can be effectively used to set digital
to analog coefficient units or servo potentiometers .at
the analog computer. Since this hybrid terminal system
includes a small digital computer, parameters will be
entered with a fifteen digit keyboard as indicated in
Figure 4.
The parameter function switch,
I
rpARI,
keyboard,
I
and ENTER keys are used in the following sequence.
Suppose the student wishes to set parameter number
four at a value of 132. He would depress switches in
the following sequence:
IpARI EI EJ EJ o IENTER I
or
I 100000
PAR
lENTERI
If the parameter number three were less than unity,
say 0.05, he would enter
or
I PARI EJElOEJ01ENTERI
I PAR lEI 0 EJ E]IENTER I
use of actual rather than normalized parameters requires additional registers in the terminal but is essential for beginning students. We must remember
that they are studying the dynamic system, not analog
computer scaling. It is also in keeping with the concept
of using the terminal as input and output for the hybrid computer. If the parameters represent frequency,
temperature, pressure, etc., they should be entered as
they appear in the problem statement if at all possible.
Since "parameter values are scaled by a program in
the digital computer, scientific notation can also be
used to permit both E and F format data entry from
the hybrid terminal. The digital software interprets
the input data to separate the mantissa and exponent
portions of the number entered in E format. For example, the student might enter
fENTERI
and the digital computer would convert this number
to +0.00015.
Reading parameter values
One significant advantage of the thumbwheel switch
parameter entry as opposed to the keyboard is the
ability to remember a specific parameter value at any
time. If the student forgets the value, he needs to be
able to display it at the terminal on request. This
capability is provided by a six character plus sign
display module located in the upper left corner of the
terminal as shown in Figures 3 and 4. This display
unit automatically shows the" student that his parameter value was correctly entered at the keyboard and
accepted by the digital computer. The format of the
output display is controlled by the digital computer
software. In addition to displaying the correct value
of the parameter when entered at the keyboard, the
Development of Analog/Hybrid Terminals
value of any parameter previously set can be indicated
using the
I
DISPLAY
I key.
Suppose the student
wishes to retrieve but not change the value of parameter three. He would press
~
I
, thenmon the
I
keyboard, and then the DISPLAY key. The digital
computer software then causes the proper value to be
displayed and light keyboard button number
II] to
identify the requested parameter number.
A separate digital display module could be used to
indicate the requested parameter number, but lighting
the keyboard number has some advantage when displaying the status of function switches as noted later.
feature of the terminal. Thumbwheel switches and
keyboard entry of parameters are fine but tend to be
somewhat slow when the student is interested in observing the effect of a range of parameter variations
on a simulation or fitting a model to experimental data
points. A potentiometer on the terminal, as we have
employed in the past, avoids this problem but involves
transmission of analog signals over long lines. As a
compromise, either a two or four position switch is used
to increment the value of any selected .parameter at a
rate determined by the digital software. Thus, the
student increases or decreases a particular parameter
value at either a fast or slow rate with this switch. The
sequence of operations would be as follows: suppose
the student wishes to vary parameter four through a
range of values to observe its effect on the solution.
He might choose a starting value of zero for this parameter which, for example, might represent the damping
coefficient in a linear, second order system. He presses
I I,
PAR
Analog/digital readout
display. The student presses
0, followed by the
appropriate number on the keyboard, and then the
IDISPLAY J function
followed by the numbers
on the keyboard and then selects the
One of the advantages which immediately becomes
apparent when the terminal includes digital readout
and a small digital computer is the capability of returning numbers which are the result of an iterative
calculation. A'· first order boundary value problem
where the unknown initial condition or time constant
is sought would be one illustration. Another example
which we have been using in a basic process instrumentation course is to demonstrate the operation of
a voltage to frequency converter or time interval analog
to digital converter.
Any digital or analog number can thus be returned
to a terminal by selecting one of the output lines for
key. This display feature is
also extremely valuable in presenting calculated results from the hybrid computer through the trunk
lines as indicated in the overall system diagram,
Figure 1.
247
He then selects the
0
and
0
IENTER I key.
I REPEAT SOLUTION I mode
to observe the solution each time the sequencer reaches
his terminal number. If the student has selected the
I STORE I mode, he can then plot a family of curves
as he increases the damping factor from zero to unity
by pushing the parameter slewing switch in the increase
direction. A four position switch allows a choice of
either fast or slow incremental changes in the parameter value. Another obvious application for this function is in curve fitting of experimental data with one
or more parameters.
Function switches
Control of the electronic function switches is provided at each terminal. To set function switch one in
I FUN I ,fol'o"k I on the key-
theiONI position, the student presses
lowed by the number
board and then the
One variable parameter
[I]
and
I ENTER I key. If he wishes to
know the present state of any function switch, he
The availability of a control which can vary one
parameter through some range of values is an important
presses 'FUN
I , the switch number, and then the
248
Fall Joint Computer Conference, 1970
I DISPLAY I key. The terminal response is to light
the function switch number and either the Io"k I
or
I I
OFF
keys on the keyborad to indicate the pres-
ent state of that particular switch. These function
switches can be used in any way desired by the instructor, e.g., adding successive terms of a power or Fourier
series to demonstrate the validity of these approximations, adding various controller modes in a process
control simulation, etc.
The instructor's terminal
The instructor's terminal is designated as terminal
number zero. This termi~l uses as its primary output
device a Tektronix Type 4501 storage oscilloscope
instead of the Type 601. Since this scanning oscilloscope has video output, the instructor can display his
solution on the closed circuit television monitor for
the class at any time. In addition, the instructor has
the capability of un blanking any or all student terminals to let them have a "copy" of his solution to
compare with· their own. He can also unblank his
terminal and pick selected student solutions for display
to the rest of the class.
SOFTWARE
Basic operating system
The basic software to serve the analog terminals
is written in assembly language for the PDP-8 control
computer. This is a 4K machine with hardware multiply and divide, although this feature is not essential
for terminal operation. The basic cycle time for the
system is controlled by the analog clock which alternately places the analog computer in the initial condition and operate modes every twenty milliseconds.
The first ten milliseconds of each initial condition
period is to ensure adequate time for problem and function selection by the relay multiplexer. The second ten
milliseconds is the normal initial condition time to
charge the integrating capacitors as shown below.
::.t~rx
NORMfJ.
3IIITCHI~l'}
MlIX
NOPA!,L,
301 IT CHING
ANALOG
-21-
AN.tI.LOG
PROSLEM SOLUT ION
....1
g
~
....1
g
~
TIME
IC TIME
AN"; LOG INrrIAL
TTI.fE
ANALOG OPERATE
CONDrrION MODE
IC TIME
ANALOG INITIAL
MODE
CONDrrrON MODE
8
Pl
R
~
I--
20 ms
--~1Mo1.r---
~ ~,---
20 ms - -......
20 ms
--+
A terminal user can activate an action key at any
time, e.g.,
t
ENTER
I,
I
DISPLAY
I , ISINGLEI
ISOLUTION I, or IREPEAT SOLUTIONI .
This request for action, along with the necessary
data and address is stored in a 32 bit shift register in
each terminal. As each terminal is interrogated in
sequence by the PDP-8 the action bit is tested. If the
user wants service, his data is transferred to a specific
core area. For instance, suppose he wishes to set parameter number 1 at a value of 0.32. He activates the following keys:
IENTER
I.
~
The
[]]
rn 0
m[!]
IENTER( key is the action code
in this instance. When the sequencer reaches his terminal, this data is transferred to storage in the proper
memory locations in the PDP-8. A similar action is
taken to set function switches, and select problems or
output channels.
The basic operating system software controls all
of these action operations. When a solution is requested,
the parameters, functions, and outputs, along with an
unblanking signal, is sent back to the terminal during
the next analog computer operate cycle. The basic
system software also converts the floating point
parameter values supplied by the student to integer
values used by the digital coefficient units or digital
to analog converters. This feature of floating point data
entry requires that the instructor provide the scaling
information for each problem as described next in the
application software section.
A pplication software
The application software is written in a special
interactive language developed for the PDP-8. This
language makes use of a cassette tape recorder in our
system, but could be used from the teletype if necessary. The information required by the terminal operating system to convert floating point to integer parameters is their maximum and minimum values. When
the instructor is setting up the terminal problem, the
computer software solicits responses similar to the
following:
IDENTIFY YOUR PROBLEM NUMBER
The instructor would then type,
CHE4
Development of Analog/Hybrid Terminals
The computer responds with
PROVIDE MAXIMUM AND MINIMUM
VALUES FOR THE PARAMETERS
If the instructor wishes to give the student control
over parameters one and two, he types
PAR 1, MAX 50, MIN 25
PAR 2, MAX 0.5, MIN 0
END PAR LIST
A similar conversational procedure is used to identify
function switches, problems, and analog computer
output channels. In our system, this scaling and
switching data is stored on the magnetic tape cassette.
A paper tape unit could also be used if desired. When
the instructor wishes to use the terminal system at a
later date, he places his cassette in the tape deck and
the proper problem board on the analog computer. From
this point on, the problem or problems can be controlled from the individual terminals.
COSTS
The cost of a system such as described in this paper
is naturally dependent on the number of terminals
involved. Since our system was developed jointly
with Electronic Associates, it is difficult to evaluate
the actual development and design costs. The individual
terminals, including a type 601 Tektronix storage
oscilloscope should be on the order of $3500 to $4000
each. Mini computers such as used in this system would
range from $6000 to $10,000 and cassette tape systems
249
are available for about $3000. The major question
mark in the estimation of system cost is the hybrid
control interface to couple the analog and digital computers. If a special interface could be developed for
about $10,000, the cost of a ten terminal system would
be on the order of $60,000. This system could be
coupled to any analog computer and, of course, provides basic hybrid capability as well as terminal operation. If a hybrid computer were already available,
the terminals could be added for about $3500 to $4000
each plus wiring costs.
CONCLUSION
The key to student and instructor use of these terminals
is the development of appropriate handout materials.
Several of these handouts have been written in programmed instruction form and have resulted in very
favorable feedback from students who used early models
of the terminals. Although the complete classroom
system will be used for the first time in the fall of 1970,
we have been very gratified with student acceptance
of the few terminals now in use. Laboratory reports
now consist of answering specific questions concerning
the dynamic system under study rather than computer
diagrams and output. Also, the student can really
proceed at his own pace, and return at any time to
repeat a laboratory exercise simply by giving the computer operator the problem number . We are excited about
the potential of this classroom terminal system and
believe that we will see significant improvement in the
students' understanding of dynamic systems as the
system is used in additional curricula.
Computer tutors that know what they teach
by L. SIKLOSSY
University of California
Irvine, California*
limited domain (multiple-choice question), or it must
match exactly or partially (through key-words) some
stored answers.
The result of the diagnostic is submitted to a strategy
program (K6). The strategy program may use additional data, past performance for instance, to determine
the next frame of the course.
INTRODUCTION
Computer tutors hold the promise of providing truly
individualized instruction. Lekanl lists 910 Computer
Assisted Instruction (CAl) programs, and this large
number demonstrates the ,\~de interest in the field of
computer tutors.
The computer is eminently suited for the bookkeeping
tasks (averaging, record keeping, etc.) that are usually
associated with teaching. In such non-tutorial tasks, the
computer is greatly superior to a human teacher. On the
other hand, in strictly tutorial tasks, the computer is
usually handicapped. In particular, CAl programs
seldom know the subject matter they teach, which can
be seen by their inability to answer students' questions.
We shall consider the structure of tutorial CAl
programs and discuss some of their shortcomings. Some
of the latter are overcome by generative teaching
systems. Finally, we shall outline how we can construct
computer tutors that know their subject matter sufficiently to be able at least to answer questions in that
subj ect matter.
KI:
STUDENT ANSWER
"IGNORANT" CO}V[PUTER TUTORS
K5:
DIAGNOSTIC: COMPARE
STUDENT ANSWER
TO A FINITE NUMBER
OF STORED ITEMS
Most CAl programs have a structure very close to
that of mechanical scrambled textbooks. These textbooks and their immediate CAl descendants, which we
shall call selective computer teaching machines, * consist
of a number of frames. Figure 1 shows the structure of a
frame of a selective computer teaching machine.
The computer tutor may either start the frame with
some statements (box labelled K2), or directly ask the
student some question (K3). The student's answer (K4)
is compared to a finite store of anticipated responses
(K5). The answer itself may have been forced into a
KG:
STRATEGY p.:
DETERMINE NEXT MOVE
* Present address: University of Texas, Austin, Texas.
* To use the terminology of Utta1. 5
p. DENOTES
PROGRAM
Figure I-Frame of a selective computer teaching machine
251
252
Fall Joint Computer Conference, 1970
Disregarding the bookkeeping tasks that the computer tutor can perform, we shall concentrate on· the
structure of the tutor. The two major criticisms that
have been levied at selective computer teaching
machines are:
a. Their rigidity;- Questions and expected answers
to these questions have been prestored.
b. Their lack of knowledge. They cannot answer a
student's questions related to the subject matter
that is being taught.
GENERATIVE TEACHING MACHINES
In an effort to overcome the rigidities of selective
computer teaching machines, some researchers have
developed generative teaching machines.
Figure 2 describes a frame of a generative teaching
machine. In this case, the computer tutor, instead of
retrieving some question or problem, generates such a
question or problem, a sample of some universe. The
generation is accomplished by a program called the
generator program (L2).
LI!
p. DENOTES
PROGRAM
The sample is presented to the student who tries to
manipulate the sample: i.e., answer the question or solve
the problem. Concurrently* another program, the
performance program, manipulates the sample (L5).
The performance program knows how to manipulate
samples in the universe of the subject matter that is
being taught.
Before continuing with our description, we shall give
some examples of generative teaching machines. Uhr
has described a very elementary system to teach
addition. A program by Wexler 3 teaches the four
elementary arithmetic operations. Peplinski4 has a
system to teach the solution of quadratic equations in
one variable. Uttal et al. 5 describe a system to teach
analytic geometry.
When Wexler's system teaches addition, the generator
program generates a sample, namely two random
numbers that satisfy certain constraints. An example
would be: four digits long, no digit greater than 5.
(Note that the number of possible samples may be very
large.) The performance program simply adds the two
numbers.
A diagnostic program (L7) analyzes the differences
between the answers of the student and the performance
program. In Wexler's system, the numbers given by the
student and the system mayor may not be equal. If
unequal, the diagnostic program may determine which
digits of the answers are equal, which number is larger,
etc.
The findings of the diagnostic program, together with
other information (such as past student performance),
are given to a strategy program (L9). This program may
decide to communicate some aspects of the diagnosis to
the student-for example : "Your answer is too small."
(L11); it may halt (L10); or transfer to a new or the
same frame (L1). Transferring to the same frame is not
an identical repetition of the previous frame, since
usually the generator program ·will generate a different
sample.
In a generative computer tutor, questions are no
longer prestored but are generated by a program. Since
the questions are not usually predictable with exactitude, a performance program is needed to answer them.
The performance program is at the heart of a computer
tutor that knows what it teaches.
PROGRAMS THAT KNOW WHAT THEY TEACH
UI:
~~~~L-
_________ _
COMMUNCATE ASPECTS OF
DIAGNOSTIC p. TO
STUDENT
Figure 2-Frame of a generative teaching machine
The performance program of a generative computer
tutor can solve the problems in some universe; in other
words, we may say that the program knows its subject
* This is the meaning of the wavy lines in the flowchart.
Computer Tutors That Know What They Teach
253
occurs faster when students generate their own
examples.
A COMPUTER TUTOR THAT KNOWS SOME
SET THEORY
Figure 3-Frame of a computer tutor that knows what it teaches
matter. We can use the performance program in two
additional ways beyond its use in generative tutors. The
performance program may answer questions generated
by the student. It can also explain how it answers some
questions and thereby teach its own methods to the
student.
Figure 3 describes a knowledgeable computer tutor.
The path of boxes L1, L2, L5, L6, L7, L9, L10 and L11
has been discussed above in the framework of a generative tutor. The function of box L12 is to explain to the
student the problem-solving behavior of the performance program in those cases when the behavior of the
performance program can be fruitfully imitated by a
human being.
In box L3, the student is allowed to generate samples.
The previous path can then be followed: both student
and computer· tutor can manipulate the samples with
the tutor helping the student. The tutor can also
manipulate the sample directly, thereby, in effect,
answering a student's question (path L3, L5 /, L6 /). We
can even let the tutor make mistakes (L4, L5 /), which
gives the student an opportunity to catch the teacher in
error (LS).
It is important to let the student generate samples so
that he can find out what happens in particular cases
about which he feels unsure. It is impossible to preprogram a set of samples that would be satisfactory to
all students. In addition, some experimental evidence
(Hunt;6 Crothers and Suppes7) indicates that learning
We shall illustrate the framework of a knowledgeable
computer tutor by a program that teaches set union.
The subject matter was selected for the ease with which
appropriate performance and diagnostic programs could
be written.
The programming language is the LISP 1.6 version of
LISP running on the PDP-10 computer. The program
is not completely polished and the outputs have been
slightly edited. A more definitive version of the program
will be described elsewhere, but we hope to give here
enough feeling for the power of such a computer tutor
to be appreciated.
Sets are represented by unordered lists. The sets
(A(B C» and ((C B)A) are equal. Each contains two
elements, one of which is itself a set. ( ) is the empty
set.
A dialogue between the computer tutor and a student
follows. We first consider the'computer generative mode:
Computer:
What is the union of (HI 32) and
((DOG»?
Student: (HI).
C. : Your answer is not right. Do you see
why?
S.: No.
C. : You missed some elements. The
following also belong to the union:
(DOG) 32. The union is ((DOG)
HI 32) ...
The output does not make it evident that the sets were
generated using a random set generator. The set
generator generates sets of a given number of elements
and of a given maximum depth. (A set with no subsets
as elements has depth 0.) The atomic elements of a set
are randomly selected from an array which includes the
atoms HI, 32 and DOG. The length and depth of the set
are themselves random numbers in ranges that are input
to the set generator routine.
The program computes the union of the sets (HI 32)
and ((DOG». The union is the set ((DOG) HI 32).
This result is compared to the student's response. The
computer tutor analyzes the differences between the
desired and obtained answers and, in this case, exhibits
the terms missing from the student's answer.
The path we have followed in Figure 3 is L1, L2, L5,
254
Fall Joint Computer Conference, 1970
L6, L7, L9, and L1l. We shall follow a different path
below and let the student generate sets.
C. : Type two sets and I will tell you their union.
S.: (AS AS) (B D).
C. : (AS AS) is not a set. Do you understand why?
S.: No.
C. : AS are duplicate elements in your first set.
Type two more sets.
S.: (A V D) ( ).
C.: The union of (A V D) and ( ) is (A V D) ...
TABLE I-Diagnostic Program for Set Union and Some Possible
Comments
Cases Determined by
Diagnostic Program
1. A=8 1 u8 2 (set equality)
C. : Would you like to quiz me ? You type in two
or more sets and I will find the union. Then
you type whether I am right or wrong ...
S.: (RST) ().
C.: The union is (R S T).
S.: Wrong.
C. : No, you're wrong. I was right. Do you see
why?
S.: No.
C. : Type what you think the union is.
S.:
(R S T).
C.:
S.:
C.:
S.:
C. :
But that's what I typed. Type some sets.
(A B) (A).
The union is (A).
Wrong.
Oh my goodness! I did make a mistake ...
We expanded the previous path to include box L4. The
tutor now may make mistakes, and the student has an
opportunity to play teacher. If, when asked "Type what
you think the union is," the student had typed
"(T R S)," the tutor's response would have been: "The
sets (R S T)and (T R S) are equal." Here we have
followed the path L1, L3, L4, LS', L6 /, L8, L7, L9
and L1l.
The tutor gives a final test to the student. In it, the
following appears:
C. : What is the union of the following sets:
(BIRD ( ) S7) (S7 (DOG) 32 87)?
S. : Impossible.
C. : You caught me. The second list was not a set.
There is nothing like giving impossible problems!
Your answer is correct.
Your answer is incorrect.
2-1.
(81U82)-A~()
2-1-1. «8 1 U 8 2) -A)
The inputs proposed by the student are checked for
well-formedness. The program finds that (AS AS) is not
an acceptable representation for a set since the element
AS is repeated. An appropriate diagnostic message is
given. The path in Figure 3 was L1, L3 and LS', with a
return to Ll. Next the student wants to determine how
union operates with the empty set. The path followed
was again L1, L3, and LS'.
We allow the tutor to make mistakes and give the
student a chance to catch them.
Possible Partial Comments
to Student
n 81~(
)
You left out some element(s).
You left out some element(s) of
the first set.
2-1-2. «8 1 U 8 2) -A)
n 82~( )
You left out some element(s) of
the seconp. set.
2-2. A -(8 1 U 82)~( )
Some element(s) in your answer
are neither in 8 1 nor in 8 2 •
We have not yet coded the introspection program
that would explain to the student how the performance
program calculates set unions. Table I lists diagnoses
that can be used in teaching set union. The two sets are
S1 and S2: the student's answer is A. We assume that
all sets have been checked for well-formedness. U, n
and - denote set union, intersection and difference.
The tutor can diagnose not only that (for instance in
Table I, case 2-2) some elements in the answer should
not have been there, but also tell the student which
elements these are. Table II lists dIagnoses that can be
used in teaching set intersection. The two tables show
how algorithmic computations allow the computer tutor
to pinpoint the student's errors.
TABLE II-Diagnostic Program for Set Intersection and Some
Possible Comments.
Cases Determined by
Diagnostic Program
1. A =8 1 n 8 2 (set equality)
2.
A~81n82
2-1.
(81n82)-A~()
Possible Partial Comments
to Student
Your answer is correct.
Your answer is incorrect.
You left out some element(s)
which belong to both 8 1 and 82.
Some elements in your answer
do not belong to both 8 1 and 8 2 •
Some element(s) in your answer
belong to 8 2 but not to 8 1 •
Some element(s) in your answer
belong to 8 1 but not to 8 2 •
Some elements in your answer
are neither in 8 1 nor in 8 2 •
Computer Tutors That Know What They Teach
The symbol-manipulating capabilities required of the
computer tutor would be difficult to program using one
of the computer languages that were designed specifically to write CAl programs.
RECIPE FOR A KNOWLEDGEABLE
COJ\1PUTER TUTOR
The framework of Figure 3 shmvs explicitly how a
knowledgeable computer tutor can be built. First, we
need a performance program which can do what we want
the student to learn. We have programs that appear to
know areas of arithmetic, algebra, geometry, group
theory, calculus, mathematical logic, programming
languages, board games, induction problems, intelligence tests, etc. The computer models which have been
developed in physics, chemistry, sociology, economics,
etc., are other examples of performance programs. To
complete the computer tutor, attach to the performance
program appropriate generator, diagnostic, strategy and
introspection programs.
We used our recipe for a knowledgeable computer
tutor to develop a tutor to teach elementary set theory
and gave examples of the capabilities of this tutor. The
manpower requirements for the development of a
computer tutor are considerable and we have not
applied the recipe to other areas. Our demonstration,
therefore, remains limited but we hope that it was
sufficiently convincing to encourage other researchers to
develop more knowledgeable and powerful computer
teaching systems.
The major difficulty that we experienced was in the
area of the topic of understanding of the diagnostic
program. In particular, linguistic student responses
could not be handled in general. Presently, we only
accept very limited student answers expressed in natural
language. The development of computer programs
which better understand language* would lead to a
much more natural interaction between student and
tutor.
CONCLUSION
:\1ost CAl programs cannot answer student questions
for the simple reason that these programs do not know
* See Simmons8 for an effort in that direction.
255
the subject matter they teach. We have shown how
programs that can perform certain tasks could be
augmented into computer tutors that can at least solve
problems or answer questions in the subject matter
under consideration. We gave as an example a program
to teach set theoretical union and showed the diagnostic
capabilities of the tutor. These capabilities are based on
programs and are not the result of clever prestored
examples.
The student-tutor interaction will become less
constrained after enough progress has been made in
computer understanding of natural language.
ACKNOWLEDGIVIENTS
J. Peterson and S. Slykhouscontributed significantly to
this research effort.
REFERENCES
1 H A LEKAN
I ndex to computer assisted instruction
Sterling Institute Boston Mass 1970
2 L UHR
The automatic generation of teaching machine programs
Unpublished report 1965
3 J D WEXLER
A self-directing teaching program that generates simple
arithmetic problems
Computer Sciences Technical Report ~ 19 University of
'Wisconsin Madison Wisconsin 1968
4 C A PEPLINSKI
A generating system for CAl teacMng of simple algebra
problems
Computer Sciences Technical Report ~ 24 University of
Wisconsin Madison Wisconsin 1968
5 W R UTTAL T PASICH M ROGERS
R HIERONYMUS
Generative computer assisted instruction
Communication ~ 243 Mental Health Research Institute
University of Michigan Ann Arbor 1969
6 E B HUNT
Selection and reception conditions in grammar and concept
learning
J Verbal Learn Verbal Behav Vol 4 pp 211-215 1965
7 E CROTHERS P SUPPES
Experiments in second-language learning
Academic Press New York New York Chapter 6 1967
8 R F SIMMONS
Linguistic analysis of constructed student responses in CAl
Report TNN-86 Computation Center The University of
Texas at Austin 1968
\
Planning for an undergraduate level computer-based
science education system that will be responsive
to society's needs in the 1970's
by JOHN J. ALLAN, J. J. LAGOWSKI and MARK T. MULLER
The University of Texas at Austin
Austin, Texas
Digital computer systems have now been developed
to the point where it is feasible to employ them with
relatively large groups of students. As a result, defining
the problems involved in the implementation of computer-based teaching techniques to supplement classical
instructional methods for large classes has become a
most important consideration. Whether the classes are
large or small, colleges and universities are faced with
presenting increasingly sophisticated concepts to continually-expanding numbers of students. Available teaching facilities, both human and technical, are increasing
at a less rapid rate than the student population. Typically, the logistics of teaching science and engineering
courses becomes a matter of meeting these growing demands by expanding the size of enrollments in lectures
and laboratory sections.
It is now apparent that we can no longer afford the
luxury of employing teachers in non-teaching functions
-whether on the permanent staff or as teaching assistants. Many chores such as grading and record keeping
as well as' certain remedial or tutorial functions do not
really require the active participation of a teacher, yet
it is the person hired as a teacher who performs these
tasks. Much of this has been said before in various contexts; however, it should be possible to solve some of
these problems using computer techniques. In many
subjects, there is a body of information that must be
learned by the dtudent but which requires very little
teaching by the instructor. Successful methods must be
found to shift the onus for learning this type of material
onto the student thereby premitting the instructor more
time for teaching. Thus, computer techniques should be
treated as resources to be drawn upon by the instructor
as he deems necessary, much the same as he does with
books.
Basically, the application of computer techniques is
supplemental to, rather than a supplantation oj, the
INTRODUCTION
The purpose of this paper is to discuss the planning of
an undergraduate level computer-based educational
system for the sciences and engineering that will be
responsive to society's needs during the 1970's. Considerable curriculum development research is taking
place in many institutions for the purpose of increasing
the effectiveness of student learning. Despite the efforts
under way, only limited amounts of course matter using
computer-based techniques are available within the
sciences and engineering.
Planning for a frontal attack to achieve increased
teaching effectiveness was undertaken by the faculty
of The University of Texas at Austin. This paper presents the essence of these faculty efforts.
An incisive analysis of the state of the art with regard
to the impact of technology on the educational process
is contained in the report "To Improve Learning" generated by the Commission on Instructional Technology
and published by the U.S. Government Printing Office,
March, 1970. 1 The focus is on the potential use of technology to improve learning from pre-school to graduate
school. The goals stated in the above report are (1) to
foster, plan, and coordinate vast improvements in the
quality of education through the application of new
techniques which are feasible in educational technology,
and (2) to monitor and coordinate educational resources.
AN OVERVIEW OF COMPUTER-BASED
TEACHING SYSTEMS
Until recently, interest in using machine-augmented
instruction has been centered primarily on research in
the learning processes and/or on the design of hardware
and software.
257
258
Fall Joint Computer Conference, 1970
human teacher. The average instructor who has had
little or no experience with computers may be awed by
the way the subj ect matter of a good instructional
module can motivate a student. If the program designer
has been imaginative and has a mastery of both his subject and the vagaries of programming, the instructional
module will reflect this. On the other 'hand, a pedantic
approach to a subject and/or to programming of the
subject will also unfortunately be faithfully reflected in
the module. Thus, just as it is impossible to improve a
textbook by changing the press used to print it, a computer-based instructional system will not generate quality in a curriculum module. Indeed, compared with
other media, computer methods can amplify pedagogically poor techniques out of proportion.
The application of computer techniques to assist in
teaching or learning can be categorized as follows:
1. Computer Based Instruction (CBI)-this connotes interactive special purpose programs that
either serve as the sole instructional means for a
course or at least present a module of material.
2. Simulation
a. of experiments
1. that allow "distributions" to be attributed
to model parameters
2. that are hazardous
3. that are too time consuming
4. whose equipment is too expensive
5. whose principles are appropriate to the
student's level of competence, but whose
techniques are too complex
b. for comparison of model results with measurements from the corresponding real equipment
3. Data Manipulation (can be interpreted as customarily conceived computation) for
a. time compression/expansion-especially in
the laboratory, as in data acquisition and reduction with immediately subsequent "trend"
or "concept" display
b. advanced analysis in which the computation
is normally too complex and time consuming
c. graphic presentation of concepts-possibly
deflections under dynamic loading, molecular
structures, amplitude ratio and phase lead or
lag, ...
4. Computer-Based Examination and Administrative
Chores to accompany self-paced instruction.
SYSTEM DESIGN PHILOSOPHY
Design concepts that foster a synergistic relationship
between a student and a computer-based educational
system are based upon the following tenets:
1. The role of the computer in education is solely
that of a tool which can be used by the average
instructor in a manner that (a) is easy to learn,
(b) is easy to control, and' (c) supplements instructional capability to a degree of efficiency unattainable through traditional instructional
methods.
2. Computer-based' education, although relatively
new, has progressed past the stage of a research
tool. Pilot and experimental programs have been
developed to the point where formal instruction
has been conducted in courses such as physics2
and chemistry.3.4 Despite this, the full potential
of these new techniques has yet to be realized.
Future systems, that are yet to be designed, must
evolve which will provide sufficient capacity,
speed and flexibility. These systems must be
able to accommodate new teaching methods,
techniques, innovations and materials.
Programming languages, terminal devices and
communications should be so conceived as to not
inhibit pedagogical techniques which have been
successfully developed over the years. The system should incorporate new requirements which
have been dictated through progressive changes
in education and adjust without trauma or
academic turbulence.
3. Initial computer-based instructional systems
should be capable of moderate growth. Their role
will be that of a catalyst to expedite training of
the faculty as well as a vehicle for early development of useful curriculum matter. Usage by
faculty will grow in parallel with evolving plans
for future systems based upon extensive test
and evaluation of current course matter.
The design of individual instructional modules to
supplement laboratory instruction in the sciences and
engineering will follow the general elements of the systems approach which has gained acceptance in curricular development. 5 This approach to curriculum design
can generally be described as a method for analyzing
the values, goals, or policies of hu'man endeavor. The
method as applied to computer-assisted instruction has
been described in detail by Bunderson. 6
Although there have been several different descriptions of the systems approach to the design of curricular
materials, two major elements are always present:
course analysis and profiling techniques. Course analysis consists of
1. a concise statement of the behavioral objectives
Computer Based Science Education System
of the course expressed in terms of the subject
matter that is to be learned.
2. the standard that each student must reach in the
course.
3. the constraints under which the student is expected to perform (which may involve an evaluation of his entering skills).
The results of the course analysis lead to an implementation of the suggested design by incorporating a
curriculum profile ("profile techniques"), which contains
L function analysis, i.e., the use of analytical
factors for measuring the parameters of a task
function
2. task analysis,7 i.e., an analysis that identifies in
depth various means or alternative courses of
action available for achieving specific results
stated in the function analysis
3. course synthesis, the iterative process for developing specific learning goals within specific
modules of instructional material.
A general flow diagram which shows the relationship
between the elements in the systems approach to curriculum design appears in Figure L
STATEMENT
OF
CONSULTANTS
BEHAVIORIAL
OBJECT IVES
PRODUCTION
OF
MATERIALS
259
Goals and behavioral objectives
Some of the longer range goals defined should be to
demonstrate quantitatively the increased effectiveness
gained by computer,:-based techniques and further, to
develop skill in the faculty for "naturally" incorporating
information processing into course design. Another long
range goal should be to effect real innovation in the
notions of "laboratory courses" and finally, to instill in
graduating students the appreciation that computers
are for far more than "technical algorithm execution."
In more detail, some of the goals are to:
L Plan, develop and produce computer-based
course material for use in undergraduate science
and engineering courses to supplement existing
or newly proposed courses. Course matter
developed will utilize a systems approach and
consider entering behaviors, terminal objectives,
test and evaluation schema, provisions for revision, and plans for validation in an institutionallearner environment.
2. Produce documentation, reports, programs and
descriptive literature on course matter developed
to include design and instructional strategies,
flow charts and common algorithms.
3. Test course matter developed on selected classes
or groups for the purpose of evaluation, revision
and validation. This is to determine individual
learner characteristics through use of techniques
such as item analysis, and latency response using
interactive languages.
4. Promote and implement an in-depth faculty involvement and competency as to the nature,
application and use of computer-based instructional languages, course matter and techniques.
5. Compile, produce and make provisions for mass
distribution of such computer-based materials
as are tested, validated and accepted for use by
other colleges or institutions participating in
similar programs.
In an academic environment the use of time-sharing
computers for education is gradually being incorporated
as a hard-core element, which in time will become so
commonplace a resource for faculty and student use
that it will serve as an "educational utility" on an interdisciplinary basis. To achieve a high degree of effectiveness of such systems, the faculty using computerbased teaching techniques as a supplement to laboratory
type instruction must initially become involved. The
pedagogical objectives of this whole approach are:
Figure i-Systems approach to curriculum design
1. To correct a logistic imbalance: i.e., a condition
marked by the lack of a qualified instructor and/
260
Fall Joint Computer Conference, 1970
2.
3.
4.
5.
6.
7.
or the proper equipment and facilities to perform
a specific teaching task (or project) being at a
specific place at a specific time.
To provide more information per unit time so
that, as time passes, the course will provide inincreasingly in-depth knowledge.
To allow new ranges of material to be covered
when one specifically considers things currently
omitted from the curriculum because of student
safety or curriculum facility costs.
To increase academic cost effectiveness, because
it is certainly expected that adroit information
processing will free the faculty from many
mundane tasks.
To provide both parties with more personal time
and flexibility, because it is anticipated that considerable amounts of time are to be made free
for both student and faculty.
To make a computer-based system the key to the
individualization of mass instruction by utilizing
dial-up (utility) techniques.
To develop laboratory simulation so that it is
no longer a constriction in the educational pipeline because of limited hardware and current
laboratory logistics.
Evaluation criteria
In general, there are two distinct phases to the evaluation ot instructional modules. The first of these coincides
with the actual authoring and coding of the materials,
and the second takes place after the program has advanced to its penultimate stage. These two types of
evaluation can be referred to as "developmental testing" and "validation testing," respectively.
Developlllental testing
This testing is informal and clinical in nature and
involves both large and small segments of the final
program. The specific objective of this phase of the
development is to locate and correct inadequacies in
the module. It is particularly desirable at this point of
development to verify the suitability of the criteria
which are provided at the various decision points in
the program. It is also anticipated that the program's
feedback to the students can be improved by the addition of a greater variety of responses. Finally, testing
at this stage should help to uncover ambiguous or incomplete portions of the instructional materials.
Relatively few students (about 25) will be required
at this stage of evaluation; however, since this phase
is evolutionary, the exact number will depend on the
nature and extent of the changes that are to be, and
have been, made. Materials which are rewritten to
improve clarity, for example, must be retested on a
small scale to establish whether an improvement has
in fact been made. A final form of this program, incorporating the revisions based on this preliminary
testing, will be prepared for use by a larger group of
students.
Validation testing
The formal evaluation of the programs will occur in
a section (or with a part of a section) of a regularly
scheduled class.
It is assumed that a selection of students can be obtained that is representative of the target population
for which the materials are designed. One of the following two methods for obtaining experimental and control groups is suggested, depending upon circumstances
existing at the time of the study (i.e., number of sections available, whether they are taught by the same
instructor, the willingness of instructor to cooperate,
section size, etc.).
The preferred method is to arbitrarily designate one
course section experimental and one course section
control with the same instructor teaching both sections.
An assumption here is that the registration procedure
results in a random placement of students in the sections. The alternative method of selecting students
follows. The instructional programs are explained to
the total student group early in the semester, and a
listing of those students who are willing to participate
is obtained. Two samples of approximately equal size
are randomly selected from this list. One sample of
students is then assigned to work with the computerassisted instructional facilities and is designated as
the experimental group.
The criteria used to evaluate the programs are as
follows:
1. The extent to which students engage in and/or
attain the behavioral objectives stated for the
program. For tutorial and remedial programs
pre- and post-tests are the instruments for
measuring attainment and will help answer the
question: Does the computer-based supplement
actually teach what it purports to teach? For
experiment simulations, the successful completion of the program is prima facie evidence that
the student has engaged in the desired behaviors.
2. Achievement as measured by the course final
examination.
Computer Based Science Education System
TABLE I-Curriculum Development Research Tasks
CONTROL
EXP.
SAME INSTRUCTOR
STANDARD I ZED
STANDARDIZED
AREA EXAM
AREA EXAM
FORM 1
FORM 1
ATTITUDE
ATTITUDE
INVENTORY
INVENTORY
COURSE CONTENT
+
Task
Title
COURSE
CONTENT
PRE-TEST CAl
~
I
I
I
I
FINAL EXAM
I
I
I
.~ I ND I CATES OVERALL
EFFECT AND EFFECT ON
_-------1.------1
2; I.=>
STANDARDIZED AREA EXAM FORM
ATTITUDE INVENTORY
I
I
I
I
I
EFFECT
RETENTION
INDICATES' NET GAIN IN
LEARNING AND CHANGES
STATISTICAL ANALYSIS OF DATA:
TECHN I QUES
Department
Dr. J.J.A.
Assistant
Professor
Mech. Engr.
Aerospace
Structural
D, IG, MM,
PrS, Sim, Stat,
Res
Dr. E.H.B.
Assistant
Professor
Aero. Engr.
Theoretical
Chemistry
Sim, D, Rsim
Dr. F.A.M.
Professor
Dr.R.W.K.
Faculty
Associate
Chemistry
Biophysical
Analysis
SIM, Rsim, Stat Dr. J.L.F.
Assistant
Professor
Zoology
IN ATTITUDE
I
THE EQUIVALENT OF AN ANALYSIS OF
COVARIANCE USING REGRESSION
Research
Investigator
D,IG,MM,
PrS, Res
__ J_______ t ___ ~
I
I
~ INDICATES IMMEDIATE
I
I
Type
Application
Machine
Element
Design
SUPPLEMENT
POST-TEST
HOUR EXAM OVER COURSE CONTENT
261
I
I
I
I
L! ____________ ::.1
Application Code
D-Drill and Practice; G-Graphics; IG-Interactive Graphics;
MM-Mathematical Modeling, Gaming; PrS-Problem Solving;
OLME-On Line Monitoring of Experiments; Sim-Simulation;
Rsim-Real Experiments Plus Simulation; Stat-Statistical Data
Processing ; Res-Research in Learning Processes.
Figure 2-Test and evaluation schema for overall program
3. Net gain in achievement as determined by preand post-testing with the appropriate standardized area examination.
4. Changes in student attitudes as measured by
pre- and post-attitude inventories.
The statistical treatment used to evaluate the programs in light of the above criteria will be a multiple
linear regression technique equivalent to analysis of
covariance for criteria 2 and 3. The covariables used
will include, (1) A placement exam score (if available);
(2) the beginning course grade (for students in advanced courses); (3) sex; (4) SAT* scores, high school
GPA**; and (5) other pertinent information available
in the various courses. The key elements of the test
and evaluation schema are shown schematically in
Figure 2.
IMPLEMENTATION
Planning is one of the most important aspects of
CBI and when done properly yields what we might
call a "systems approach" to curriculum or course
design. This means not only the setting up of a course
* Scholastic Aptitude Test.
** Grade Point Average.
of instruction by following a comprehensive, orderly
set of steps, but also a plan for involving other faculty.
No two curriculum designers will agree as to what
constitutes the essentials in outlining a course in its
entirety before beginning. However, there are certain
sequential or logical steps that can be defined precisely.
These steps have been designated below as the course
planning "mold" and are based upon actual in-house
experience in planning, developing, testing and evaluation of course matter. Examples of this planning as
shown in the entries in Tables I and II are authentic
TABLE II-Curriculum Development Research Task Cost
Task Title
Total
Duration Dollar
(Mo.)
Value*
Personnel
Cost
Computer
Time
Cost
Elements of
Design
27
$72,440.
$31,120.
$41,320.
Aerospace
Structures
31
$111,720.
$45,920.
$65,800.
Theoretical
Chemistry
24
$53,150.
$36,900.
$16,250.
Biophysical
Analysis
19
$43,250.
$23,600.
$19,650.
* Not including hardware cost.
262
Fall Joint Computer Conference, 1970
and have been derived by requesting each new associate
investigator to fit the approach to beginning his work
into a "mold." Descriptive material for each prospective participating faculty member is shown in the
following example, * and is organized as follows:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
Title
Introduction
Objectives
Project Description
Method of Evaluation
Impact on the Curriculum
Pedagogical Strategy
Current or Past Experience
Related Research
Plans for Information Interchange
Detailed Budget *
Time Phasing Diagram
Application Cross-Reference Chart
EXAMPLE OF A PROSPECTIVE ASSOCIATE
INVESTIGATOR'S PROPOSAL:
INTERACTIVE DESIGN OF MACHINE
ELEMENT SYSTEMS
machine elements. One of the primary goals is to allow
students to consider machine element systems instead
of the traditional approach of the machine elements.
The object of this is to show the interplay of the
deflections and stresses due to imposed forces on
machine element systems. Another objective is to
allow distributions to be attributed to parameters of
systems normally considered as discrete. Latest in the
series of engineering texts are those that consider
probablistic approaches to design. Finally in the
design process, by definition, a task performed at one
instant in time does not give the observer of a designer
any information about what the designer's next task
might be. Hence, it' is most important to construct an
environment that will allow the student to "meander"
through the myriad of possibilities of. alterations of a
nonfeasible solution of a design problem that might
make it subsequently a feasible solution. Another objective of using an interactive system is so considerations not necessarily sequential in an algorithmic sense
can be superposed for the student's consideration. That
is, he can consider system reliability, system structural
integrity, and system economics simultaneously and
make design decisions based on anyone of those
fundamental considerations.
In troduction
Project description
Engineering design is a structured information/
creative process. The synthesis of physically feasible
solutions generally follows many design decisions based
on processed available information. The structure of
design information has been defined in the literature. 8
Processing this design information in a scientific and
logical method is important to the understanding of
how one teaches engineering design, particularly the
part that computer augmentation might play in the
process. Essentially, the computer can relieve the engineering designer of those aspects of problem manipulation and repetitive computation that might otherwise
distract him from the context of his problem. The
fundamental principle here is to have the designer
making decisions, not calculations.
Objectives
There are several objectives to being able to put a
student in an interactive situation for the design of
* It should be emphasized that the courses listed in Tables I and
II represent only a portion of the curriculum matter which is
being or needs to be developed.
* Sample forms for items 11, 12, and 13 can be obtained from the
authors. The form for item 11 in particular gives the details
necessary to arrive at a project's estimated dollar cost.
This project involves the integration into a conventional classroom of one or more reactive CRT displays.
The addition of computer augmentation to the traditional teaching of engineering element systems design
is proposed, in order to satisfy the needs of the undergraduate student who would like to be able to synthesize and analyze more realistic element systems than
is now pedagogically possible. The following specific
desired functions in the computer-based system are
necessary to make it an easily accessible extension to
the student designer's functional capabilities:
1. Information storage and retrieval-The system
must be able to accept, store, recall, and present
those kinds of information relevant to the designer. For example, material properties, algorithms for analyzing physical elements, conversion factors, etc.
2. Information Interchange-The system must be
able to interact with the designer conveniently
so that he can convey information with a minimum of excess information during the operation
of the system. 8
3. Technical Analysis Capabilities-The system
must be able to act on the information pre-
Computer Based Science Education System
sented, analyze it, and present concise results
to the designer.
4. Teaching and Guidance Capabilities-The system must provide the student designer with information necessary to enable him to use the
system and also to tutor him in the context of
his problems.
5. Easy Availability-The system should be available to the student user and adaptable to his
modifications.
'
In essence this project can be described as the design
and implementation of a computer-based reactive
element design system which would be as integral a
part of a teaching environment as the blackboard,
doors and windows. Further, in this project the amount
of additional material in terms of reliability, value
analysis, noise control and other modern engineering
concepts that can be integrated into the standard
curriculum can be conveyed more effectively and to a
deeper degree.
Method of evaluation
The effectiveness of this method will be evaluated
by presenting the students with more comprehensive
design problems at the end of the semester. Several
observations would be made. First, they would be
able to take into account more readily the interaction
between systems elements in a mechanical network.
They should not require as many approximations with
respect to fatigue life, method of lubricating bearings,
etc.
Illlpact on the curricululll
The effect on the curriculum will be as follows. The
Mechanical Engineering Department at The U niversity of Texas has what is known as "block" options.
In this way, a student in his upper-class years may select
some particular concentrated area of study. Part of the
material that he now receives in one of his block courses
366N could be moved back to his senior design course
366K. The effects on the curriculum should be to free,
for additional material, one-half semester of a threehour course at the senior undergraduate level for those
maj oring in design.
Pedagogical strategy
The strategy of the course at present is the solution
of authentic design problems solicited from industry.
263
However, all analysis techniques are currently confined to paper and pencil with computer algorithms
where practical. The new strategy will add the ability
to analyze mechanical systems networks on an interactive screen and have an opportunity to manipulate
many possible ideas (both changes in topology and
changes in parameters) per unit time.
Current or past experience
The investigator has spent several years on the development of interactive graphic machine design
systems both in industry and in academic institutions.
Further, the investigator has been teaching the design
of machine element systems since 1963 and prior to
that practiced design of machine element systems since
1958.
Related research
Professor Frank Westervelt at the University of
Michigan is currently conducting research in the area
of interactive graphic design. His maj or emphasis is
on the design of the executive systems behind interactive computer graphic systems. Dr. Milton Chace also
at the University of Michigan uses some software generated by Dr. Westervelt's group. His concentration is
on using Lagrange's method to describe dynamic
systems and be able to manipulate the problem's
hardware configurations on the screen. Professor
Daniel Roos of the MIT Urban Systems Laboratory is
now putting a graphic front end on his ICES system.
Professor Gear at the University of Illinois has a system
running on a 338/360-67 system and his primary interest there is to work with people who are manipulating electrical network topologies and doing network
analysis. Professor Garrett at Purdue University is
using graphic terminal access to his university's computer for performing a series of analyses on mechanical
engineering components.
The unique aspect of the work that is envisioned
here, as opposed to all above mentioned relative works,
is primarily that it will be an instructional tool. That is,
the computer is recognized as an analysis tool, a
teacher, and an information storage and retrieval
device.
With respect to each of the above, there are two
connotations. With respect to analysis, the computer
will perform analysis in its traditional sense of engineering computation and it will also analyze the
topology of mechanical systems as drawn on the screen
such that the excess information between the designer
and the computer will be reduced. Concerning teaching,
264
Fall Joint Computer Conference, 1970
the computer will work with the student not only to
teach him how to use the system, but also in another
sense it will help him learn about his problem's context
by techniques such as unit matching and unit conversion and checking topological continuity before allowing engineering computations. With respect to information storage and retrieval, traditional parameters such
as material yield strengths and physical properties of
fluids will be available.
Another concept in interactive design will be developed when the system can work with the student
and help him optimize apparently continuous systems
made up of objects such as bearings that only come in
discrete quantities, for instance VB inch increment bores,
etc.
Plans for inforInation interchange
Information interchange, of course, has two meanings: (1) how to get information from other schools to
the University of Texas, and (2) how to disseminate
the results of my research to other interested parties.
It is the responsibility of the principal investigator to
insure that information from professional society
meetings, personal visits to other campuses, research
reports, published articles, personal communication,
and "editorial columns" in both regional and national
newsletters of societies such as ASME, IEEE, SID,
SCI, ACM, and others are disseminated to his research
associates.
Further, it is the researcher's responsibility to generate research reports, published articles, take the responsibility for keeping his latest information in
"news items," attend meetings, and write personal
letters to other people in the field who are interested
to help keep them abreast of his current research
activity.
EXPERIENCES TO DATE
Completed projects
During the academic year 1968-69 two pilot projects
were conducted on the use of computer-based techniques in the instruction of undergraduate chemistry.
Fifteen curriculum modules were written for the General Chemistry project and eight for Organic Chemistry.
In each instance the modules covered subjects typical
of the material found in the first semester of each course.
Each module was "debugged" and polished by extensive use of student volunteers prior to use in the pilot
studies. In each study, the modules were used to supplement one section of the respective courses under con-
trolled conditions. Results from this two-semester
study on computer-based applications in organic
chemistry indicate a high degree of effectiveness. Not
only was the study effective in terms of student score
performance, but also in terms of outstandingly
favorable attitudes towards computer-based instruction
by students and professors.
Concurrently, faculty members of the College of
Engineering have also conducted various courses using
computer-based techniques. Dr. C. H. Roth of the
Electrical Engineering Department has developed a
computer-assisted instructional system that simulates
a physical system and provides computer-generated
dynamic graphic displays of the system variables. 9 An
SDS 930 computer with a display scope is used for this
project. The principal means of presenting material to
the students is via means of visual displays on the
computer output scope. A modified tape recorder provides audio messages to the student while he watches
the scope displays. A flexible instructional logic enables
the presentation of visual and audio material to the
student and allows him to perform simulated experiments, to answer questions (based on the outcome of
these experiments) and provides for branching and help
sequences as required. Instructional programming is
done in FORTRAN to facilitate an interchange of
programs with other schools.
Dr. H. F. Rase, et al.,l0 of the Chemical Engineering
Department have developed a visual interactive display for teaching process design using simulation techniques to calculate rates of reaction, temperature profiles and material balance in fixed bed catalytic reactors.
Other computer-based instructional programs developed include similar modules in petroleum engineering and mechanical engineering. In each instance, the
curriculum modules are used to supplement one or more
sections of formal courses. In several instances it is
possible to measure the course effectiveness against a
"control" group. Course modules generally contain
simulated experiments, analysis techniques using computer graphics, and some tutorial material.
The general objectives for all of the aforementioned
studies are as follows:
1. To give the students an opportunity to have
simulated laboratory experiences which would
otherwise be pedagogically impossible.
2. To provide the students with supplemental
material in areas which experience has shown to
be difficult for many students.
3. To provide a setting in which the student is allowed to do a job that professionals do; ·i.e.,
collect, manipulate and interpret data.
4. To give the student the feeling that a real, con-
Computer Based Science Education System
cerned personality has been "captured" in the
computer to assist him.
5. To individualize the student-computer interactions as much as possible by allowing the
student to pace himself.
6. To give the student a one-to-one situation in
which he can receive study aid.
Present state of computer-based learning systems
Curriculum development in engineering and the
sciences is being accomplished within the University
of. Texas through the Computation Center CDC-6600
system using conversational FORTRAN within the
RESPOND time-sharing system. Also, small satellite
pre- post-processors such as a NOVA, a SIGMA 5 and
anSDS-930 are linked to the CDC-6600. Of special
significance is the Southwest Regional Computer Network (SRCN) which is now in the early stages of use
and is built around the CDC-6600. Some eight intrastate colleges and universities are linked. Workshop
and user orientation sessions are still under way concurrent with curriculum development. The integration
of course matter for this network will be accomplished
during the next two to three years. A discussion of the
factors involved in curriculum software development
and some evaluation aspects follows.
Cost factors and management considerations
When developing an accounting system for examining
the cost of generating software for teaching, one readily
realizes that there is the traditional coding and the
subsequent assembly. and listing. However, because
academic institutions frequently have this class of
endeavor funded from agency sources, a next step is
very frequently hardware installation (if the terminals
or the central processor have not been "on board" prior
to the initiation of the research). Once the hardware is
available, however, on-line debugging can take place
and the first course iteration can begin. The next step
is the first course revisiQn in which the material is rewritten, possibly restructured, to take advantage of
experiences on the first pass. Then, the second course
iteration is performed and finally the second course
revision.
The estimates for coding, assembly, listing, and
debug time, etc., are a function of
1. the computer operating system and its constraints.
2. the coding proficiency of the professionals involved.
265
3. the way in which the computer is supposed to
manifest itself, that is:
a. as a simulation device in parallel with the
real experiment,
b. as purely a simulation device,
c. as a base for computer-augmented design,
d. for data acquisition,
e. for computer-based quizzes,
f. for computer-based tutorial and drill,
g. or finally, for computation.
4. the degree of reaction required, that is in the
physiological sense, how the computer must
interact for the user's latent response.
5. the extent of the data base required and the
data structure required to allow one to manipulate that data base.
The primary considerations are organization and
control. In this work the organization consists of the
following. At each college there is a project coordinator
who is the line supervisor for the secretarial services,
programming services, and technical implementation
services, and who acts as the coordinator for
consultants.
At the University level there exists a review panel,
composed of members of the representative colleges
and several people trom other areas such as educational
psychology and computing, which evaluates the works
that have been conducted in any six-month period and
also evaluates the request for continuation of funds to
continue a project to its duration. The actual fiscal
control of each project is with the project coordinator
of that particular college. Also, the purchase of equipment is coordinated at the college level.
The control as expressed above is basically a twostep control; a bi-annual project review, plus a budgetary analysis, is accomplished by an impartial review
panel. Their function is to act as a check on the context of the material presented and to recommend continuance of particular research tasks. As a further step,
this research is coordinated in all colleges by the Research Center for Curriculum Development in Sciences
and Mathematics.
SUMMARY
Dissemination of information
Dissemination of information is planned through (1)
documentation of publications in the form of articles,
reports or letters, (2) symposia to be held which cover
procedures and fundamentals for developing curriculum
in CBI and (3) furnishing of completed packages of
266
Fall Joint Computer Conference, 1970
course matter on computer tapes, cards or disks to
other colleges or institutions desiring, and able to use,
this material. Wide publicity will be given completed
course matter through such agencies as ERIC, ENTELEK and EDUCOM. The provision for continuing
periodic inputs to the above agencies will provide for
current availability of curriculum materials.
Future outlook
The future outlook for time-sharing in computerbased educational systems is extremely bright with
respect to hardware development. The advent of the
marketing of newer mini-computer models selling for
five to ten thousand dollars-some complete with a
limited amount of software-is already changing the
laboratory scene. The configuration of direct-connect
terminals, with the inherent advantage of installation
within one building, further enhances the use of this
type of system by eliminating the high expense of data
lines and telephones.
Software in the form of a powerful CBI language for
the sciences and engineering designed specifically for
minicomputers is perhaps one of the most important
needs. Rapid progress has been made in developing a
low cost terminal using plasma display or photochromic
technology, however, the promise of a low cost terminal
has yet to be realized.
A small college, high school or other institution may
be able to afford a small time-sharing computer system
with ten terminals that could meet its academic needs
for less than $36,000; however, still lacking isOthe vast
amount of adequate curriculum matter. Educators using
CBI are in the same position as a librarian who has a
beautiful building containing a vast array of shelves
but few books to meet academic needs of students or
faculty. The task of curriculum development parallels
the above situation and must be undertaken in much
the same manner as any other permanent educational
resource.
Educational benefits
Benefits that result from implementing this type
plan are a function of the synergistic interplay of (1)
personnel with expertise in the application of computerbased techniques, (2) computer hardware including interactive terminal capability, (3) faculty-developed
curriculum materials, and (4) the common information
base into which the entire research program can be
embedded.
The program can provide students with a learning
resource that serves many purposes. That is, the computer can be the base of a utility from which the user
can readily extract only that which he needs, be it
computation, data acquisition, laboratory simulation,
remedial review, or examination administration. At all
times the computer can simultaneously serve as an
educator's data collection device to monitor student interaction. This modularized dial-up capability can give
the students an extremely flexible access to many
time-effective interfaces to knowledge.
Administrative benefits
When this type project has been completed, all users
may have access to the results. This unified approach
can yield modules of information on cost accounting
which can be used as a yardstick by the University.
Further, this type project insures that data-yielding
performance is of a consistently high quality, and that
regardless of the subject matter on any research task
the depth of pedagogical quality is relatively uniform.
The subject matter developed can serve as the
basis for conducting experiments in teaching and continuing curricular reform. Indeed, the association of
faculty in diverse disciplines can serve as a catalyst for
curricular innovations in the course of preparing materials for computer-based teaching techniques.
The instructional efforts described here can serve as
the basis for displaying the unity of science and engineering to the undergraduate student in an indirect
way. For example, if a student is taking a set of science
courses in. a particular sequence because it is assumed
each course contributes to an understanding of the
next one, it is possible to use programs developed in
one course for review of remedial work in the next
higher course. Thus, an instructor in biology can assume a certain level of competence in chemistry without having to review the important points in the latter
area. Should some students be deficient in those aspects of chemistry that are important to the biology
course, the instructor can assign the suitable material
that had been developed for practice and drill for the
preceding chemistry course. With a little imagination,
the instructional system can make a significant impact
on the student by giving him a unified view of science
or enginering. It is possible to develop both a vertical
and horizontal structure for common courses which
can be used on an interdisciplinary basis for integration
in the basic core curriculum in the various departments
where computer-based techniques are used. The revision problem of inserting new and deleting old material in such a system is considerably simplified for
all concerned.
Computer Based Science Education System
There is a vast, largely unexplored area of applications. As time-sharing methods become more widespread, terminal hardware becomes less complex, and
teleprocessing techniques are improved, the potential
usefulness of computers in the educational process will
increase. With the technology and hardware already
in existence, it is. possible to build a computer network
linking industries and universities. Such a network
would (1) allow scientists and engineers in industry to
explore advanced curriculum materials, (2) allow those
who have become technically obsolete to have access
to current, specifically prepared curriculum materials,
training aids and diagnostic materials, (3) allow local
curriculum development as well as the ability to utilize
curriculum materials developed at the university, (4)
allow engineers to continue their education, (5) provide
administrators with an efficient and time-saving method
of scheduling employees and handling other data processing chores such as inventories, attendance records,
etc., and (6) provide industrial personnel with easily
obtainable and current student records to aid in giving
the student pertinent and helpful counseling and
guidance.
Although complaints have been voiced that computer-based techniques involve the dehumanization of
teaching, we argue to the contrary-the judicious use
of these methods will individualize instruction for the
student, help provide the student with pertinent
guidance based upon current diagnostic materials and
other data, and allow instructors to be teachers.
ACKNOWLEDGl\1ENTS
Special thanks are due Dr. Sam J. Castleberry, Dr.
George H. Culp, and Dr. L. O. Morgan (Director), of
the Research Center for Curriculum Development in
Science and Mathematics, The University of Texas at
Austin. Also, appreciation is extended to numerous
267
colleagues who have contributed to our approaches with
their ideas.
REFERENCES
1 To improve learning
US Government Printing Office March 1970
2 N HANSEN
Learning outcomes of a computer-based multimedia
introductory physics course
Semiannual Progress Report Florida State University
Tallahassee Florida 1967 p 95
3 S CASTLEBERRY J LAGOWSKI
Individualized instruction in chemistry using computer
techniques
J Chem Ed 47 pp 91-97 February 1970
4 L RODEWALD et al
The use of computers in the instruction of organic chemistry
J Chem Ed 47 pp 134-136 February 1970
5 R E LAVE JR D W KYLE
The application of systems analysis to educational planning
Comparative Education Review 12 1 39 1968
6 C V BUNDERSON
Computer-assisted instruction testing and guidance
W H Holtzman Ed Harper & Row New York New York
1970
7 R GAGNE
The analysis of instructional objectives for the design
In Teaching Machines and Programmed Learning II The
National Education Association Washington DC 1965
pp 21-65
8 J J ALLAN
Man-computer synergism for decision making in the system
design process
CONCOMP Project Technical Report 1(.9 University of
Michigan July 1968
9 E A REINHARD C H ROTH
A computer-aided instructional system for transmission line
simulation
Technical Report No 51 Electronics Research Center The
University of Texas Austin 1968
10 H FRASE T JUUL-DAM J D LAWSON
L A MADDOX
The use of visual interactive display in process design
Journal Chem Eng Educ Fall 1970
The telecommunications equipment marketPublic policy and the 1970's
by l\,IANLEY R. IRWIN
University of New Hampshire
Durham, New Hampshire
render service in 85 percent of the geographical sector
of the country and account for 15 percent of the remaining telephones in the U.S. The independents are
substantially smaller than AT&T and in decreasing
size include the General Telephone and Electronics
System, United Utilities, Central Telephone Company
and Continental Telephone respectively. Although
General is by far the largest, the independents have
experienced, over the past two decades, corporate
merger and consolidation.
Western Union Telegraph Company provides the
nation's message telegraph service, the familiar telegram and Telex, a switched teletypewriter service.
Recently, Western Union has negotiated with AT&T
to purchase TWX thus placing a unified switched network under the single ownership of the telegraph company. 2 In addition to their switched services, the carriers provide leased services to subscribers on a dedicated or private basis. In this area, both Western Union
and AT&T find themselves offering overlapping or
competitive services.
The carriers, franchised to render voice or non··
voice service to the general public, reside in an environment of regulation. Licenses of convenience and
necessity are secured from either Federal or state
regulatory bodies and carry with it a dual set of privileges and responsibilities. In terms of the former, the
carriers are assigned exclusive territories in which to
render telephone or telegraph services to the public
at large-a grant tendered on the assumption that competition is inefficient, wasteful, and unworkable. In
terms of the latter, the carriers must serve all users at
non·-discriminatory rates, submitting expenses, costs
and revenue requirements for public scrutiny and
overview. In the United States, the insistence that
utility firms be subject to public regulation rests on
the premise that economic incentives and public control are neither incompatible nor mutually exclusive.
INTRODUCTION
The growing interdependence of computers and communications, generally identified with developments
in digital transmission and remote data processing
services, has not only broadened the market potential
for telecommunication equipment but has posed several
important public policy issues as well. It is the purpose
of this paper to explore the relationship between the
telecommunications equipment market and U.S. telecommunication policy. To this end we will first survey
the traditional pattern of supplying hardware and
equipment within the communications common carrier industry and second, identify recent challenges
to that industry's conduct and practices. We will conclude that public policy holds a key variable in promoting competitive access to the telecommunication
equipment market-access that will redound to the
benefit of equipment suppliers, communication carriers, and ultimately the general public.
THE COMMUNICATION COMMON CARRIER
As a prelude to our discussion it is useful to identify the major communications carriers in the United
States. The largest U.S. carrier, AT&T, provides upwards to 90 percent of all toll or long distance telephone
service in the country. In addition to its long line division, AT&T includes some 24 telephone operating
companies throughout the U.S.; the Bell Telephone
Laboratory, the research arm of the system; and
Western Electric, the manufacturing and supply agent
of the system.! These entities make up what is commonly known as the Bell System.
The non-Bell telephone' companies, include some
1800 firms scattered throughout the U.S. These firms
269
270
Fall Joint Computer Conference, 1970
THE POLICIES AND PRACTICES OF THE
CARRIER
Given the carriers and their environmental setting,
three traits have tended to distinguish the communication industry in the past. These include, first, a
practice of owning and leasing equipment to subscribers; second, the policy of holding ownership interest in equipment suppliers and manufacturers;
and finally, a practice of taking equipment and hardware requirements from their supply affiliates. Each
of these policies has conditioned the structure of telecommunication equipment for several decades and
thus merits our examination.
Tariffs
In the past at least the carriers provided what they
term a total communication service. That service
embraced loops or paired wires, switching equipment,
interoffice exchange trunks and terminal or station
equipment. Prior to 1968, subscribers were prohibited
from linking their own telephone equipment to the
telephone dial network. This policy was subsumed
under a tariff generally termed the foreign attachment
tariff-the term "foreign" in reference to equipment
not owned or leased by the telephone company. Users
who persisted in attaching equipment not supplied
by the carrier incurred the risk of service disconnection.
Carrier non-interconnection policy extended to
private communication systems as well as user equipment. In the former case, the denial of interconnection
rested on the carriers apprehension that customers
would tap profitable markets. Accordingly, customer
interconnection would lead to profit cream skimming,
loss of revenues to carriers, and ultimately require
the telephone company to increase rates to the general
public or postpone rate reductions.
Interconnection was also said to pose problems of
maintenance for the utility. With equipment owned
partly by subscribers and owned partly by utility,
who would assume the burden of service and who
would coordinate the introduction of new equipment
and new facilities? Whether these problems were real
or imaginary, public policy sanctioned carrier ownership and control of related terminal equipment under
the presumption that divided ownership would compromise the systemic integrity of a complex and highly
sophisticated telephone network.
Telephone subscribers had little choice but to adjust to the foreign attachment prohibition. This meant
that of necessity equipment choices were restricted
to hardware supplied and leased by the carrier. Competitive substitutes were by definition minimal or
nonexistent. In fact the carrier's policy of scrapping
old equipment removed a potential used market from
possible competition with existing telephone equipment.
Integration
In addition to certain practices embodied as filed
tariffs, the carriers owned manufacturing subsidiaries.
The integration or common ownership of utility and
supplier thus marked a second characteristic of the
industry. Obviously Western Electric, the Bell System's
affiliate dominated the industry, and over the years,
accounted for some 84 to 90 percent of the market.
General Telephone's supply affiliates, acquired since
1950, accounted for some 8 percent of the market.
Together the two firms approached what economists
term a duopoly market; that is, two firms supplying
in excess of 90 percent of the market for telecommunication equipmen.t.3
Despite the persistence of integration, the efficacy
of vertical integration experienced periodic review.
In 1949, for example, the Justice Department filed
an antitrust suit to divest Western Electric from the
Bell System. 4 The suit premised on a restoration of
competition to the hardware market, asserted that the
equipment market could grow and evolve under conditions of market entry and market access. In 1956,
a consent decree permitted AT&T to retain Western
Electric as its wholly owned affiliate on the apparent
assumption that divestiture served as an inappropriate
means to achieve the goal of competition. 5 Instead,
market access was to be achieved by making available
Bell's patents on a royalty free basis.
Still later the Justice Department embarked on
another antitrust suit. This time the antitrust division
challenged General Telephone's acquisition of a West
Coast independent telephone company on grounds
that the merger would tend to substantially lessen
competition in the equipment market. 6 The General
suit felt the weight of the Bell Consent Decree. So
heavy in fact was the Bell precedent that the Department cited the 1956 Decree as grounds for dropping
its opposition to General Telephone's merger. 7
Procurement
A third practice inevitably followed the carrier's
vertical relationship; namely the tendency to take the
bulk of their equipment from their own manufacturing
affiliates. Perhaps such buying practices were inevitable.
Telecommunication Equipment Market
Certainly, in the carriers' judgment, the price and
quality of equipment manufactured in-house was
clearly superior to hardware supplied by independent
or nonintegrated suppliers.
Indeed, the courts formalized the procedure of determining price reasonableness by insisting that the
carrier rather than the regulatory agency assume the
burden of proof in the matter.8 The result saw the
arbitor of efficiency pass from the market to the dominant firm. Over the years the integrated supplier firm
has accorded itself rave reviews. Consultant's under
carrier contract repeated those reviews. But under the
existing rules of the game, one would hav~ hardly
expected the firm to act differently.
However long standing, the triad of tariffs, integration and procurement has held obvious implications
for independent suppliers of equipment and apparatus.
First, non-integrated suppliers found it difficult to
sell equipment to telephone subscribers given the enforcement of the foreign attachment tariff. Second,
the non-integrated supplier was not particularly successful in selling directly to integrated operating companies. No policy insisted that arms-length buying be
inserted between the utility and its hardware affiliate,
and indeed the integrated affiliate assumed the role
as purchasing agent for its member telephone carriers.
Little. surprise then that the percentage of the market
penetrated by independent firms has tended to remain
almost constant for some forty years.
Having said this it must be noted that the carriers
insisted that the quality, price and delivery time of
equipment from their in-house suppliers was clearly
superior to alternative sources of supply. It was as if
a competitive market was, by definition less, efficient
in allocating goods and services. The private judgment
of management was never put to an objective test.
Indeed, the carriers resisted formal buying procedures
as unduly cumbersome and unwieldy.9 That resistance
has tended to carry the day.
Third, vertical integration skirted the problem of
potential abuse inherent in investment rate-base padding. Utilities, for example, operate on a cost plus
basis, i.e., they are entitled to earn a reasonable return
on their depreciated capital-a derivation of profits
that stands as the antithesis of the role of profits under
competition. Vertical integration compounded utility
profit making by providing an incentive to transplant
cost plus pricing to the equipment market. Certainly,
the penalty for engaging in utility pricing was difficult
to identify much less discipline. The affiliate occupied
the best of all possible worlds.
In all fairness one must note the institutional con_.straint erected to prevent corporate inefficiency on the
equipment side. The argument ran that the regulatory
271
agency monitored the investment decision of the
carrier. By scrutinizing the pricing practices of the
integrated affiliate indirect regulation prevented exorbitant costs on the supply side from entering the
utility rate base and passed forward to the subscriber.
Indirect regulation allegedly protected both the public
and the utility.
As an abstract matter, indirect regulation held an
element of appeal. Translating that theory into practice was obviously another matter. On the federal
level, the FCC has never found an occasion to disallow
prices billed by Western Electric to AT&T.lO Yet, 65
percent of AT&T's rate base consists of equipment
purchased in-house and absent armslength bargaining. l1
Finally, vertical integration placed the independent
equipment supplier in an awkward if not untenable
position. As noted, the independent firm could secure
equipment subcontracts from its integrated counter-·
part. The dollar value of those subcontracts was not
unimportant. The problem was that the non-integrated
supplier was still dependent upon its potential competitor-a competitor who exercised the discretion
to make or buy. Little wonder then, that the viability
of independent equipment suppliers was controlled
and circumscribed by the tariffs, structure, and procurement practices of telephone utilities. Patently,
no market existed for the outside firms; and without
a market, the base for technical research and development, much less the incentive for product innovation,
was effectively constrained, not to say anesthetized.
Access to the telecommunication equipment was, in
short, limited to suppliers holding a captive market.
The government asked the monopoly firm to judge
itself; and after dispassion3lte inquiry the firm equated
the public interest with preservation of its monopoly
position.
MARKET CHANGES AND PUBLIC POLICY
]JI[ arket
changes
All this has been common knowledge for decades.
Whatever the pressures for reassessment and change,
those pressures were sporadic, ad hoc and often in-·
consistent. Today, however, the telecommunications
industry is experiencing a set of pressures that marks
a point of departure from the triad of policies described
above. In a word, the pace of technology is challenging
the status quo. More specifically, new customized
services tend to be differentiated from services rendered by the common carriers. Time sharing and remote computer based services, for example, provide
and impetus for a host of specialized information ser-
272
Fall Joint Computer Conference, 1970
vices. The rise of facsimile and hybrid EDP/ communication services is equally significant as a trend toward
specialization and sub-market development. Subscribers themselves, driven by the imperatives of
digital technology, seek flexibility and diversity in
their communication facilities. Segmentation and
specialization is gaining momentum.
At the same time, the telecommunication hardware
market is experiencing a proliferation of new products
that pose as substitutes to carrier provided equipment.
In the terminal market, for example, modems, multiplexors, concentrators, teleprinters, CRT display units
are almost a daily occurrence~ Indeed, the computer
itself now functions as a remote outstation terminal;
and many go so far as to assert that the TV set holds
the potential as the ultimate terminal in the home and
the school.
The carriers, of course, have not stood idly by. In
the terminal market, touch-tone hand sets, picturephones and new teletypewriters signal an intent to
participate in remote access input output devices as
well. But the point remains-carrier hardware no longer
stands alone. The proliferation of competitive substitutes and the potential rise of competitive firms is
now a process rather than an event. '
The same technological phenomena is occurring in
the transmission and switching area as well. Cable TV
provides a broad link directly to the home, the school,
or the business firm. Satellite transmission poses as a
substitute for toll trunking facilities and the FCC has
recently licensed MCI as a new customized microwave
carrier. Furthermore, carrier switching technology is
challenged by hardware manufactured and supplied
by firms in the computer industry.
All of this suggests that carrier affiliates no longer
possess the sole expertise in the fundamental components that make up telecommunication network
and services. It is perhaps inevitable then, that the
growing tension between the existing and the possible
has surfaced as questions of public policy. These
questions turn once again on matters of tariff, procurement and integration.
Public policy decisions
Tariffs
Undoubtedly, the FCC's 1968 Carterphone Decision
marks one significant change in the telecommunication
equipment industry.12 Here the Commission held that
users could attach equipment to the toll telephone
network. Indeed, the Commission insisted that carriers establish measures to insure that customer-owned
equipment not interfere with the quality and integrity
of the switched network. Subsequently, the Commission entrusted the National Academy of Science to
evaluate the status of the network control signalling
device. Although somewhat cautious, the Academy
has suggested that certification of equipment may
pose as one feasible alternative to noncarrier equipment. 13
The implications of Carterphone bear repetition.
For one thing the decision broadens the users option
in terms of equipment selection. The business subscriber no longer must lease from the telephone company, but may buy hardware from other manufacturers as well. For another, an important constraint
has been softened with respect to suppliers of terminals,
data modems and multiplexors as well as PBX or
private branch exchanges. Indeed, some claim that
the decision has established a two billion dollar market
potential for private switching systems.H Ironically,
the carriers themselves, to meet the demand for PBX's,
have turned to independent or nonaffiliated firms supplying such equipment.
Nevertheless, the Carterphone in softening previous
restraints continues to pose an interesting set of questions. For example, what precisely is the reach of
Carterphone? Will the decision be extended to the
residential equipment market? Is the telephone residential market off limits to the independent suppliers
of telecommunications equipment? These questions
are crucial if for no other reason than terminal display
units are already on stream and the carriers themselves are now introducing display phones on a commercial basis. Indeed, the chasm between Carterphone's
reality and promise will bulk large if public policy
decides that the residential subscriber cannot be entrusted with a freedom of choice comparable to the
business subscriber.
Vertical integration
The vertical structure of the carriers has also been
subject to reexamination. A relatively unknown antitrust suit involving ITT and General Telephone system
is a case inpoint. 15 The suit erupted when General
Telephone purchased controlling interest in the Hawaiian Telephone Company-a company that was
formerly. a customer of ITT and other suppliers. ITT
has now filed an antimerger suit on grounds that
General forcloses ITT's equipment market. The ITT
suit represents a frontal assault on General's equipment subsidiaries, for ITT is seeking a ban on all of
General Tel's vertical acquisitions since 19.50. In a
Telecommunication Equipment Market
word, the suit seeks to remove General Telephone
from the equipment manufacturing business.
While the suit is pending, it is obviously difficult
to reach any hard conclusions, but one can speculate
that anything less than total victory for General
Telephone will send reverberations throughout the
telephone industry and the equipment market. Certainly, if General Telephone is required to give up its
manufacturing affiliate, then the premise of the Western Electric-AT &T consent decree will take on renewed interest.
Another development in the equipment market
focuses on Phase II of the FCC's rate investigation
of AT&T .16 This phase is devoted to examing the
Western Electric-AT&T relationship. Presumably, the
Commission will examine Bell's procurement policies
as well as the validity of the utility-supplier relationship. What conclusions the Commission will reach
are speculative at this time. In terms of market entry
for the computer industry, the implications of Phase
II are both real and immediate.
Still another facet of integration is the relationship
of communication to EDP and carrier CATV affiliates.
In the former, the FCC has ruled that with the exception of AT&T, carriers may offer EDP on a commercial
basis via a separate but wholly owned corporation. 17
Nothing apparently prohibits a carrier from offering
an EDP service to another carrier-note the current
experiments in remote meter reading. By contrast,
the FCC has precluded carriers from offering CATV
service in areas where they currently render telephone
service. 18 Both moves, to repeat, hold important
market implications for manufacturers of telecommunication equipment.
ProcureInen t
Finally, equipment procurement has surfaced once
again as a policy issue. Consider Carterphone, domestic
satellites and specialized common carriers as symptomatic of the procurement theme.
The premise supporting Carterphone is that the user
is entitled to free choice in his equipment selection.
Once that principle has been established, and that may
well be debatable, someone is bound to pose an additional question. Should suppliers be permitted to sell
to the Carriers directly rather than through carrierowned supply affiliates? Perhaps that precedent has
already been made. Bell System companies may buy
computer hardware directly from computer suppliers,
thus permitting the computer industry to bypass
Western Electric's traditional procurement assignment. 19 The point may well be asked, does this policy
merit generalizing across the board?
273
Access to the equipment market in the domestic
satellite field poses as a second issue. A White House
memorandum has advised the FCC that the problems
of spatial parking slots and frequency bands do not
bar the number of competitive satellite systenis. 20
And in return, the FCC has reopened its domestic
satellite docket for reevaluation. If the Commission
adopts only segments of the White House memo,
domestic' satellites will presumably raise the issue of
competitive bidding in one segment of the hardware
market. As it stands now, all satellite equipment,
whether secured be Com Sat or the international carriers, must be secured through competitive bids. 21
These rules apply not only to the prime contractor,
but all sub-contracting tiers at a minimum threshold
of $24,000. The equestion persists, if domestic satellites
evolve within the continental U.S., will competitive
bidding procedures attend such an introduction whether
in satellite bird or in earth terminal stations. These
issues will likely gain momentum as the carriers move
into the production of ground station equipment.
Finally, an FCC proposed rule made in the area of
specialized carriers, bears directly on the equipment
market. 22 The docket is traced to the FCC's MCI
decision which authorized a specialized carrier to offer
service between Chicago and St. Louis. 23 Since the
MCI decision, the FCC has received over 1700 applications for microwave sites. In its recent docket, the
Commission has solicited views in proposed rulemaking that would permit free access of any and all
microwave applicants. As the Commission noted,
"Competition in the specialized communications field
would enlarge the equipment market for manufacturers
other than Western Electric. . . .' '24 If this policy becomes implemented and the FCC can prevent the
carriers from engaging in undue price discrimination,
it is clear that the one constraint to the growth of
specialized common carriers will be the output capacity of firms who manufacture such equipment.
CONCLUSION
In sum the premises supporting the tariffs, structure
and practices of the carriers have been exposed to
erosion and subject to revision. That change has in
turn spilled into the policy arena. Firms in the telecommunication equipment industry-and this incJudes
the computer industry-will find it increasingly difficult to avoid the policy issues ofa market whose potential exceeds $5 billion.
One might argue that questions dealing with market entry are in one sense peripheral issues. That is,
public policy should direct its attention to existing
274
Fall Joint Computer Conference, 1970
structures as well as potential entry. In this context
competitive buying practices may well pose as a workable solution to the vertical integration problem. But
that solution is obvjously of short term duration. The
pace of technology is suggesting that something more
fundamental must give. Over the next decade, the
nation's supply of telecommunication equipment must
expand by an order of magnitude and that goal stands
in obvious conflict with monopoly control of telecommunication equipment suppliers.
REFERENCES
1 W H MELODY
I nterservice subsidy: Regulatory standards and applied
economics
Paper presented at a conference sponsored by Institute of
Public Utilities Michigan State University 1969
2 New York Times
July 291970
3 Final Report
President's Task Force on Communications Policy
December 7 1968
4 United States v Western Electric Co
Civil No 17-49 DNJ filed Feb 14 1949
5 Consent Decree US v Western Electric Co
Civil No 17-49 DNJ January 23 1956
6 United States v General Telephone and Electronics Corp
Civil No 64-1912 SD NY file June 19 1964
7 In the US District Court District of Hawaii International
Telephone and Telegraph Corporation v General Telephone
and Electronics Corporation and Hawaiian Telephone
Company Civil No 2754 G T&E's motion under Rule 19
Points and Authorities in Support Thereof April 21 1970
8 Smith v Illinois Bell Telephone
282 US 1930
9 Telephone investigation
Special Investigation Docket No.1, Brief of Bell System
Companies on Commissioner Walker's Proposed Report
on the Telephone Investigation 1938
10 The domestic telecommunications carrier industry
Part I Presidents Task Force on Communications Policy
Clearinghouse pp 184-417 US Department of Commerce
June 1969
11 Moody's public utility manual
Moody's Investors Service Inc New York August 1969
12 Before the FCC in the Matter of Use of the Carterphone
Device in Message Toll Telephone Service FCC No 16942
In the Matter of Thomas F Carter and Carter Electronics
Corporation Dallas Texas Complainants v American
Telegraph and Telephone Company Associated Bell
System Companies Southwestern Bell Telephone Company
and General Telephone of the Southwest FCC Docket No
17073 Decision June 26 1968
13 Report of a technical analysis of common carrier/user
interconnections
National Academy of Sciences Computer Science and
Engineering Board June 10 1970
14 New York Times
July 121970
15 In the US District Court for the District of Hawaii
International Telephone and Telegraph Corp v General
Telephone and Electronics Corp and Hawaiian Telephone
Company Complaint for Injunctive Relief Civil Action
No 2754 October 18 1967 Also Amended Complaint for
Injunctive Relief December 14 1967
16 Before the FCC In the Matter of American Telephone and
Telegraph Company and the Associated Bell System
companies charges for Interstate and Foreign
Communication Service 1966
Stanford Research Institute Policy Issues Presented by the
Interdependence of Computer and Communications Services
Docket No 19979 Contract RD-10056 SRI Project 7379B
Clearinghouse for Federal Scientific and Technical
Information US Department of Commerce February 1969
17 Before the FCC in the Matter of Regulatory and Policy
Problems Presented by the Interdependence of Computer
and Communication Service and Facilities Docket No
16979 Tentative Decision 1970
18 Before the Federal Communications Commission In the
Matter of Applications of Telephone Companies for Section
214 Certificates for Channel Facilities Furnished to
Affiliated Community Antenna Television Systems
Docket No 18509 Final Report and Order January 28 1970
19 A systems approach to technological and economic imperatives
of the telephone network
Staff Paper 5 Part 2 June 1969 PB184-418 President's Task
Force on Communications Policy
20 Memorandum White House to Honorable Sean Burch
Chairman Federal Communications Commission January
231970
21 Before the FCC In the Matter of Amendment of Part 25
of the Commission's Rules and Regulations with Respect
to the Procurement of Apparatus Equipment and Services
Required for the Establishment and Operation of the
Communication Satellite System, and the Satellite
Terminal Stations Docket No 15123 Report and Order
April 3 1964
22 Before the FCC In the Matter of Establishment of Policies
and Procedures for Consideration of Applications to Provide
Specialized Common Carrier Services in the Domestic
Public Point-to-Point Microwave Radio Service and
Proposed Amendments to Parts 2143 and 61 of the
Commission's Rules Notice of Inquiry to Formulate Policy
Notice of Proposed Rulemaking 1 and Order July 1970
(Cited as FCC Inquiry on Competitive Access)
23 Federal Communications Commission In re Application of
Microwave Communications Inc for Construction Permits
to Establish New Facilities in the Domestic Public Point
to Point Microwave Radio Service at Chicago Illinois
St Louis Missouri and Intermediate Points Docket No
16509 Decision August 14 1969
24 FCC Inquiry on Competitive Access op cit July 1970 p 22
Digital frequency modulation as a technique for improving
telemetry sampling bandwidth utilization
by G. E. HEYLIGER
Martin Marietta Corporation
Denver, Colorado
INTRODUCTION
strictly band-limited signal are required for complete
recovery of that signal. Nevertheless, 5 to 10 samples
per cycle are widely employed. There are reasons,
practical and otherwise, for the resulting bandwidth
extravagance:
A hybrid of Time Division Multiplexing (TDM) and
Frequency Division Multiplexing (FDM), both wellestablished in theory and practice is described herein.
While related to TDM and FDM, the particular combinations of techniques and implementations are novel
and, indeed, provide a third alternative for signal
multiplexing applications. The essence of the idea is
to perform all band translation and filtering via numerical or digital techniques.
Signal multiplexing techniques are widely employed
as a means of approaching the established theoretical
limitations on communication channel capacity. In
general, multiplexing techniques allow several signals
to be combined in a way which takes better advantage
of the channel bandwidth. FDM systems accomplish
this by shifting the input signal basebands by means
of modulation techniques, and summing the results.
Judicious choice of modulation frequencies allows nonoverlapping shifted signal bands, and permits full
use of the channel bandwidth. Refinements such
as "guard bands" between adjacent signal bands and
the use of single sidebands can further affect the system
design, but, in general, the arithmetic sum of the
individual signal bandwidths must be somewhat less
than haH the composite channel bandwidth.
TD1VI systems achieve full utilization of channel
bandwidth in quite a different way. Several signals
are periodically sampled, and these samples are interleaved so that the individual signal must be sampled
at least twice per cycle for the highest signal frequency
present in accordance with Nyquist's sampling theorem.
In this case, also, the number of signals that can be
combined depends upon the sum of individual signal
bandwidths and the bandwidth of the channel itself.
The sampling theorem states that only two samples
per cycle of the highest frequency component of a
1. Many times it is difficult, if not impossible, to
place a specific upper limit on "significant'.
frequency components. Safe estimates are made.
2. Interpretation of real-time or quick-look plots
is simpler and more satisfying if more samples
per cycle are available.
3. Aliasing or folding of noise is more severe for
relatively low sampling rates and inadequate
prefiltering.
This paper acknowledges the practice of oversampling but avoids the difficulties previously described. Full use is made of the sampling bandwidth
by packing several signals into that bandwitdh utilizing
a form of FDM. The novelty lies in the use of FDM
and the way modulation is achieved for periodically
sampled signals.
SYSTEM DESCRIPTION
Before describing the system, it is useful to briefly
consider some theoretical background. The following
discussion should clarify the basic ideas. Consider a
source signal with the spectrum shown in Figure l(a).
It is well known that sampling signals at a frequency
is = l/T where T is the time between samples, results
in a periodic replication of the original spectrum as
shown in Figure l(b). Modulation of the original signal
by frequency /0 produces the usual sum and difference
frequencies, and sampling then results in the replicated
pattern shown in Figure 1 (c).
275
276
Fall Joint Computer Conference, 1970
I
I
I
. -3 21.
-I •
-I 21.
rh
S ; " e r e d by Low-Pass
0
I
I
I
I
1.21.
I.
321.
~ C'\OC'\ ~ do~ A C'\OC'\
(a) Original
:. ! I,
r71
-I.
-T2~-~
Fllt.rin~
·I s
I
1 2 I.
I
0
1 2 I.
Is
I
.,
3 2 I.
I
I
r71
1.21.
I.
(a) Combined Spectra of Three Oversamp1ed and Modulated Sources
1
1
(b) Sampled
1
, C"'\ f:,. C'\ c;J ~ f:,. ~ Q C'\ I)
-t,
3l1...
-12f~
I
~
0
's
12f"
1"'""Jr; •
32f.
(b) Demodulated by 1/2 f
(c) Sampled and Modulated by fO
I
3!f,
Figure 1-Spectral effects of sampling and modulating
;
t
I
I
s
rro G""\ rro C" fA) I~rro
C\ rro C"' fA) ~
I
-,
..
-12/.
I
0
12/
I
321
I S S
•
(c) Demodulated by 1/4 fs
Now consider three source signals with the spectra
shown in Figure 2(a), all with roughly the same bandwidth. Modulating the second and third signals with
the frequencies f8/2 and fs/4, respectively, results in
the shifted spectra shown in Figure 2(b). Summing
yields the composite spectrum shown in Figure 2(c).
This composite signal now makes full use of the sampling bandwidth.
Figure 3 shows the inverse process of obtaining the
original spectra. Demodulating by the same frequencies
used for modulation successively brings each signal
band to the origin where low pass filtering eliminates
all but the original signal.
Since few signals are strictly band-limited, it is
evident that crosstalk noise will appear in the received
signal. This noise can be controlled by the degree of
pre- and postfiltering. For certain relatively inactive
signals, the crosstalk may be no penalty at all. In
general, however, crosstalk presents the same problems
here as with any FDM system. The important point
to be made is that tracking of the modi demod oscillators is not relevant since these operations are obtained
directly by operating on successive samples, i.e., there
are no local oscillators per se.
In general, modulation is accomplished by multiplying the signal source by a single sinusoidal frequency or carrier. Sampled signals are modulated in
t.
Figure 3-Prefiltered separation of combined signals
the same way, but the modulating frequency multiplier is required only at successive sample times.
Modulation (i.e., multiplication) by integer fractions
of the sampling frequency is particularly simple if
appropriate sample times are chosen. For example,
certain modulation frequency amplitudes are quite
easily obtained as shown in Table I. The phase shift
of 1'(/4 for 1/4 fs was chosen to avoid multiplication
by zero yet retain natural symmetry. All the modulation factors may be easily obtained by modifying the
sign of the signal magnitude and/or multiplying by
a factor of 1/2. Furthermore, the majority of interesting cases are handled by these modulation frequencies, packing two, three, or four FDM channels within
the sampling bandwidth. This degree of packing nicely
accommodates practical oversampling systems encountered in practice. For particular applications, it
may be useful to employ arbitrary modulation frequencies and the corresponding sequence of numerical
multipliers (nonrepeating or repeating).
A hybrid form of implementation is shown in Figures
4 and 5. Figure 4 is the modulator, and Figure 5 is
the demodulator. Not explicitly shown, but implied,
Table I
Modulation
Frequency
t
(a) Three Oversampled Source Signals
1
4
C"'\
fs
f
s
Modulation Factor
= 0,1,2,...
General Expr.ession. k
(t fs 21fT) =
fs )
cos (k;;- 21fT =
cos
cos k1f
l, -1, ...
1f
cos k2
0, I, 0, -1, ...
1
(No t e Con stan l
Amplitude)
(b) Original Signals Modulated by O. 1/2 fs' and 1/4 fs' Respectively
I' C"'\ 0
-I 2 I.
0
1
f
1
f
b
C'""\
t.
1 2 I.
(c) Combined Spectra (Reduced to Sampling
Bandwidth)
Figure 2-Combinations of oversampled signals
Periodic Sequence
3
s
5
cos
f21fT
)
(k 6'
= cos k3
cos
[s )
(k 321fT
=
5
-
1,
t, -t,
1,
-t, -to ...
'If
2
cos k3 1f
TABLE I-Modulation Factor
-1,
-to t.···
Digital Frequency Modulation
5,
-- - - - - - - -- - - - -- - - -- - -- - - - - - -- - - - -,
I
I
t
1
:
I
I
To Conventional
Time Division
Multiplexing
System
Notes:
1)
1/2
~f'
. ,-1--1-....1...-,
IS
L ________________________________ ~
fa' is a periodic pulse
stream. delayed with
respect to f s. the
sampling pulse sequence.
(See text..)
Figure 4-Sampled FD M modulator
is the use of the combined signal output as a single
sampled source for conventional TDM systems. The
system diagram assumes the case of four signals of
roughly equal bandwidth to be combined into a single
signal. Subfunctions such as sampling, counting, digital
decoding trees, and operational amplifiers can be implemented in a variety of ways utilizing conventional,
commercially available functional blocks or components. Details of the subfunction implementations
themselves are incidental to the concept but important
to the particular application. Referring to Figure 4,
the multiplexer modulator works as follows:
Four independent signals (Sl, S2, S3, and S4) are
accepted as inputs. One, shown as S1, goes directly
to the summing amplifier, A. Each of the other signals
is switched periodically under control of the approprlate binary counter which is synchronized and driven
by the sampling frequency pulses. As shown, S2 is
alternately switched from the first to the second of a
two-stage cascade of operational amplifiers. The effect
of this chain is to alternately multipiy S2 by the factors
plus one and minus one, i.e., the modulation factor
cos k7l"; = 0, 1, 2, ... in accordance with Table I and
considering the modulation signal valid at the sample
times only. Similarly, S3 is multiplied by the periodic
sequence (1, -72, -72) again in accordance with the
third line of Table I. The effect, considered at sample
times only, is to modulate Sa by 1/3 fs. Fip.ally, S4 is
modulated by 1/6 F s , by periodically switching this
signal to one of six inputs of the operational amplifier
chain with the gains (1, 72, -72, -1, -72, 72) in
accordance with line four of Table I.
All four outputs are summed by the operational
amplifier A, and the summed signal sampled at the
277
output of A at the sampling frequency, fs. It should be
noted that the switching counters can be changed at
any time after a sample is taken from the output of
A; therefore, the design of the system provides that
the pulse driving the counters is delayed slightly more
than the aperture time of the sampled output. This
mechanization provides ample time for switching operations prior to the subsequent sampling. The sampled
output signal, St*, can be used as an input to a conventional TDM system.
The demodulator shown in Figure 5 is very similar
to the modulator. In fact, within the dotted lines it is
identical. Here, the appropriate output from a conventional TDM system, St*, is used as input to all
four counter-controlled switches. A sample and hold
operation is employed at the input in order to drastically
reduce the time response requirements of the operational amplifiers.
Again, sequentially switching the input effectively
demodulates St by the frequencies 1/6 fs, 1/3 fs, and
1/2 fs. Since this modulation is effective only at the
sampling instants, a sample and hold circuit is required
at each output. The low-pass filter eliminates components of all but the demodulated signal. Note that
for the demodulator, the signals f't should precede
fs in phase by the aperture (or pulse width) of St*,
to allow a maximum time for change in St* to be accommodated by the amplifier and switching chain.
Since fs is derived from St* and is a periodic signal,
any desired relative phasing is readily achieved.
SYSTEM ADVANTAGES AND CAPABILITIES
Several useful and interesting features are inherent
in the system:
1. Numerical Modulation of Sampled SignalsBecause the modulation signal is required only
.---------------------.- --- --------1
'T"
"
"
'3
"
1/2
•"{"ehron'"}
T
c.in.tor
L __ - - - - - - - - - - - - - - -
- -------- ---- --
f.
Figure 5-Sampled FDM demodulator
278
Fall Joint Computer Conference, 1970
2.
3.
4.
5.
at the sampling instants, a periodic sequence
of numerical multipliers substitutes for the
local oscillator of conventional frequency modulation systems. Conventional oscillator accuracy
and stability problems do not arise, and very
low frequency modulation is readily achieved.
Coincident Sampling of Several Signals-Conventional TDM systems may combine signals
sampled at the same rate, but at different instants of time. This approach provides for
combining signals sampled at the same rate
and same times. Full use of conventional TDM
techniques can be employed on the combined
signal.
Full Utilization of Sampling BandwidthThe sampling rate chosen defines the unaliased
bandwidth in a sampled data system. Here, a
way of combining several independent signals
is employed so that the total sampling bandwidth can be utilized for transmission of information.
Signal Independent Choice of Sampling RateAs a corollary to 3, this system permits, even
promotes, oversampling of individual signals.
Oversampling is attractive and widely practiced
as previously noted. The system described here
avoids the usual oversampling penalties by
packing several independent signals within
the sampling bandwidth.
Noise Aliasing Avoidance-Some source signals
must be heavily prefiltered or oversampled
in order to avoid the noise signal folding effects
of sampled data systems. Again, oversampling
can be employed without the usual penalties.
It should be noted that wideband noise will
of course result in crosstalk among the combined
channels.
In summary, the system described gives a new dimension in the design of signal multiplexed systems.
Combination of these techniques with the conventional
TDM and FDM techniques allows the designer to
tailor a sampled data system to the peculiarities of a
specific set of source signals, while making full use of
the available sampled bandwidth.
following system functions can be identified:
1. Sampling, timing, and switching;
2. Analog/digital (A/D) conversion;
3. Sample modulation/demodulation.
The modulator/transmitter also requires an adder
for combining the signals, while the demodulator/
receiver requires a suitable lowpass filter for each
output. Conversion to a digital representation of the
signals can be performed at most any point in the
system. Following conversion, the subsequent functions are performed via conventional digital arithmetic
and logic operations.
Exclusively digital implementation
As an extreme example, consider an implementation
that provides A/D conversion at the source (modulator/transmitter input).
Modulation is accomplished by arithmetic multiplication of the source sequence values by the desired
modulation sequence, cos kO o where 0 = sT. Note
that in this case, the modulation sequence need not
be a periodic sequence if a means is provided for generating the values cos k 00 for all integers, k.
Independent signals are combined after modulation
simply by arithmetic addition of corresponding modulated sequence values. The summed sequence is the
output. The combined PCM samples are then handled
as with a conventional TDM system.
At the demodulator/receiver, the input is the digital
sampled sequence as derived from a conventional
PCMsystem.
Demodulation is performed as before; arithmetic
multiplication of the input sequence by the appropriate
sequence of values, cos k 00 •
Each resulting output must be filtered to eliminate
the other signal components. Filtering can be ac··
complished numerically using either recursive or
nonrecursive techniques.
The outputs then are available as separate signals
corresponding to those first transmitted. The digital
output sequence may be used directly for listing, further processing, or as an input to an incremental
plotter. Alternatively, D/ A, conversion and hold
operations convert the signal to its analog equivalent.
ALTERNATIVE IMPLEMENTATIONS
Mixed analog/digital implementations
The hybrid system described herein uses pulse
amplitude modulation (PAM). However, pulse code
modulation (PCM) can be employed as well, in one of
several attractive alternative implementations. The
Evidently, a number of obvious combinations of
PAM and PCM are possible. Thus, operational amplifier (op-amp) modulation can be used in combination
Digital Frequency Modulation
with a time-shared AID converter and arithmetic
summation with the result handled as a conventional
PCM signal. Similarly, at the receiver, DI A conversion
may take place at the output of the PCM arithmetic
modulator, and the result passed through a conventionallow-pass analog filter for signal recovery.
A nalog system simplifications
Figure 4 presents the system in a way that aids
description and understanding. Good design practice
would permit combination of the modulation and
summing functions in a single op-amp stage. Similarly,
various combinations of cascades 2- and 3-way switches
might be advantageous instead of the single stage
6-way switch shown in Figure 4.
Modulation sequence considerations
The op-amp modulator implementation requires
that the modulation sequence, cos k eo, be a repeating
or periodic sequence. From a practical point of view,
only a small number of modulation values should be
employed, since each requires additional switching and
input to the op-amp. While the only theoretical limitation on the number of values is that eo be some
rational fraction of 211"', the simple ratios of the examples shown should prove most useful in practice.
Arithmetic implementation of the modulation and
demodulation function imposes no constraint on the
number of distinct modulation values, cos k eo. Successive values may be generated arithmetically using
some equivalent of the following algorithm:
sinkeo = cos(k - l)e o sinOo
+
sin(k - 1)0 0 cose o
coske o = cos(k - 1)00 coseo - sin(k - l)e o sine o
Only the initial values cos 00 and sin eo are required to
start. If eo is some rational fraction of 211"', the sequence
will be repeating; otherwise, not. In this case any desired modulation frequency (wo) may be realized.
279
Bandwidth packing variations
While roughly equal bandwidths were assumed for
the combined signals of the system described, the
fundamental constraint is that the sum of, signal
bandwidths plus guard bands must be less than the
sampling frequency. As usual with FDM systems,
both upper and lower sidebands for each signal must
be included in this consideration. Choice of a suitable
modulation frequency then depends upon the placement of each signal band within the sampling bandwidth. Clearly, many variations of center frequencies
and bandwidth are feasible and useful.
Variations in digital system
A general purpose digital computer can perform all
operations required for modulating, summing, demodulating, and filtering. Where such a computer is already
employed in the data system for switching, comparison,
calibration, and control, the additional functions
described here become particularly attractive. Standard programming practices can be used to perform
the essential functions described here.
Alternatively, for the system example the arithmetjc operations required are quite simple. Multiplications of Y2 and -1 are readily realized by right
shift and sign change operations, respectively. A special
purpose digital computer with few storage registers
and capability for "right shift," "add," "sign change,"
and conventional register transfers, will provide the
required functions.
CONCLUSION
The digital frequency modulation technique described
herein permits combination of several signals into a
single signal having a sampled bandwidth equal to
the sum of the original signal bandwidths. Utilization
of this technique to reduce the penalties of oversampled telemetry channels appears particularly attractive.
THE ALOHA SYSTEM-Another alternative for computer
communications*
by NORMAN ABRAMSON
University of Hawaii
Honolulu, Hawaii
WIRE COMMUNICATIONS AND RADIO
COMMUNICATIONS FOR COMPUTERS
INTRODUCTION
In September 1968 the Uhiversity of Hawaii began
work on a research program to investigate the use of
radio communications for computer-computer and
console-computer links. In this report we describe a
remote-access computer system-THE ALOHA SySTEM-under development as part of that research
program! and discuss some advantages of radio communications over conventional wire communications
for interactive users of a large computer system. Although THE ALOHA SYSTEM research program is
composed of a large number of research projects, in
this report we shall be concerned primarily with a
novel form of random-access radio communications
developed for use within THE ALOHA SYSTEM.
The University of Hawaii is composed of a main
campus in Manoa Valley near Honolulu, a four year
college in Hilo, Hawaii and five two year community
colleges on the islands of Oahu, Kauai, Maui and
Hawaii. In addition, the University operates a number
of research institutes with operating units distributed
throughout the state within a radius of 200 miles from
Honolulu. The computing center on the main campus
operates an IBM 360/65 with a 750 K byte core memory
and several of the other University units operate smaller
machines. A time-sharing system UHTSS/2, written
in XPL and developed as a joint project of the University Computer Center and THE ALOHA SYSTEM
under the direction of W. W. Peterson is now operating.
THE ALOHA SYSTEM plans to link interactive computer users and remote-access input-output devices
away from the main campus to the central computer
via UHF radio communication channels.
At the present time conventional methods of remote
access to a large information processing system are
limited to wire communications-either leased lines or
dial-up telephone connections. In some situations these
alternatives provide adequate capabilities for the designer of a computer-communication system. In other
situations however the limitations imposed by wire
communications restrict the usefulness of remote access
computing. 2 The goal of THE ALOHA SYSTEM is to
provide another alternative for the system designer
and to determine those situations where radio communications are preferable to conventional wire
communications.
The reasons for widespread use of wire communications in present day computer-communication systems
are not hard to see. Where dial-up telephones and leased
lines are available they can provide inexpensive and
moderately reliable communications using an existing
and well developed technology.3,4 For short distances
the expense of wire communications for most applications is not great.
Nevertheless there are a number of characteristics
of wire communications which can serve as drawbacks
in the transmission of binary data. The connect time
for dial-up lines may be too long for some applications;
data rates on such lines are fixed and limited. Leased
lines may sometimes be obtained at a variety of data
rates, but at a premium cost. For communication links
over large distances (say 100 miles) the cost of communication for an interactive user on an alphanumeric
console can easily exceed the cost of computation. 5
Finally we note that in many parts of the world a
reliable high quality wire communication network is
not available and the use of radio communications for
data transmission is the only alternative.
There are of course some fundamental differences
* THE ALOHA SYSTEM is supported by the Office of Aerospace Research (SRMA) under Contract Number F44620-69-C0030, a Project THEMIS award.
281
282
Fall Joint Computer Conference, 1970
between the data transmitted in an interactive timeshared computer system and the voice signals for which
the telephone system is designed. 6 First among these
differences is the burst nature of the communication
from a user console to the computer and back. The
typical 110 baud console may be used at an average
data rate of from 1 to 10 baud over a dial-up or leased
line capable of transmitting at a rate of from 2400 to
9600 baud. Data transmitted in a time-shared computer system comes in a sequence of bursts with extremely long periods of silence between the bursts. If
several interactive consoles can be placed in close
proximity to each other, multiplexing and data concentration may alleviate this difficulty to some extent.
When efficient data concentration is not feasible however the user of an alphanumeric console connected
by a leased line may find his major costs arising from
communication rather than computation, while the
communication system used is operated at less than
1 percent of its capacity.
Another fundamental difference between the requirements of data communications for time-shared systems
and voice communications is the asymmetric nature
of the communications required for the user of interactive alphanumeric consoles. Statistical analyses of
existing systems indicate that the average amount of
data transmitted from the central system to the user
may be as much as an order of magnitude greater than
the amount transmitted from the user to the central
system. 6 For wire communications it is usua]]y not
possible to arrange for different capacity channels in
the two directions so that this asymmetry is a further
factor in the inefficient use of the wire communication
channel.
The reliability requirements of data communications
constitute another difference between data communication for computers and voice communication. In addition to errors in binary data caused by r~ndom and
burst noise, the dial-up channel can produce connection
problems-e.g., busy signals, wrong numbers and disconnects. Meaningful statistics on both of these problems are difficult to obtain and vary from location to
location, but there is little doubt that in many locations the reliability of wire communications is well below that of the remainder of the computer-communication system. Furthermore, ~ince wire communications
are usually obtained from the common carriers this
portion of the overall computer-communication system
is the only portion not under direct control of the system
designer.
THE ALOHA SYSTEM
The central computer of THE ALOHA SYSTEM
(an IBM 360/65) is linked to the radio communication
~
~
TRANSMIT
CENTRAL
DATA
COMPUTER
IBM
360165
~
~
DATA
MODEM
Figure I-THE ALOHA SYSTEM
channel via a small interface computer (Figure 1).
Much of the design of this multiplexor is based on the
design of the Interface Message Processors (IMP's)
used in the ARPA computer net.4, 7 The result is a
Hawaiian version of the IMP (taking into account the
use of radio communications and other differences)
which has been dubbed the MENEHUNE (a legendary
Hawaiian elf). The HP 2115A computer has been
selected for use as the MENEHUNE. It has a 16-bit
word size, a cycle time of 2 microseconds and an 8Kword core storage capacity. Although THE ALOHA
SYSTEM will also be linked to remote-access inputoutput devices and small satellite computers through
the MENEHUNE, in· this paper we shall be concerned
with a random access method of multiplexing a large
number of low data rate consoles into the MENEHUNE
through a single radio communication channel.
THE ALOHA SYSTEM has been assigned two 100
KHZ channels at 407.350 MHZ and 413.475 MHZ.
One of these channels has been assigned for data from
the MENEHUNE to the remote consoles and the
other for data from the consoles to the MENEHUNE.
Each of these channels will operate at a rate of 24,000
baud. The communication channel from the MENEHUNE to the consoles provides no problems. Since
the transmitter can be controlled and buffering performed by the MENEHUNE at the Computer Center,
messages from the different consoles can be ordered in a
queue according to any given priority scheme and
transmitted sequentially.
Messages from the remote consoles to the MENEHUNE however are not capable of being multiplexed
in such a direct manner. If standard orthogonal multiplexing techniques (such as frequency or time multiplexing) are employed we must divide the channel
from the consoles to the MENEHUNE into a large
number of low speed channels and assign one to each
console, whether it is active or not. Because of the fact
that at any given time only a fraction of the total
number of consoles in the system will be active and
because of the burst nature of the data from the con-
THE ALOHA SYSTEM
soles such a scheme will lead to the same sort of inefficiencies found in a wire communication system.
This problem may be partly alleviated by a system of
central control and channel assignment (such as in a
telephone switching net) or by a variety of polling
techniques. Any of these methods will tend to make
the communication equipment at the consoles more
complex and will not solve the most important problem
of the communication inefficiency caused by the burst
nature of the data from an active console. Since we
expect to have many remote consoles it is important
to minimize the complexity of the communication
equipment at each console. In the next section we
describe a method of random access communications
which allows each console in THE ALOHA SYSTEM
to use a common high speed data channel without the
necessity of central control or synchronization.
Information to and from the MENEHUNE in THE
ALOHA SYSTEM is transmitted in the form of
"packets," where each packet corresponds to a single
message in the system. 8 Packets will have a fixed length
of 80 8-bit characters plus 32 identification and
control bits and 32 parity bits; thus each packet will
consist of 704 bits and will last for 29 milliseconds at a
data rate of 24,000 baud.
The parity bits in each packet will be used for a
cyclic error detecting code. 9 Thus if we assume all
error patterns are equally likely the probability that a
given error pattern will not be detected by the code is10
2-32 =10- 9•
Since error detection is a trivial operation to implement, 10
the use of such a code is consistent with the require- '
unr I
rtlTIt-
In n
n
~
n
·
...,. 2
I
o
fA 0
0
I
••
user "
sum
·:
o
Om
1000
orint It
~
·:•
~
Interference
repetitions ~
time
--+
Figure 2-ALOHA communication multiplexing
283
ment for simple' communication equipment at the consoles. The possibility of using the same code for error
correction at the MENEHUNE will be considered for a
later version of THE ALOHA SYSTEM.
The random access method employed by THE
ALOHA SYSTEM is based on the use of this error
detecting code. Each user at a console transmits packets
to the MENEHUNE over the same high data rate
channel in a completely unsynchronized (from one
user to another) manner. If and only if a packet is received without error it is acknowledged by the MENEHUNE. After transmitting a packet the transmitting
console waits a given amount of time for an acknowledgment; if none is received the packet is retransmitted.
This process is repeated until a successful transmission
and acknowledgment occurs or until the process is
terminated by the user's console.
A transmitted packet can be received incorrectly
because of two different types of errors; (1) random
noise errors and (2) errors caused by interference with
a packet transmitted by another console. The first
type of error is not expected to be a serious problem.
The second type of error, that caused by interference,
will be of importance only when a large number of
users are trying to use the channel at the same time.
Interference errors will ,limit the number of users and
the amount of data which can be transmitted over this
random access channel.
In Figure 2 we indicate a sequence of packets as
transmitted by k active consoles in the ALOHA random
access communication system.
We define T as the duration of a packet. In THE
ALOHA SYSTEM T will be equal to about 34 milliseconds; of this total 29 milliseconds will be needed for
transmission of the 704 bits and the remainder for receiver synchronization. Note the overlap of two packets
from different consoles in Figure 2. For analysis purposes we make the pessimistic assumption that when
an overlap occurs neither packet is received without
error and both packets are therefore retransmitted. *
Clearly as the number of active consoles increases the
number of interferences and hence the number of retransmissions increases until the channel clogs up with
repeated packets.l1 In the next section we compute the
average number of active consoles which may be supported by the transmission scheme described above.
Note how the random access communication scheme
of THE ALOHA SYSTEM takes advantage of the
nature of the radio communication channels as opposed
to wire communications. Using 'the radio channel as
we have described each user may access the same
* In order that the retransmitted packets not continue to interfere with each other we must make sure the retransmission delays
in the two consoles are different.
284
Fall Joint Computer Conference, 1970
channel even though the users are geographically dispersed. The random access communication method
used in THE ALOHA SYSTEM may thus be thought
of as a form of data concentration for use with geographically scattered users.
RANDOM ACCESS RADIO COMMUNICATIONS
We may define a random point process for each of
the k active users by focusing our attention on the
starting times of the packets sent by each user. We
shall find it useful to make a distinction between those
packets transmitting a given message from a console
for the first time and those packets transmitted as
repetitions of a message. We shall refer to packets of
the first type as message packets and to the second type
as repetitions. Let X be the average rate of occurrence
of message packets from a single active user and assume
this rate is identical from user to user. Then the random
point process consisting of the starting times of message
packets from all the active users has an average rate
of occurrence of
r=kX
where r is the average number of message packets per
unit time from the k active users. Let T be the duration
of each packet. Then if we were able to pack the messages into the available channel space perfectly with
absolutely no space between messages we would have
rT=1.
Accordingly we refer to rT as the channel utilization.
Note that the channel utilization is proportional to k,
the number of active users. Our objective in this section
is to determine the maximum value of the channel
utilization, and thus the maximum value of k, which
this random access data communication channel can
support.
Define R as the average number of message packets
plus retransmissions per unit time from the k active
users. Then if there are any retransmissions we must
have R>r. We define RT as the channel traffic since this
quantity represents the average number of message
packets plus retransmissions per uni ttime multiplied
by the duration of each packet or retransmission. In
this section we shall calculate RT as a function of the
channel utilization, rT.
Now assume the interarrival times of the point
process defined by the start times of all the message
packets plus retransmissions are independent and exponential. This assumption, of course, is only an approximation to the true arrival time distribution. Indeed,
because of the retransmissions, it is strictly speaking
not even mathematically consistent. If the retransmission delay is large compared to T, however, and the
number of retransmissions is not too large this assumption will be reasonably close to the true distribution.
Moreover, computer simulations of this channel indicate that the final results are not sensitive to this
distribution. Under the exponential assumption the
probability that there will be no events (starts of message packets or retransmissions) in a time interval T
is exp( -RT).
Using this assumption we can calculate the probability that a given message packet or retransmission
will need to be retransmitted because of interference
with another message packet or retransmission. The
first packet will overlap with another packet if there
exists at least one other start point T or less seconds
before or T or less seconds after the start of the given
packet. Hence the probability that a given message
packet or retransmission will be repeated is
[1- exp( -2RT)].
(1)
Finally we use (1) to relate R, the average number
of message packets plus retransmissions per unit time
to r, the average number of message packets per unit
time. Using (1) the average number of retransmissions
per unit time is given by
R[1- exp(-2RT)]
so that we have
R=r+R[1- exp(-2RT)]
or
(2)
Equation (2) is the relationship we seek between the
channel utilization rT and the channel traffic RT. In
Figure 3 we plot RT versus rT.
chama'
trafflc
RT
.50
--------------- ----------- --------------
.40
.30
.20
.10
.10
~'5
.186
channal utilization r T
Figure 3-Channel utilization vs channel traffic
THE ALOHA SYSTEM
Note from Figure 3 that the channel utilization
reaches a maximum value of 1/2e=0.186. For this
value of rr the channel traffic is equal to 0.5. The
traffic on the channel becomes unstable at rr = 1/2e
and the average number of retransmissions becomes
unbounded. Thus we may speak of this value of the
channel utilization as the capacity of this random access
data channel. Because of the random access feature
the channel capacity is reduced to roughly one sixth
of its value if we were able to fill the channel with a
continuous stream of uninterrupted data.
For THE ALOHA SYSTEM we may use this result
to calculate the maximum number of interactive users
the system can support.
Setting
. we solve for the maximum number of active users
A conservative estimate of A would be 1/60 (seconds)-l,
corresponding to each active user sending a message
packet at an average rate of one every 60 seconds.
With r equal to 34 milliseconds we get
kmax = 324.
(3)
Note that this value includes only the number of
active users who can use the communication channel
simultaneously. In contrast to usual frequency or time
multiplexing methods while a user is not active he consumes no channel capacity so that the total number of
users of the system can be considerably greater than
indicated by (3).
The analysis of the operation ~f THE ALOHA
SYSTEM random access scheme provided above has
been checked by two separate simulations of the system. 12,13 Agreement with the analysis is excellent for
values of the channel utilization less than 0.15. For
larger values the system tends to become unstable as
one would expect from Figure 3.
285
REFERENCES
1 N ABRAMSON et al
1969 annual report THE AWHA SYSTEM
University of Hawaii Honolulu Hawaii January 1970
2 M M GOLD LL SELWYN
Real time computer communications and the public interest
Proceedings of the Fall Joint Computer Conference
pp 1473-1478 AFIPS Press 1968
3 R M FANO
The MAC system: The computer utility approach
IEEE Spectrum Vol 2 No 1 January 1965
4 L G ROBERTS
Multiple computer networks and computer communication
ARPA report Washington DC June 1967
5 J G KEMENY T E KURTZ
Dartmouth time-sharing
Science Vol 162 No 3850 p 223 October 1968
6 P E JACKSON C D STUBBS
A study of multiaccess computer communications
Proceedings of the Spring Joint Computer Conference
pp 491-504 AFIPS Press 1969
7 Initial design for interface message processors for the ARPA
computer network
Report No 1763 Bolt Beranek and Newman Inc January
1969
8 R BINDER
Multiplexing in THE ALOHA SYSTEM:
MENEHUNE-KEIKI design considerations
ALOHA SYSTEM Technical Report B69-3 University of
Hawaii Honolulu Hawaii November 1969
9 W W PETERSON E J WELDON JR
Error-correcting codes-Second edition
John Wiley & Sons New York New York 1970
10 D T BROWN W W PETERSON
Cyclic codes for error detection
Proceedings IRE Vol 49 pp 228-235 1961
11 H H J LIAO
Random access discrete address multiplexing communications
for THE ALOHA SYSTEM
ALOHA SYSTEM Technical Note 69-8 University of
Hawaii Honolulu Hawaii August 1969
12 W H BORTELS
Simulation of interference of packets in THE ALOHA
SYSTEM
ALOHA SYSTEM Technical Report B70-2 University of
Hawaii Honolulu Hawaii March 1970
13 P TRIPATHI
Simulation of a random access discrete address communication
system
ALOHA SYSTEM Technical Note 70-1 University of
Hawaii Honolulu Hawaii April 1970
Computer-aided system design*
by E. DAYID CROCKETT, DAYID H. COPP, J. W. FRANDEEN, and CLIFFORD A. IS BERG
Computer Synectics, Incorporated
Santa Clara, California
PETER BRYANT and W. E. DICKINSON
IBM ASDD Laboratory
Los Gatos, California
and
lVIICHAEL R. PAIGE
University of Illinois
Urbana, Illinois
Gatos, California, which defined the proposed CASD
system and looked into the problems of building the
various component programs. Details of several
prototype programs which were implemented are
given elsewhere. 1 There are no present plans to continue work in this area. This paper is essentially a
feasibility report, describing the overall system structure and the reasons for choosing it. It includes descriptions of the data forms in the system and of the
component programs, discussions of the overall approach, and an example of a device described in the
CASD design language.
INTRODUCTION
This paper describes the Computer-Aided System
Design (CASD) system, a proposed collection of computer programs to aid in the design of computers and
similar devices. CASD is a unified system for design,
encompassing high-level description of digital devices,
simulation of the device functions, automatic translation of the description to detailed hardware (or
other) specifications, and complete record-keeping
support. The entire system may be on-line, and most
day-to-day use of the system would be in conversational mode.
Typically, the design of digital devices requires a
long effort by several groups of people working on different aspects of the problem. The CASD system would
make a central collection of all the design information
available through terminals to anyone working on
the job. With conversational access to a central file,
many alternative designs can be quickly evaluated,
proven standard design modules can be selected, and
the latest version of the design can be automatically
documented. The designer works only with high-level
descriptions, which reduce the number of trivial errors
and ensure the use of standard design techniques.
From October, 1968, through December, 1969,
the authors participated in a study at the IBM Advanced Systems Development Laboratory in Los
THE SYSTEM IN GENERAL
The (proposed) Computer-Aided System Design
(CASD) system is a collection of programs to aid the
computer designer in his daily work, and to coordinate record-keeping and documentation. It offers the
designer five major facilities:
H igh-level description
The designer describes his device in a high-level,
functional language resembling PL/I, but tailored to
his special needs. This is the only description he enters
into the system, and the one to which all subsequent
modifications, etc., refer.
* This work was performed at the IBM Advanced Systems Development Laboratory, Los Gatos, California.
287
288
Fall Joint Computer Conference, 1970
High-level simulation
An interpretive simulator allows the designer to
check out his design at a functional level, before it is
committed to hardware. The simulation is interactive,
allowing the designer to "watch" his design work and
evaluate precisely design alternatives.
Translation to logic specifications
The high-level design, after testing by simulation,
is automatically translated to detailed logic specifications. These specifications may take a variety of forms,
such as (1) input to conventional Design Automation
(DA) systems, or (2) microcode for an existing machine.
On-line, conversational updating
The designer makes design changes and does his
general day-to-day work at a terminal, in a conversational mode. Batch facilities are also available.
design automation systems) is a natural by-product
of the CASD organization.
The CASD system can thus be viewed as an extension
to higher levels of current systems for design, in roughly
the same way that compilers are functional extensions
of assemblers to higher levels.
The general organization of the system is pictured
in Figure 1. The designer describes his device in a
source design language, which is translated by a compiler-like program called the encoder to an internal
form. The internal form is the input both to the highlevel simulator (called the interpreter) and to a series of
translators (two are shown in Figure 1) which convert
it to the appropriate form of logic specifications. Different series of translators give different kinds of final
output (e.g., one series for DA input, another series
for microcode). The entire system is on-line, operating
under control of the CASD monitor, which handles
communication to and from the terminals. The user
interface programs handle the direct "talking" to the
user and invoke the proper functional programs.
DATA FORMS IN THE CASDSYSTEM
Complete file maintenance and documentation
Source design description
Extensive record-keeping is provided to keep track
of different machines, different designs of machines,
different versions of designs, results of simulation runs,
and so forth. High-level documentation of designs
(analogous to that produced at lower levels by today's
The CASD design language the designer uses is a
variant of PL/I, stripped of features not needed for
computer design and enriched with a few specialized
features for such work. PL/P and CASD's languageS
are described more fully elsewhere.
Procedures
The basic building block in a CASD description is
the procedure. A procedure consists of: (1) declarations
of the entities involved in the procedure, and (2) statements of what is to be done to these entities. A procedure is written as a PROCEDURE statement, followed by the declarations and statements, followed
by a matching END statement, in the usual PLII
format:
PROC1:
PROCEDURE;
declarations and statements
ENDPROCl;
KEY
..-.-.... = DATA FLOW
+---+ = CONTROL FLOW
Figure I-The CASD system
defines a procedure whose name is PROC1.
A procedure represents some logical module of the
design, e.g., an adder. A complete design, in general,
would have many such procedures, some nested within
Computer-Aided System Design
others. The adder procedure, for example, may contain a half-adder as a subprocedure.
289
2. The WAIT statement takes the form
WAIT(expression) ;
Data iteJns
Each procedure operates on certain data items, such
as registers or terminals. These items are defined by
DECLARE statements, which have the general format:
DECLARE name attribute, attribute, ... ;
The name is used to refer to the item throughout
the description. The attributes describe the item in
more detail, and are of two types-logical and physical.
Logical attributes describe the function of the item
(it is bit storage, or a clock, say); physical attributes
describe the form the item is to take in hardware
(magnetic core, for example). Logical attributes influence the encoding, interpreting, and translating
functions. Physical attributes, on the other hand, are
ignored by the interpreter, giving a truly functional
simulation.
Like any block-structured language, the CASD
language has rules about local and global variables,
and scope of names. These have been taken directly
from the corresponding rules for PL/I.
Statements
The basic unit for describing what is to be done to
the data items is the expression, defined as in PL/I
but with some added Boolean operators, such as
exclusive or (jIJ), and some modifications to the bit
string arithmetic.
The basic statement types for describing actions
on data items are the assignment, WAIT, CALL, GO
TO, IF, DO, and RETURN statements. These are
basically as they are in PL/I, except as described below.
1. The assignment statement is extended to allow
concatenated items to appear on the left-hand
side. Thus:
XREG
II YREG:=ZREG;
where XREG and YREG are 16 bits each and
ZREG is 32 bits, means to put the high 16 bits
of ZREG into XREG and the low 16 bits into
YREG. In combination with the SUBSTR
built-in function,4 this assignment statement
offers convenient ways to describe shifting and
similar operations. The assignment symbol itself
is the ALGOL" : = " rather than" = " as in PL/I.
It thus differs from PL/I in that it allows one
to specify a wait until an arbitrary expression is
satisfied. This is useful for synchronizing tasks
(see below).
3. The GO TO statement includes the facility of
going to a label variable, and the label variable
may be subscripted. This is useful for describing
such operations as op-code decoding-for example: GO TO ROUTINE (OP).
Sequencing
The differences in motivation between CASD's
language and PL/I are most evident in matters of
sequence control and parallelism. PL/I, as a programming language, does not emphasize the use of parallelism. Programs are described and executed sequentially, which is not adequate for a design language.
The basic unit of work in CASD is the node. A node
is a collection of actions which can be performed at
the same time. For example, XREG: = YREG; and
P:=Q; can be performed together if all t4e items involved are distinct. On the other hand, XREG: =
YREG; ZREG:=XREG; cannot be performed (as
written) at the same time, since the result of the first
written operation is needed to do the second. The
basic CASD rules are:
1. Operations are written as sequential statements.
2. However these operations are performed (sequentially or in parallel), the end results will
be the same as the results of performing them
sequentially.
3. Sequential statements will be combined into a
single node (considered as being done in parallel)
whenever this does not violate rule 2. That is,
CASt> assumes you mean parallel unless there's
some "logical conflict."5
Of course, the designer may want to override rules
2 and 3. Another rule gives him one way to do this:
4. A label1ed statement always begins a new node.
Another way is by specifying parallelism explicitly. If the DO statement is written as
DO CONCURRENTLY, all statements within
the DO will be executed in parallel. Finally,
the TASK option of the CALL statement makes
it possible to set several tasks operating at once.
290
Fall Joint Computer Conference, 1970
Preprocessor facilities
Some of the PL/I preprocessor facilities have been
retained. These include the iterative %DO, which is
particularly useful in describing repetitive operations,
and the preprocessor assignment statement, useful
for specifying word lengths, etc.
No defaults
Unlike PL/I, the CASD language follows the principle that nothing should be hidden from the designer.
In particular, it has no default attributes, and everything must be declared. Similarly, it does not allow
subscripted subscripts, subscripted parameters passed
to subroutines, or anything else that might force the
encoder to generate temporary registers not specified
by the designer. Such restrictions might be relaxed in
a later version, but we feel that until we have more
experience with such systems, we had better hide as
little as possible.
Internal form
Before the source description can be conveniently
manipulated by other programs, it must be translated
to an internal form. This form is designed to be convenient for both the translator programs and the interpreter. Compromises are necessary, of coursea computer program might be the most convenient
form for simulatjon, but would be of no use at all to
the translator.
The CASD internal form resembles the tabular
structure used for intermediate results in compilers
for programming languages. It consists of four kinds
of tables: descriptors, expressions, statements and
nodes.
The descriptor table records the nature of each item
(taken from its DECLARE statement). The entries
are organized according to the block structure of the
source description and the scope-of-names rules of
the language.
The expression table contains reverse Polish forms
of all expressions in the source description, with names
replaced by pointers to descriptors. Each expression
appears only onee in the expression table, although
it may appear often in the source description. In effect,
the expression table lists the combinational logic the
translator must generate.
The statement table consists of one entry for each
statement in the source description, with expressions
replaced by pointers to entries in the expression table,
and a coded format for the rest of the statement
(statement type plus parameters).
The node table tells which statements in .the statement table belong in the same node, and the order in
which various nodes should be executed.
The internal form has thus extracted three things
from the source description-data items, actions to
be taken on those items, and the timing of the actions-and recorded them in three separate tablesthe descriptor, the statement, and the node tables.
The expression table is added for convenience.
Simulation results
The high-level simulation involves three forms of
data: values of the variables, control information, and
run statistics.
Before a simulation run begins, the variables of the
source design description (corresponding to registers,
etc.) must be assigned initial values. One way to do
this is with the INITIAL attribute in the DECLARE
statement) which makes initialization of the variables
at execution time a fundamental part of the description.
Sometimes, though, the designer may want to test
a special case, and simulate his design starting from
some special set of jnitial values. CASD permits him
to store one or more sets of initial values in his files;
and for a given simulation run, to specify the set of
initial values to be used. In this way, he can augment
or override the INITIAL attribute.
At the end of a simulation run, the final values of
the variables may be saved and used for print-outs,
statistics gathering, or as initial values for the next
simulation run. That is, a simulation run may continue
where the last one left off.
The high-level, interpretive simulation in CASD
is perhaps most useful because of its control options.
As an interpreter, operating from a static, tabular
description of the device, the CASD simulator can
give the user unusually complete control over the running of the simulation. Through a terminal, he can at
any time tell the system which variables to trace, how
many nodes to interpret at a time, when to stop the
simulation (e.g., stop if XREG ever gets bigger than 4
and display the results), and so forth. These control
conditions may be saved just as the data values may
be, and a simulation run may use either old or new
control conditions.
Permanent records of a simulation also include summaries of run statistics (the number of subprocedure
calls, number of waits, etc.).
Computer-Aided System Design
Translator output
Different translators produce different kinds of output. Assembly-language level listings of mircocode
might be needed for some lower-level systems, the
coded equivalent of ALD sheets for others. Typically,
output would include error and warning messages.
File structure
In an on-line, conversational system, it is particularly important that the working data be easily ac··
cessible to the user and the control language seem
natural to him. CASD attempts to facilitate user control in two ways: through the user interface programs,
and the structure of the data files.
The basic organizational unit in the CASD files
is called the design. A design consists of all the data
pertinent to the development of some given device.
A design may have many versions, representing current alternatives or successive revisions. Each version
has some or all of the basic forms of data associated
with it: source description, internal form, simulation
results, translator output, and so on.
Two catalogs, one for designs and one for versions,
are the basic access points to CASD data. A typical
entry in the design catalog (a design record) contains
a list of pointers to the version descriptors for each
version of every design in the system. The version
descriptor contains pointers to each of the various
forms of data for that version (source description, ... )
plus control information telling which set of translators
has been applied to the design in this version, and so on.
These descriptors give the user interface programs
efficient access to needed data. For example, if the
user asks to translate a given design, the interface
finds the version descriptor, and can then tell if the
design has been encoded, and if not, inform the user
and request the input parameters for encoding.
PROGRAMS IN THE CASD SYSTEM
CASD monitor and support programs
All the CASD component programs are under control of a monitor program, which provides the basic
services for communicating with terminals and allocates system resources. In the prototype version 6 the
environment was OS/360 1VIVT, and it was convenient
to set up the monitor as a single job, attaching one
subtask for each CASD terminal. The CASD files were
all in one large data set, and access to them was controlled by service routines in the monitor. The moni-
291
tor also controlled the allocation of CPU time to various
CASD terminals within the overall CASD job. This
approach makes it easier to manage the various interrelated data forms within the versions, and would
probably work in environments other than OS/360
as well.
Besides the monitor and the data access routines,
the support programs include a text-editing routine
to use in editing the source description.
User interface programs
CASD system control is not specified in some general
language. Rather, each CASD function has its own
interface program, which has the complete facilities
of the system available to it.
The design records and version descriptors give
precisely the information needed by user interface
programs. A typical user interface program might be
one for encoding and simulating a source design description already in the CASD files. The version descriptor
shows, for example, whether or not the source description has already been encoded. The interface may then
give the user a message like "Last week you ran this
design for 400 nodes. Should the results of that run
be used as initial values for this run?" The point is
that the conversation is natural to the task at hand.
The tasks under consideration are well defined, and
each natural combination of them has its own interface
program.
Encoder
Since the CASD encoder is roughly the first haH
of a compiler, it may be built along pretty standard
lines. Care must be taken only in providing some sort
of conversational compilation facility. Conversational
interaction is an important part of the CASD approach
to design, and some sort of line-by-line feedback is
required. Similarly, since modification is so common
in design work, recompilation must be as efficient as
possible. Incremental compilation-translating each
source statement as far as possible on input, independently of other statements-is one answer. Then only
those statements which have changed since the last
compilation need be recompiled. The approach used
in the CASD prototype is described elsewhere. 7,8
Interpreter
The basic unit that the interpreter simulates is the
node table, the various statements which comprise
292
Fall Joint Computer Conference, 1970
the node are identified. These statments are then "executed" in two steps: First, all the expressions in the
statements are evaluated; second, the results are stored.
By this two-step procedure, the parallelism inherent
in the definition of the node is correctly simulated.
The interpreter steps from node to node, as they
appear in the node table, with several exceptions. One
is the conditional branch, where some (usually just one)
statment within the node must be evaluated or executed to determine what the next node should be.
Another exception is when wait, halt, or trace conditions have been met. Such "values" as "stop if this
item is referenced" may be stored with the item's
descriptor in the internal form. If this kind of condition is encountered in a node, the interpreter takes
the action indicated before going to the next node.
Control conditions like these may be altered dynamically by the user, who may, when a "halt" condition
is satisfied, not only observe the variables and their
values, but alter the control conditions.
Translators
The translator used in the prototype system converts
the internal form to a list structure of the machine logic. Techniques for translating from this to
DA input or actual circuits for any given circuit
family are straightforward. The elements of the list
structure are: hash cells, part cells, sub expression cells,
assignment cells, action cells, condition cells, and clock
cells. Hash (as in "hash code 1' ) cells contain index
entries and cross-references to the rest of the cells.
Part cells contain all the information declared about
each item; subexpression cells indicate how the various
items are to be combined to form circuits. Assignment
cells tell what data is to be transferred to where. Action
cells and condition cells are lists of which actions (e.g.,
assignments) are to be taken and under which conditions. Clock cells contain labels and other information about sequencing. Most of the information in
these cells comes fairly directly from the appropriate
tables in the internal form, but the translator links the
cells in a way that corresponds to the hardware that
must be generated. For example, all assignments to
a given register are linked together, and this might
correspond (for a particular circuit family) to a single
storage bus.
Essentially, the translator reduces the high-level
description to a form which currently known procedures9 ,10,l1,12 can handle, by breaking up the information in the internal form and linking it up again
in several different ways. Details of the various linking
schemes and how they relate to the source description
are given elsewhere. 13
Other programs
The general structure of the CASD system is flexible
enough to permit addition of other programs. A few
possibilities have been considered.
One obvious drawback of interpretive simulation
is the overhead. Simulation by compilation to machine code would be perhaps 50 or 100 times as fast.
This is a significant difference on long runs, after the
design is basically checked out (e.g., runs to get firm
performance figures).
A generalized assembler program to prepare program
input to the interpreter would allow larger quantities
of software to be tested by "running" it on the machine being simulated.
Cost-estimating programs operating directly from
the internal form would give quick-and-dirty estimates
without going through the entire hardware translation
process. Translation from the internal form to microcode is another possible extension.
COMMENTS
History
Others-most notably Gorman and Anderson,14
Schorr,1s Franke,16 Duley and Dietmeyer,17,18 Friedman and Yang,20 and Metze and Seshu21-have described languages and systems for logic translation or
simulation, and occasionally for both. Typically, in
logic translation systems, the design is described in a
special-purpose procedural language similar to programming languages. The description is usually at
a lower level than in CASD and is translated to Boolean equations, or some similar form, by programs
written for the purpose.
In most simulation systems, on the other hand,
designs are described in some high-level, generalpurpose language-either a general simulation language,
or an existing programming language augmented with
timing subroutines and the like. The description is
translated by an existing compiler to a program which
performs the simulation.
There is good reason for this difference. Until recently, no existing programming or simulation language
was really adequate to describe logic, and no generalpurpose simulation system was so deficient as to justify
creating a special system for simulating computer
Computer-Aided System Design
designs. But the advantages of integrating logic translation and simulation into the same system outweigh
these factors, in our judgment.
Integration of the two functions is achieved in CASD
by translating a single, high-level, special-purpose
language to a common internal form, providing input
to both logic translation programs and an interpretive
simulator. The interpretive simulation is also a key
point in making the system on-line.
Another innovation in CASD is the way in which
descriptions incorporate timing. Timing is included
rather explicitly in typical existing languages. At
lower levels, every statement or action is accompanied
by an indication of when it is to take place (at which
clock pulse, say). At higher levels, actions are simply
recorded sequentially, with some indication of how
long they take and what resources they require. (Simulators operating from these descriptions usually construct "future events" lists, ordered by increasing
time of occurrence, and simulate whichever event is
on top of the list at the moment.)
Timing in the CASD descriptions is based on the
use of asynchronous design as proposed by Metze
and Seshu. 22 Multiple tasks are synchronized by using
shared variables and referring to them with WAIT
statements. This approach has several advantages.
Asynchronous design at the functional level, as offered by the CASD system, allows reasonable hardware independence, since synchronizing conditions
refer to elements of the functional design rather than
to its physical implementation. (An -asychronous
description may, of course, be implemented in either
synchronous or asynchronous logic circuits.) Perhaps
most important, especially for an on-line system, is
that the PL/I multitasking scheme, from which the
CASD timing approach is derived, and techniques
like DO CONCURRENTLY make it possible to describe timing relationships in a quick and natural
manner.
Advantages of an on-line system
Conventional design work is slowed by turn-around
time (in the model shop as well as in the computation
center) and an elaborate hierarchy of system architects,
engineers, and technicians. One result is that few alternatives are considered in designing a system, and
fewer still are evaluated in any systematic way. The
CASD system bypasses these limitations by putting
the designer directly in touch with a design system
by a terminal, having the system take over many of
the bookkeeping functions of design, and giving him
293
immediate feedback at each stage of the design process.
Immediate feedback is important in:
a. Encoding, where descriptions are entered line
by line, and syntax is checked immediately,
allowing immediate correction and modification.
b. Simulation, in which the designer may "converse" with the system as his design is simulated. He may change control conditions as the
simulation progresses, look at values of data
items, and so forth.
c. Selection of different translation procedures
based on the results of simulation, cost estimating programs, or other translations.
Except for (a), these could be done with a batch
system, of course, but they are much more effective
in an on-line environment. Suppose, for example, that
a design for a computer is stored in the system, and it
contains special hardware for floating point operations.
The designer wants to know just what difference it
would make if he eliminated this hardware and did all
floating point operations with programmed subroutines.
With the CASD text-editing programs, the designer
would remove the description of the hardware for
floating point, and change the floating point operation
code descriptions to trap these operations to a specified
location. He would re-encode the description and correct
any errors. By simulating and translating both this new
description and the old one, he would obtain precise
figures on the exact difference in hardware and running
time. An on-line system can reduce this complicated
maneuver to a one-day job.
Advantages of an integrated system
Most of the advantages of integrating all aspects
of design in a single system can be summed up in one
word: control. Consider how important it is that the
simulation model accurately reflect the hardware that
is being built. Under the CASD system, this is automatic: the design description is the simulation model.
A necessary part of the design process is low-level
checking of logic circuits both for logical correctness
and for race and hazard conditions. In CASD, the system always uses proven .methods. Besides reducing
the necessary tests, this controlled logic synthesis
ensures the use of standard techniques and building
blocks. Different optimality criteria can be used and
the results compared. For example, the different effects of restricting the logic to one chip type, or allowing
more freedom, might be compared. Criteria such as
these are often more important than minimizing the
294
Fall Joint Computer Conference, 1970
total number of circuits; and under the CASD system,
the correct criteria can be enforecd.
A good design must be reliable and allow ready
diagnosis of problems that occur. The CASD controlled
synthesis ensures that the resulting logic is diagnosable.
Indeed, the required diagnostic tests can be produced
as an integral part of the translation process by at
least one method. 23 It is easy to see how translators
could be made to produce either duplicated logic,
triple-modular-redundant logic, or unduplicated logic
(say) if the designer wants to compare their relative
costs.
Finally, the advantages of a unified file system, providing documentation automatically, are fairly clear.
Accurate, consistent, up-to-date documentation may
be the most important single feature of the CASD
system.
EXAMPLE
This section contains an example of a computer
described in the CASD design language. The computer
and the way it is described have been chosen to illustrate the features of the language, rather than for any
intrinsic merit. The computer is a simple binary machine called SYSTEM/D. It contains 65,536 32~bit
words of memory and 16 general-purpose and index
registers called XREG(O) through XREG(15). XREG
(0) always contains all zeros. It may be stored, tested,
and shifted, but not altered.
The instructions of SYSTEMjO are one word (32
bits) long. The first 8 bits contain the operation code.
The next 8 bits contain two four-bit fields, the M (for
modifier) and X (for index register) specifications.
The last 16 bits are used for an address.
The following instructions are described in the following CASD description:
ST
CLA
BC
M,X,ADDR Store the contents of XREG(M)
into memory location [ADDR+
contents of XREG(X)].
M,X,ADDR Load the contents of memory
location [ADDR+contents of
XREG(X)] into XREG(M).
M may not equal zero.
M,X,ADDR Branch to location [ADDR+
contents of XREG(X)] if and
only if the contents of XREG
(M) is zero. (Since XREG(O)
is always zero, BC 0, X,ADDR
is an unconditional branch.)
RR
BAL
SIO
M,X,ADDR
Rotate XREG(M) right [contents of XREG(X) + ADDR]
places. The number of places to
rotate is always assumed to be
modulo 32.
M,X,ADDR Branch and Link to location
[ADDR+contents of XREG(X)]
storing the return address (=
next location) in the low-order
16 bits of XREG(M), setting the
high-order 16 bits of XREG(M)
to zero. M may not equal zero.
M,X,ADDR Start an input-output operation
on device number [ADDR +
contents of XREG(X)]. The M
field specifies which input-output operation is to be performed.
Figure 2 shows the data flow the designer might
expect CASD to generate, after entering the functional
description given in Figures 3 through 7. (The order
of the figures is for illustration only. The designer need
have only a shadowy outline of the data flow in mind
at the time he prepares his functional description.)
Figures 3 through 7 are annotated to highlight interesting features of the CASD language. Also note
that there are a few places where the designer did
choose to dictate the data flow. For example, the only
link to the XREG's is constrained to be through the Y
register by specifying Y: = MSDATA; XREG(M): =
Y; rather than just XREG(M):=MSDATA; . So,
the designer can exercise as much or as little direct
influence on the final data flow as he chooses.
ACKNOWLEDGMENTS
We wish to thank George T. Robinson and Dr. Eugene
E. Lindstrom for their guidance and advice.
REFERENCES
1 E D CROCKETT et al
Computer-aided system design
Advanced Systems Development Division IBM
Corporation Los Gatos California Technical Report
~ 16.198 1970
2 IBM System/360 PL/I reference manual
IBM Corporation White Plains New York Form C28-8201
3 CROCKETT Appendix A
4 IBM Corporation page 237
5 CROCKETT Appendix G
6 IBID Appendix H
7 IBID Appendices I, J, K
Computer-Aided System Design
'x
NRW. OPERATICf'l PROCEDURE
LAllCL INITIAL(ST,CLA,BC,RR,BAt.--,
SIO,(250)ILLEGAL);
'" -------------Il
MAR
t]OLATCHIITRAPLATCH!
(32)
END EAIlOR,
-
~
16
=ma.
i_
of )
_ _ _ _ _..J_
Routi.... ILLEGAL. TRAPROUTINE
~
8
nt;Itgivent..
(AOB)
Figure 5-CASD description of SYSTEM/O, page 3
SYSTEM/O DATA FLOW
Figure 2-Flow of data in SYSTEM/O
/x- EXECUTICf'l ROUTINES x/
/X STORE INSTRUCTlCf'l ,,/
IX EVALUATE EFFECTIVE ADDRESS "/
/x .GET REGISTER VALL£ ,,/
I" PUT IT INTO HAIN i'EKlRY "/
SYSTEMO:
DECLAAE
PROCEllUlE CPTlCf'lS(HAIN);
~_ _ _-,(£:i~~nWli's;ao;aoiUl"'~TIQ'ct""""CO'UlJlTEiA-A-""f----.....-1QCis.16-bitstcngldlvicl.)
CP BIT(S),
M SIT(~) ,
X BIT(~),
IIDIR BIT 16)
G DeFINED Of'
IMlIxIlAOOl,
,~ Of'ERATICf'l CODE ",
'" MJIliFIER FIELD ",
'" Itax REGISTER SPECIFICATlCf'l ,,/
AL>DRESS PORTICf'l Ci' INSTRl.CTICf'l"/
I':.
'~ HAIN ST~ DATA REGISTER '"
'" RIGHT HALF "/
&0:65535)
MAR
BC:
'" u.cex REGISTERS 0 THWIJGH 15 "'
XREG(O:I5) BIT(32),
8IT02>;)~--I"'-""",,"IIItU-jrtrtJ~lRlJRT"i""JAIr-------I-G2~==~KJ
y:=-'OO;
~ ~:)'O' THEN
IC
:=_,
/X CCf'jD1T1~ BRN«:H RWTlNE x/
RETIMj,
RETIMf;
I" HAIN i'EKlRY AOOIESS REGISTER ,,/
8IT(l6),
IY,
'" Y REGISTER ,,/
2 YL 8IT(l6),
2 YR 8IT(6),
IOLATCH BITO),
I" LEFT HALF "/
'" RIGHT HALF x/
IOREG 8IT(6),
I" USED TO tt:lLD OEVICE iU'8ER "/
'" USED TO tt:lLD 110 Of' CODE '"
'" CCf'jTROL LATCH BETWEEN EXECUTICf'l ,,/
,,/
Figure 6-CASD description of SYSTEM/O, page 4
Phyolcolottr _ _
'" In) I/O ROUTINES
lOOP BIT(8),
TlW'LATCH SITO),
IPLLATCH BITO),
_OIIIittod.
/" USED TO SIGNAL I/O TRAP "/
'" INOICATES IPL BUTTCf'l DePRESSED '"
Figure 3-CASD description of SYSTEM/O, page 1
'" ilOTATE RIGHT ROUTINE
"I
/" START THE I/O LOOP GOING '"
IM:"
'" SET XAEG(O) EQUAL TO ZERO "/
'" RESET IPL LATCH
0Ct-lf ~/
'" FETCH
PW
EXECUTE AN OPERATlCf'l
~---------------I"-~----ANO--L-I~--R-OUT-I-NE-,,-/----~~f~~
"I
MISSING PROCEDURES:
XREG(H): = Y;
IIIC,
RETIMj,
=
::~~,~.R~~~r.h!'~": tr.~'t.T~i~ ::mber
II?~~~!."='~~O;:
EAIlOR;
R:= (16)'0'
IC := MAR;
GO TO START;
:,
BAl.:
L
1?:.~oWcH
/X START I/O ROUT INE x/
IX GET OEVICE NU1!ER x/
/X WAIT I.NTIL PREVIOUS 1-0 STARTS x/
: ~~o. When the operation in compl.... it sots TRAPLATCH
:';~~tC=tiV;~~~w~~r~;!.:{~=~~:;!Mo<
including (CARRYFLAGzO l') the carry on the result.
Figure 4-CASD description of SYSTEM/O, page 2
Figure 7-CASD description of SYSTEM/O, page 5
296
Fall Joint Computer Conference, 1970
8 P BRYANT
A note on designing incremental compilers
Submitted to CACM August 1970
9 J R DULEY D L DIETMEYER
Translation of a DDL digital system specification to Boolean
equations
IEEE Transactions Vol C-18 April 1969
10 T D FRIEDMAN
ALERT: a program to produce logic designs from preliminary
machine descriptions
Research Division IBM Corporation Yorktown Heights
New York Research Report No RC-1578 March 1966
11 T D FRIEDMAN S C YANG
Methods used in an automatic logic design generator (ALERT)
Research Division IBM Corporation Yorktown Heights
New York Research Report No RC-2226 October 1968
12 D F GORMAN J P ANDERSON
A logic design translator
Proceedings AFIPS Fall Joint Computer Conference 1962
13 CROCKETT Appendix M
14 GORMAN and ANDERSON
15 H SCHORR
Computer-aided digital system design and analysis using a
register-transfer language
IEEE Transactions Vol EC-13 December 1964
16 E A FRANKE
Computer-aided functional design of digital systems
IEEE Southwestern Conference Record April 1968
17 DULEY and DIETMEYER op cit
18 J R DULEY D L DIETMEYER
A digital system design language (DDL)
IEEE Transactions Vol C-17 September 1968
19 FRIEDMAN
20 FRIEDMAN and YANG
21 G METZE S SESHU
A proposal for a computer compiler
Proceedings AFIPS Spring Joint Computer Conference
1966
22 IBID
23 CROCKETT Appendix N
Integrated computer aided design systems
by ROGER C .. HURST
North American Rockwell
Los Angeles, California
and
ALLEN B. ROSENSTEIN
University of California
Los Angeles, California
Process undergoing change. In response to the increasing need to search for an optimum solution have come
a number of optimization programs, and very recently,
a powerful generalized optimization program (General
Electric's AID)3 that may be coupled to existing
analysis routines to close the Design Process loop,
Figure 2.
The statement that the digital computer offers extended assistance in many if not most stages of the
Design Process presents nothing new. We should like
to examine, however, some of the emerging advances
on the road from Computer .Aided Design to Design
Automation. It should be obvious that we are now
ready to seriously consider Integrated Computer Aided
Design systems that tie together individual stages of the
design process, many of which have already been programmed.
INTRODUCTION
Computer Aided Design, the initial phase of Engineering Design Automation, has been characterized by the
development of individual computer programs for
engineering design tasks. These programs specifically
describe design tasks that are identified as repetitive in
nature and, as such, are appropriately interspersed
into the overall design process.
Design Automation is now entering a new phase
characterized by the need for an integrated design approach to the modeling, synthesis, analysis, optimization, documentation, and production functions of
entire engineering projects and of complete engineering
fields. Concurrent with this need has come a recognition
of the generalized Morphology and Anatomy of the
Design Process which in turn has led to a rapid development of formal procedures for many of the basic
functions of the Design Matrix (Figure 1).1 Since the
Decision Making process which we call Design and its
fundamental elements apply without restriction to all
engineering activities, it is not surprising to find that
very general computerized design programs are beginning to appear which can be applied to whole classes
of engineering problems without regard to particular
disciplines.
Computers have long been applied to the analysis
phase of the design process with the great majority of
existing engineering computer programs, in fact, devoted to analysis. A study of the limited number of
generalized models available to the engineer and of the
mathematics applicable to these models makes obvious
the utility of an analysis language such as Fortran and
the possibilities for further generalization. 2 But analysis
and simulation are not the only phases of the Design
INTEGRATED COMPUTER AIDED DESIGNICES AND ELECSYS
The requirements for an Integrated Computer Aided
Design system can be outlined as follows:
1. Generality must be extensive enough to provide
a substantial design capability for a complete
class of problems or major areas in engineering
fields such as Civil Engineering or Electrical
Engineering. System capabilities would of a
necessity include generalized optimization routines and strategies, extensive data handling
and file capacity, and solution of simulation programs as well as comprehensive analytical capability-all to operate upon a common data set.
297
298
Fall Joint Computer Conference, 1970
In this case, we have modified an existing Electronic
Circuit Analysis Program (ECAP) -the DC analysis
portion only-to reflect the external subsystem requirements of ICES. Neither ICES or ELECSYS can
ever be considered complete systems in that they have
been deliberately designed for the almost unlimited
addition of engineering subsystems as desired.
,.,.""'....."
......
ICES
Figure 1
2. Flexibility is required to allow selection and coupling of preferred programs and the substitution
of data at will with negligible effort.
3. Problem Oriented Languages that allow the engineer to communicate with the computer in
the same engineering language that he would use
with fellow engineers are a necessity if the Integrated Computer Aided Design system is to
earn wide user acceptance.
4. A Programming mechanism should be available
to allow the insertion of new design routines or
the modification of existing programs with a minimal investment in programming time.
In spite of the identification of the computer with
electrical and electronic engineering, and the early extensive use of computers for the design of electrical
components such as transformers and electronic subsystems including computer subsystems, the first
operational Integrated Computer Aided Design system
has appeared in Civil Engineering with the MIT developed Integrated Civil Engineering System (ICES).4
It is the intent of this paper to briefly describe ICES
and then obtain some review of its capabilities by
describing a new Integrated ELECtronic Engineering
SYStem (ELECSYS) that utilizes the basic ICES concepts--"and programs for internal control of the computer
software and hardware.
Generality of the Integrated Computer Aided Design
concept will be demonstrated by the conversion from
the Civil Engineering environment of ICES to the
Electronic Engineering of ELECSYS. Flexibility and
Programming capability are explored by utilizing an
MIT·· modified version* of ICES as the programming
structure to activate the first subsystem of ELECSYS.
* Modified to drop off Civil Engineering SUbsystems and add
programming routines to simplify the task of adding new subsystems.
Let us briefly examine the capabilities and structure
of ICES while reserving a more detailed explanation
for Appendix A. 5
ICES has been designed to allow engineers with little
or no computer programming experience to apply the
computer to a wide range of engineering problems. The
user can view ICES as a set of engineering subsystems
in a particular discipline of engineering such as structural analysis, soil mechanics, etc. , ... , which the user
can call upon individually or collectively to solve his
problems. Each subsystem has its own problem
oriented language that is derived from the natural
language of the discipline.
ICES is a modular, dynamic system that also has
been designed to simplify the programmer's task. Programming languages have been incorporated to enable
the programmer to readily make modifications and additions. To provide a full ICES system capability, a
computer will ultimately contain a total of six languages
or perhaps we should say six language levels if we count
the final machine language itself (Job Control Language, FORTRAN, ICETRAN, Command Definition
Language, and Problem Oriented Language). However,
the user need only master the simple problem oriented
languages of the subsystems and disciplines that interest him. He communicates with a subsystem only
through the commands of the subsystem Problem
Oriented Language (POL).
The subsystem programmers, on the other hand, will
ITATI.NlOf MOILIM
fOMIIUU,tlONOfJIIIIOI
..MUNG
YAL"'IYSTIM'OMaILATION
Y.
YI
'YNlHlIIIOfALTlMA1IVlI
MAL"'''
IV~
","~""'\,""LI"
•.• IfIIIoJICtM,M ...... ,....",.,
,,_IltAl.IIMI\IT¥
D.NOOUCIIM.IT't
',....,....fY
1 ......
l__ --_L-_-_-_-_-_-_-k1"':;;'~ ~- ~._
c:o.tuNlCAtlON
-----'--rDlIIGNINF'o...u.,.
I
~
Figure 2-The design-planning process flow chart
Integrated Computer Aided Design Systems
require two additional languages besides Fortran. The
first which has been called the Command Definition
Language (CDL) is used to write a program for each
subsystem to interpret each command in the POLand
provide direction for the processing of each command.
The CDL specifies what information should be provided in the engineer's commands, how and where
that information should be stored, and what operations
(ICETRAN programs) shall be used to perform the
desired operations upon the data.
I CETRAN, the second language of the subsystem
programmer, is an extension and expansion of FORTRAN that is used by the subsystem programmer to
develop the ICETRAN building block programs that
./
./
ICETRAN
PROGRAM
V
"
FLOW OF ceN rROL
__ -
-
-
FLOW OF INFORM .. TlO"
COL
COMMAND
T R ANSLA T ION
RULES
Figure 4-Subsystem execution
operate upon the engineering data. To facilitate the
translation from ICETRAN to FORTRAN and finally
to machine language, a. special translator program is
provided called the ICETRAN Compiler, Figure 3.
Operation of an integrated ICES type system can be
partially explained and the remaining ICES system
elements introduced by referring to Figures 4, 5, and 6.
Stored in computer primary memory, we find the Execu-·
ICES
PRECOMPILER
IBM 360!75 COMPUTER
~
"
GENERATED
FORTRAN
PROGRAM
SUBSYSTEM
LOAD
MODULES
./
/
I
COMMON
COMMUNICATION
AREA
I
I
I
I
COMMAND
DEfiNITION
BLOCKS
I
I
I
"
IBM 2311 DISK PACK
"ICES 35"
I
I
FORTRAN
COMPILER
SECONDARY STORAGE
SUBSYSTEM
LOAD
MODULES
~
"
MACHINE
LANGUAGE
PROGRAM
./
L _
COMMAND
DEfiNITION
BLOCKS
/
Figure 3-ICETRAN precompilation and compilation
299
Figure 5-ICES system organization
300
Fall Joint Computer Conference, 1970
Load Modules called up from secondary storage by the
Executive program. The Command Interpreter can
now refer to the subsystem command dictionary to
process subsequent commands. Each subsystem command calls for a specific Command Dictionary Block
which the Command Interpreter uses to analyze the
full command and transmit the correct information to
the required subprograms.
Data and information extracted from the commands
and the command definition blocks are stored in the
subsystem Common Communications Area where they
are available for processing by the ICETRAN programs of the subsystem load modules.
ELECSYS
Keeping in mind the built-in prOVlSIOns for expansion and ch;'nge, let us examine the requirements for
an Integrated Electronic Engineering Design System
(ELECSYS) and its implementation, Figures 7 and 8.
We wish to provide in a single computer· aided design
system all of the analytical methods, design rules,
manufacturing standards, component characteristics,
tabular data, simulation routines, and optimization
LEGEND:
PROGRAM
NOTE:
ICES EXECUTIVE
DIRECTS INTERNAL
SYSTEM LOGIC FLOW
ENG.
YES
Figure 6-System logic diagram
tive program that supervises and coordinates all ICES
jobs. The multi-subsystem capability of ICES demands
a dynamic data structure and extensive use of secondary storage. Stored in secondary memory for each subsystem are Subsystem Load Modules (constructed from
I CETRAN building block programs), Subsystem
Command Dictionary, and Subsystem Command
Definition Blocks.
The engineer's POL commands are dIrected to an
ICES Command Interpreter that proceeds on a command-by-command basis. From a primary command
dictionary, the first subsystem requested by the engineer will be identified and the corresponding Command Dictionaries, Command Definition Blocks, and
LEGEND.
(ENCIHEER)
ICOMPUTUI
Figure 7-ELECSYS system flow diagram
Integrated Computer Aided Design Systems
programs necessary for the computer aided design of
electronic equipment. All of the foregoing should be
available to the user in problem oriented languages
with a common vocabulary and similar formats. It
should be noted that ELECSYS would be classified as a
computer aided design system instead of design automated since the engineer will intervene at frequent intervals during the design process to establish desired
system behavior.
ELECSYS, Figure 7, has been laid out to follow the
iterative decision making pattern of the design process,
Figure 2. Design normally progresses from problem
recognition to problem definition where design requirements, constraints, and performance specifications are
established. A field of feasible system solutions is next
synthesized which in turn can be broken down into
subsystem, module, and finally circuit specifications.
At some function level, it becomes convenient to review
the applicability of existing designs.
Electronic subsystems readily lend themselves to
classification and evaluation, i.e., amplifiers, flip flops,
shift registers, etc. ELECSYS would include an extensive library of proven circuits and designs evaluated
in accordance with standard performance/cost criteria.
Full listings would also be provided of standard components along with their cost and performance characteristics. As the analytical capabilities of ELECSYS are
expanded, it has been suggested that a stage will
eventually. be reached when the computer can use its
off hours to rea~ the technical literature in order to
independently evaluate published circuits and update
its own library.
Both the engineer and the computer would review
their respective libraries for standard circuits capable of
meeting the required specifications. The ELECSYS·
Standard Circuit subsystem would provide the engineer with a thorough computerized search of existing
designs to meet specific performance specifications and
design criteria. If an acceptable circuit is not found, the
engineer will design a new circuit with the aid of the
computer circuit analysis programs. Final detailed
electronic designs are subject to many design reviews
to insure system performance and reliability. System
stress and reliability analysis can be done by the computer along with system simulation.
Since a common circuit data base is necessary for
both electrical and mechanical design, ELECSYS has
been conceived to provide POL routines for both the
electronic design and much of the mechanical design
required for manufacturing. After the electrical performance requirements are satisfied, the resultant
circuits are re-examined for fabrication. A set of programs should be incorporated to carry manufacturing
from printed and integrated circuit layouts through the
301
CHr~SSIS
PRINTED
CIRCUIT
Figure 8-Electronic equipment
wire harnessing and cabling necessary to interconnect circuits and components.
A very general purpose optimization program that
can be coupled to analysis routines (such as G.E.'s
AID) is to be included to provide computer assistance
in the determination of improved circuit and electromechanical system design.
INITIAL IMPLEMENTATION-ECAPNC
ELECSYS has been conceived as a flexible integrated
electronic design system that incorporates as subsystems existing or new computer programs in part or in
wholew herever desirable. To test the feasibility of this
concept, we decided, as mentioned earlier, to build
IBM's ECAP (Electronic Circuit Analysis Program) into
ELECSYS as a subsystem for New Circuit analysis,
ECAPNC.
Implementation of ELECSYS began with the acquisition from IBM of the ICES Type C Release version
containing all system programs necessary for ICES
302
Fall Joint Computer Conference, 1970
utilization including the programming capability for
adding new subsystems. Modification of the ICES Job
Control Language was required for the installation of
ICES on the UCLA Campus Computer Network.
With ICES operational on campus as "ICES35"
five major steps were taken to implement and verify
ECAPNC. The first three tasks were concerned with
the computer software needed by an engineer setting up a
subsystem. The next step employed the computer software provided to an engineer using a subsystem while the
final step became that of operational verification. Thus,
the first three tasks dealt with subsystem generation
whereas the last two specifically relate to subsystem
utilization in a problem oriented language environment.
Typical subsystem installation and operation can be
presented by reviewing those five tasks.
1. Precompilation, Compilation, and Object Load:
Programs are written in ICES FORTRAN
(ICETRAN) by the engineer designing an engineering subsystem which temporarily creates
and stores computer programs for engineering
operations. This task utilizes the ICES procedure
"Precompile, Compile, and Object Load" (Refer
to Figure 3) to process the written ICETRAN
programs in preparation for the next task of
Load Module Generation.
2. Load Module Generation: This task employs
the ICES procedure called "Load Module Generation" to combine or link edit the ICETRAN
programs of the previous task into Subsystem
Load Modules that satisfy the computer hardware requirements. The Subsystem Load Modules are computer programs permanently stored
for the performance of engineering operations.
To initiate ECAPNC, the DC Analysis portion of
the standard ECAP program was modified in accordance with tasks 1 and 2. In particular, six subprograms
were programmed in ICETRAN and added to the
original DC Analysis subprograms in order to provide
the final subscripted variable translation of ECAP
problem data. ICES CDL software cannot translate
POL data directly into Fortran subscripted variables,
thus, these extra ICETRAN programs provide the
necessary processing of ECAP compatible data. The
total package of I CETRAN subprograms (1400 cards)
were processed by tasks 1 and 2 to establish the engineering load module for the ECAPNC subsystem.
3. Subsystem Command Definition Execution: Utilizing the CDL of ICES, a subsystem vocabulary
must be developed to provide the Problem
Oriented Language (POL) required for task 4.
Permanent subsystem computer programs must
be created to interpret the engineer's English
language (POL) input and select the appropriate
building block programs for execution. ICES
CDL procedures are used to create a Subsystem
Command Dictionary and the individual Subsystem Command Definition Block associated with each command in the subsystem
dictionary.
Command Definition Language (CDL) programs
were designed to translate the Problem Oriented Language commands of ECAPNC, extract the problem
data, and convert that data into the appropriate
ICETRAN variables to be operated upon by the
ICETRAN subprograms for DC Analysis (task 2). A
total of 400 cards were required to generate the Subsystem Command Definition Dictionary and its COmmand Definition Blocks for the ECAPNC subsystem.
4. POL Program Execution: An individual program must be written for each new circuit requiring a DC performance analysis with
ECAPNC. However, the POL provided by task
3 completely routinizes this step making it
feasible to train technicians or secretaries to
convert the engineer's schematics into the required punched cards or tape.
5. Circuit Execution: With a program written for
the desired circuit topology, the program can be
submitted to a computer with the initial values
of individual components and the allowable
range of component values to be investigated.
The ELECSYS system presently utilizes batch
computer processing techniques to obtain solutions of circuit problems. Since the POL is conversational in nature, this is an unnecessary
restriction. Future systems will utilize a remote
CRT terminal or teletype to improve ICES
man-machine communication as well as job
turnaround time.
To verify the successful implementation of ECAP in
the ELECSYS subsystem, a sample electronic circuit
was run through tasks 4 and 5 of ECAPNC and compared with the results of submitting the same circuit
to the original ECAP program. The results were, of
course, identical.
The detailed explanation of the necessary ICES
modifications and required ECAP conversion under
tasks 1,2, and 3 is given in Reference 7. In Appendix B,
the POL Df task 3 is described and its application to a
simple circuit illustrated for tasks 4 and 5.
Integrated Computer Aided Design Systems
RESULTS AND CONCLUSIONS
This work was undertaken to obtain operational experience with Integrated Computer Aided Design Systems
and to provide a basis for consideration of further automation of the Design Process. We wished in particular
to test the concept of a very generalized Integrated
Computer Aided Design System that would be independent of its field of engineering application. Also,
although ELECSYS has been proposed (Figure 7)
with human intervention at every major step, it should
be apparent that further formalization of the engineer's
decision rules and data resources will allow significant
reductions in the number of unmechanized phases.
This, of course, would appear practical only if the
system can operate upon a common design problem
data base that is derived from the original problem
statement.
Allowing for the present limited ELECSYS implementation, our experiences to date have been quite
satisfying. No unusual difficulties were encountered in
utilizing the structure of ICES, designed as an Integrated Civil Engineering System, for ELECSYS, an
Integrated Electronic Engineering System. The feasibility and economics of incorporating existing design
subprograms into an integrated design system has been
clearly established. Once the details of ECAP and ICES
had been mastered, the programming chores required
to generate the load modules (tasks 1 and 2) and the
language translator (task 3) were found to be quite
reasonable.
The ECAP DC Analysis program was converted to
ICETRAN in two steps. The first step required a compatibility study of the language interface between
ECAP FORTRAN and ICES FORTRAN that resulted
in modification of several ECAP FORTRAN statements which would have created ICES system errors.
A second step was required to produce a set of subprograms necessary to overcome a subscripted variable
limitation of the ICES Command Definition Language.
Completion of both steps produced a permanently
stored set of DC Circuit Analysis subprograms.
Utilization of the existing ECAP routines saved, of
course, the substantial effort that would have been
required to create a new circuit analysis program.
It should be observed that problem oriented language programs such as ECAP, STRESS, CIRC, and
STRUDL in reality solve the same general class of
problem. In each of these cases the computer is given
the problem topology and component lumped parameter characteristics. With this data, the computer sets
up and solves the appropriate matrix. I t should be
feasible, therefore, to design into the Integrated Design
System a very general, lumped parameter, equation
303
writing, and analysis routine that would provide suitable load modules and eliminate the need to repeat
tasks 1 and 2. When general, lumped parameter, load
modules have been created for an integrated design
system, incorporation of engineering fields utilizing
lumped parameter models will require only the production of the problem oriented language from task 3.
Utilization of the ICES Command Definition Language to generate the CDL subprograms for ICETRANjPOL interface control and a set of CDL subroutines for data extraction and storage (task 3), gave
particularly interesting results. The programming
effort created a total of nine subprograms and five subroutines with a final program source deck of 370 CDL
cards. A significant difference in programming effort
and time is realized when the 370 cards of the CDL
program are compared to the 1610 Fortran cards required by the original ECAP Language Processor to
perform the same language translation. This comparison would indicate that the ICES CDL provides a
simplified programming capability for data translation
of complicated POL such as ECAP. With the adoption
of Integrated Computer Aided Design Systems somewhat dependent upon the programming investment,
the efficiency of the CDL will be of increasing importance particularly if generalized load modules can be
developed to reduce the programming effort of tasks 1
and 2.
Review of ECAPNC revealed that the POL and
flexibility criteria were satisfied. The POL notation of
ECAP was retained with small modification. However,
whereas the original ECAP language requires text in a
fixed order as well as a rigid format that tends to increase language programming errors, the ECAPN C
ordering of the text supplying problem data is very
flexible. The integrated system concept offers still
further opportunity for increasing the flexibility and
utility of ECAP. Recently while reviewing ELECSYS
with Mr. Howell Tyson of IBM, who is one of the
originators of ECAP, Tyson pointed out the advantages
that could be obtained by interfacing the ECAPNC
sub~ystem with the existing ICES TABLE subsystem. 6
A permanent file of electronic circuit components,
characteristics, particularly transistor models, could
be maintained by the TABLE subsystem and utilized
as required by the ECAPNC subsystem in conjunction
with the ICES system programs. By combining the
TABLE capabilities with ECAPNC, a more powerful
circuit analysis program could be achieved with circuit
lookup capability similar to the NET-1 program.
On the negative side, the average time for four
ECAPNC problem solutions was 21 seconds compared
to an average of 11 seconds for the identical solutions
with ECAP. The difference is caused by the separate
304
Fall Joint Computer Conference, 1970
processing that is performed by the CDL when extracting problem data. For offices with a large circuit
analysis load, the differences in computing time could
become prohibitive. On the other hand, when analysis
is considered as· only part of the computational load
of the design process, the advantages of the common
problem data base of the Integrated Computer Aided
Design System should more than compensate for the
analysis computing inefficiencies.
BIBLIOGRAPHY
1 A B ROSENSTEIN
The concept of engineering design as a formal discipline
Proc ASME 8th Annual Technical Symposium Albuquerque
New Mexico November 17 1967
2 A B ROSENSTEIN
Modeling, analysis, synthesis, optimization, and decision
maker in engineering curricula
UCLA Department of Engineering EDP2-68 April 1968
3 J K CAREY R L RUSTAG
AID-A general purpose computer program for optimization
Recent Advances in Optimization Techniques edited by
Love & Vogi 1966
4--Introduction to ICES
Department of Civil Engineering Massachusetts Institute
of Technology Cambridge Massachusetts Report R67-47
C 1967
5-ICES System-General description
Department of Civil Engineering Masachusetts Institute of
Technology Cambridge Massachusetts Report R67-49
C.1967
6--ICES Programmers Reference Manual
Department of Civil Engineering Massachusetts Institute
of Technology Cambridge Massachusetts Report R67-50
C.1967
7 R C HURST
The feasibility of an electrical/electronic engineering computer
system (ELECSYS) which utilizes the integrated civil
engineering system (ICES)
University of California at Los Angeles 405 Hilgard Avenue
Los Angeles, California 90024 Master's Thesis C 1969
8--1620 electronic circuit analysis program (ECAP)
1620-EE-20X user's manual
International Business Machines Corp Technical
Publications Department C 1965
APPENDIX A
INTEGRATED CIVIL ENGINEERING SYSTEM
(ICES)
The ICES system is now ready to perform its prescribed system tasks (Refer to Figure 6). These tasks
are externally controlled by the IBM 360 Job Control
Language (JCL) and internally by the ICES System
Programs. The external control process provides information to the computer system concerning the ICES
data flow between the IBM 360/75 central computer
and the IBM 2311 secondar,y storage disk pack. Internal control is provided by an appropriate ICES
system program for the complete performance of a
related system task. External and internal controls are
combined for each system task in order for the system
to be fully operational.
The following paragraphs illustrate the ICES control process for the first four system tasks. The fifth
system task concerns circuit solutions and the design
iteration process of the engineer.
The first system task for subsystem implementation
concerns the translation of ICETRAN programs into
machine language (Figure 3). The Job Control Language directs information flow between computer
hardware units such as secondary storage devices (disk
pack), and tape units. After appropriate units have
been accessed, program QQFUBAR, internal controlling program designated by the Task 1 JCL, is
executed and successively linked to Program QQVOLO,
the ICETRAN precompiler; to Program IEJFAAAO,
the E-Ievel FORTRAN compiler; and to Program
QQNIX3, the object program loader.
The second system task for subsystem generation
concerns the permanent creation and storage of the
machine coded programs from Task 1. After similar job
initialization and secondary storage accessing, the JCL
designates the Program QQFUBAR2 to provide internal control and successively link to Program
QQSETGEN, the load module interface program generator; and program ASMBLER, the E-Level Linkage
Editor. Program QQSETGEN generates an interface
program called QQSETUP which is tailor-made for
every subsystem load module, and is used whenever
the generated load module is entered for the performance of Task 4, Problem Oriented Language (POL)
Program Execution. In particular, the Load Module
Description input for this task provides the necessary
information to generate a unique QQSETUP program.
The third and fourth system tasks have radically
different functions. Task 3 involves the subsystem
generation of Command Definition Language dictionaries, while Task 4 utilizes the data generated from
the previous tasks to perform overall subsystem activities for the solution of engineering problems.
Both tasks utilize Program QQICEX3, the internal
controlling ICES executive. For the engineer setting
up a subsystem, the ICES Executive program will
process and store Command Definition Language
programs. For the engineer using ICES in a problem
solving mode, the ICES Executive program will
Integrated Computer Aided Design Systems
process Problem Oriented Language commands as well
as control input/output, secondary storage file management, core memory allocation, and program loading of
subsystem load modules and command definition
dictionaries.
The POL Execution sequence starts with the initialization of the ICES Executive program. This interrogates
the input data for the existence of POL commands. If
there are no commands, the program terminates. If
commands are present in the input data, the ICES
Executive calls the Command Interpreter and an appropriate Subsystem Command Definition Block
(CDB) and Dictionary. When a POL command is not
defined in the CDB, a POL error is given by the ICES
Executive program. If the POL statement is a valid
command, an appropriate Command Definition Language program is directed to extract problem data from
the POL command. Unless errors occur in the data or
data identifiers, the ICES Executive directs further
processing of the Command Definition Language program which may include either more CDB's or the
execution of CDL designated ICETRAN programs.
When an ICETRAN program is performed, engineering
results are calculated and tabulated for engineering
analysis. At this point, the ICES Executive can either
process more CDB programs or more ICETRAN programs; or return to process subsequent POL commands.
After all POL commands have been processed, the
ICES Executive terminates the specific problem
solution.
It can be readily seen that there is no limit to the
number of subsystems that can be executed. Each subsystem is started when the POL contains a system
command that specifies the subsystem name. The
presence of this command causes the previous subsystem, if any, to be closed and the specified subsystem
to be processed hy the ICES Executive program. The
case of anyone computer run is specified by the system
command FINISH, which causes the last subsystem
to be closed, as well as the ICES system itself. Thus,
for the first time, an integrated system concept is
evolving for the solution of engineering problems as
complete discipline, rather than the present scheme of
disassociated, fragmented computer programs.
APPENDIX B
THE ECAPNC PROBLEM ORIENTED
LANGUAGE
Initial results from a generalized study of ECAP indicated that the Problem Oriented Language design
should be similar in format to the original ECAP input
305
language. This was advantageous for two reasons:
1. The POL design would utilize existing ECAP
language notation for the identification of electronic circuit data. Thus, most of the data
identifier information required in the design of
the ECAPNC Command Definition Language
programs was readily determined.
3. The instruction of engineers in the use of
ECAPNC would not be substantially different
than that of the original input language. Also,
since ECAP is a widely used circuit analysis
program, engineers already familiar with ECAP
could easily convert to ECAPNC.
Based on the previous design criteria, the POL
design was developed to incorporate all existing ECAP
problem statements while satisfying related design
constraints imposed by the design of the CDL and
ICETRAN programs.
The completed design provides a detailed summary
of usage instructions for the engineer utilizing the
ECAPNC subsystem for DC circuit analysis.
BASIC COMMAND NOTATION
The engineer communicates problem data to the
circuit analysis subsystem through a POL program consisting of a series of statements known as Commands.
Each command utilizes the following two types of
elements:
1. Alphanumeric words that are used as labels for
commands, command modifiers, and data
identifiers.
2. Integer or decimal numbers that make up the
engineering problem data.
The alphanumeric words or single letters identify the
command statements according to the rules set forth
in the design of the ECAPNC Command Definition
Language. Each word in a command statement uniquely
specifies the problem data with respect to engineering
terminology. Usually the first word in the statement
defines the command, and subsequent words further
describe and label the type of data required for problem
solution. It is also emphasized that in addition to
supplying problem data, the command words can instruct the subsystem to perform calculations on data
specified in previous command statements.
After appropriately identifying the engineering
306
Fall Joint Computer Conference, 1970
problem data, it must be specified in the following data
modes:
1. Integer data
These are numbers that do not contain a decimal
point, or commas.
Examples: 1 38 -1000 + 10000
Note: If the sign is omitted, it is assumed
positive (+).
The command notation for integer data is given
by in, where n is a subscript that uniquely
identifies integer data within a command
statement.
2. Decimal data
These numbers must contain a decimal point,
but no commas. There are two basic types of
decimal numbers, normal and exponential. The
normal decimals consist of digits preceded by
an optional sign.
Examples: 1.0 38. -1000. + 10000.
The exponential numbers are decimals multiplied
by the power of ten. Th~y have the form of a
decimal, but are followed by the letter E and a
signed or unsigned integer representing the
power of ten.
Examples: 10.E -1 3.8E1 -1.0E3 + 10E3
The command notation for decimal data is
given by Vn , where n is a subscript that uniquely
identifies decimal data within a command
statement.
The command text is now defined as the logical
meaning and ordering of the command elements
(alphameric words, and integer or decimal numbers).
For convenience and simplicity, the meaning and ordering of the command text is abbreviated through the
use of special symbols such as underlines , braces,
parentheses, and brackets. The following abbreviations
are summarized for subsequent reference:
1. Underlines are used to indicate the required
portion of an alphanumeric word in a command
statement. For example, if the word INCREMENT is used in a command, the engineer need
only give the letters INCR or any other word
starting with these letters such as INCREASE.
2. Braces are used to indicate that a choice exists
among the enclosed elements in the command
text.
Example:
rSENSITIVITY 1
~ WORST
~
lSTANDARD
J
The engineer may choose one of the three words
within this command statement.
3. Parentheses are used to indicate that certain
words may be omitted in the command text.
Example:
DC (SOLUTION)
The engineer can specify the DC solution to a
problem and add the word SOLUTION if
clarity is desired. It is noted that if parentheses
enclose the example for braces, the entire set of
elements may be omitted.
4. Brackets are used to indicate' the alphanumeric
words that are used as labels for integer or
decimal data.
Example:
[BRANCH] i 1 [NODES]
i2
ia
It is ~~ted that an internal ICES programming
capabIlIty allows the engineer to omit the labels
and just insert the data in the order specified by
the subscripts, or to give the data any order
provided that they are labeled.
Example:
[~ODES]
i2
ia
[BRANCH]
i1
In the last example, it should be emphasized
that i2 and ia are a group of related data with
the common label of NODES. Thus, this capability stipulates that problem data may be
given in any order within the command text
provided that the data is labeled.
In essence, then, the POL command text consists of
alphanumeric words that define commands and label
data in conjunction with special symbols that specify
the language order and meaning.
GENERAL COMMANDS FOR THE ECAPNC
SUBSYSTEM
The design of the ECAPNC Problem Oriented Language is organized into nine separate commands. Each
command performs a unique function in the overall
problem solution. For instance, some commands
specify certain types of electronic circuit data while
others dictate the type of analysis that must be performed on the specified data. This section provides a
detailed explanation of all POL commands used in
describing electronic circuit analysis problems to the
ECAPNC subsystem.
The Problem Oriented Language for the ECAPNC
Integrated Computer Aided Design Systems
subsystem is summarized by the following command
names:
1. Subsystem Specification (ECAPNC)
2. Solution Specification (DC)
3. Analysis Specification (SENSITIVITY,
WORST CASE, STANDARD DEVIATION)
4. Circuit Description (DESCRIPTION)
5. Circuit Topology (INPUT)
6. Transconductance (TRANSCONDUCTANCE)
7. Execute Print (EXECUTE)
8. Branch lVlodification (MODIFY)
9. Transconductance Modification (TMODIFY)
It should be noted that an ICES capability in the
Command Definition Language allows POL commands
3 through 6 to be specified in any order when included
between the DC and EXECUTE commands. Thus, the
POL commands are partially order-independent which
enables the engineer to formulate problem solutions
in a language environment oriented towards normal
engineering practice.
In order to add clarity to the command descriptions,
a sample electronic circuit will be used to derive problem
data. The circuit schematic diagram (Figure 9) 8 shows
the DC equivalent of a single-stage common emitter
transistor amplifier. The transistor has been replaced
at the Base, Emitter, and Collector nodes by a DC
model containing a transconductance or current gain
(Tl). The circuit is prepared for computer solution by
numbering each electrical branch (B) and corresponding electrical nodes (V). The electronic components
that make up the circuit are given their respective precalculated values.
The circuit can be described as follows: In Branch 1,
between Nodes 2 and 0 (Ground), there is a Resistor
of 2000 ohms in series with a voltage source of 20 volts;
In Branch 2, between Nodes 1 and 0, there is a Resistor
of 6000 ohms in series with a voltage source of 20 volts;
In Branch 3, between Nodes 1 and 0, there is a Resistor of 1000 ohms; In Branch 4, between Nodes 1
and 3, there is a Resistor of 350 ohms in series with a
voltage source of 0.5 volts; In Branch 5, between
Nodes 3 and 0, there is a Resistor of 500 ohms; In
Branch 6, between Nodes 2 and 3, there is a Resistor
of 11.1E3 ohms; and between Branches 4 and 6, there
is an. equivalent current gain (1Ih/ e ) of 50. This circuit
problem is now defined in a form which the ECAPNC
Problem Oriented Language can readily utilize.
The following commands are ~vailable to the engineer for communicating problem definitions to the
ECAPNC subsystem:
The subsystem Specification command specifies the
307
20v
-----1r
6000n
2N657
TRANSISTOR
EQUIVALENT
11.1K n
1000n
Figure 9-DC equivalent circuit for the single-stage common
emitter amplifier
required ELECSYS subsystem and is the first command of any problem solution.
General form:*
ECAPNC**
Example:
ECAPNC
This is the name of the subsystem (ECAP New Circuit
Analysis) that performs DC electronic circ~it a~lysis.
The Solution Specification command is used to direct
the ECAPNC subsystem to perform the nominal DC
solution. It also prepares the subsystem for subsequent
problem data, and therefore, must follow the subsystem
Specification command.
General form:
DC (SOLUTION)
* A double asterisk, **, has been used to point out differences
between ECAP and ECAPNC notation, and commands unnoted
are identical. Also, this double asterisk in not part of the command notation.
· 308
Fall Joint Computer Conference, 1970
i3-integer number representing total dependent
current sources. **
Example:
DC SOLUTION
In the example, the word SOLUTION may be
omitted from the command text. It is noted that any
number of problems may be specified in one entry of
the subsystem simply by starting each problem with
this command.
The Analysis Specification command directs the
ECAPNC subsystem to override the DC solution command and instead perform one of three available
analysis routines. However, to reach this mode, the DC
solution command must be given and followed by the
desired Analysis Specification command. Without an
Analysis command, a nominal DC solution will be
provided.
General form:
rSENSITIVITY
(ANALYSIS)
I
1
r
~ WORST (CASE)
(ANALYSIS)
lSTANDARD
(DEVIATION) )
Example:
The example shows that the subsystem is directed to
perform the Sensitivity Analysis, which is a measure of
circuit output stability when each circuit component
is subjected to a one percent variation. The Worst
Case Analysis could have been specified instead of the
Sensitivity Analysis, and allows the engineer to obtain
the minimum and maximum DC solutions assuming
linear variation in component parameters. The Standard Deviation Analysis could also have been specified
and would yield the three-sigma standard deviations
for all electrical node voltages subject to the worst
case component variations. The extreme parentheses
iIidicate that all three analyses are optional, and do not
have to be specified.
The Circuit Description command specifies the total
dimensions of the circuit topology. In the sample
problem, there are six electrical branches, three electrical nodes, and one current gain (also known as
transconductance or dependent current source).
General form:
(TOTALS)
[NODES
[BRANCHES]
'l2
DESCRIPTION TOTALS
BRANCHES 6
NODES 3
DCUR 1
The engineer must specify the number of circuit
branches and electrical nodes, otherwise, the DC solution cannot be calculated. The number of current gains
is optional since some circuits may not contain transistors requiring this modeling technique.
The Circuit Topology command is used to specify
the electrical topology (Branches and Nodes) as well
as the component parameter data. This command is
identified by the word INPUT which is followed by
sub commands of similar format in a tabular arrangement. Each subcommand represents the complete
circuit data for each of the electrical branches, and
may be given in any arbitrary order as long as all
branches are tabulated. The label ENDB is used to
signal the end of tabulated circuit branch data.
General form (Tabular):
INPUT**
SENSITIVITY
DESCRIPTION
Example:
([DCUR]
il
i3) **
where iI-integer number representing total circuit
branches, **
i2-integer number representing total circuit
nodes,**
ENDB**
Where iI-integer number identifying each electrical
branch,
i2 - integer number for the initial node of branch,
i3-integer number for the final node of branch,
VI-decimal number for nominal component
value,
v2-decimal number for worst case minimum
component value,
v3-decimal number for worst case maximum
component value,
[B]-Circuit branch label,
[N]-Circuit nodes label,
[RJ-Resistor Impedance label (data in ohms),
[G]-Resistor Admittance label (data in mhos),
[E]- Voltage source label in series with Resistor
(data in volts),
Integrated Computer Aided Design Systems
[I]-Current source label in parallel with Resistor (data in amps).
TRANSCONDUCTANCE
ENDT
INPUT
N02
NO 1
N 0 1
N 1 3
N 3 0
N 2 3
R 2000.
R 6000.
R 1000.
R 350.
R 500.
11.1E3
R
E
E
20.
20.
E -
0.5
ENDB
I t is noted that resistor component data may be
specified as impedance or admittance while independent
voltage or current sources are respectively placed in
series or parallel with the resistor.
The Transconductance command is used to specify
current gains or dependent current sources such as
those occurring in transistor models. It utilizes a
tabular format to describe problems containing more
than one transconductance.
General form (Tabular):
TRANSCONDUCTANCE**
[T] i l
Example:
T 1 B 4 6 BETA 50.
Example:
B 1
B2
B3
B4
B5
B 6
309
[~J i2 i3
([BETA] VI
i
l [GM]
(V2 V3)
I
~
VI
(V2 V
3»)
ENDT**
It is noted that the transconductance values may be
given as BETA or GM, and any number of transconductances may be specified between the TRANSCONDucTANcE command and the label ENDT.
The Execution Print command signals the end of a
problem specification and specifies the performance of
calculations by the ECAPNC subsystem as prescribed
in the Solution and Analysis commands. After the appropriate analysis has been performed, the subsystem
is ready to accept further commands.
General form:
EXECUTE (AND) (PRINT)
[NV] i l
([CA] i l
[BP] i l
[SE] i l
[CV] i l
[BA] i l
[BV] i l
[MI] i l ) **
Where iI-integer number equal to 1 (one), **
[NV]-Print Node Voltages label,
[CA]-Print Element Currents label,
[CV]-Print Element Voltages label,
[BA]-Print Branch Currents label,
[BV]-Print Branch Voltages label,
[BP]-Print Branch Power Losses label,
[SE]-Print Sensitivities label,
[MI] - Print Miscellaneous label (nodal and conductance matrices used in calculations).
Example:
EXECUTE AND PRINT
Where iI-integer number identifying each transconductance,
i 2-integer number of the "from" electrical
branch,
i3-integer number of the "to" electrical
branch,
VI-decimal number of nominal gain value,
v2-decimal number of worst case minimum gain
value,
v3-decimal number of worst case maximum gain
value,
[T]- Transconductance label,
[B]-Current gain direction ("from" and "to"
branches) label,
[BETA]-Current gain magnitude label (dimensionless),
[GM]-Current gain BETA divided by the Impedance of "from" branch (data in mhos).
NV 1 CA 1 CV 1 BA 1 BV 1 BP 1
If an output label is not followed by the integer one
(1), the corresponding output is not printed.
After the circuit has been analyzed for the steadystate solution, the previously specified circuit data can
be changed utilizing two Data Modification commands.
The first command changes circuit component values
while the second changes transconductance values.
Both commands prepare the circuit specification for reanalysis toward an optimum solution.
The Branch Modification command is used to change
impedance, admittance, voltage source, and current
source data originally specified in the INPUT command. The branch data is modified in one of two ways:
1. Discrete changes in nominal and worst case
data, or
310
Fall Joint Computer Conference, 1970
2. Incremental changes of each component value
in turn.
The command also utilizes a tabular format in which
the word MODIFY starts the tabulation and the label
ENDMB signals the end of data.
General form (Tabular):
MODIFY
( ~rn]
lmJ
{
[~J
v. (v,v,)
V4
V5 V 6
INCREMENT**
INCREMENT**
1
J
INCREMENT**
1
JJ
VI (V2 Va)
o
[~J
([IJ
lcn
V4
V5 V 6
VI (V2 Va)
v, v,v,
1
J
Example:
MODIFY
1 B 1 R 1000.
10.
3000.
INCR
ENDMB
The example shows that the Resistor in Branch one
(1) is to be modified in ten increments from a value of
1000 ohms to a value of 3000 ohms, and is the only
branch to be modified.
The Transconductance Modification command is
very similar in construction to the Branch Modification
command. In this case, the tabulation starts with the
word TMODIFY and ends with the label ENDMT.
This command also has a tabular format which can
specify either discrete or incremental changes in current gains.
.
General form (Tabular):
I
T1VIODIFY**
iI
[TJi2
(CBETA]v.
lCBETA]V'
l
(CGM]
lCGM]
( V2Va)
V5 V 6
VI ( V2V a)
V4
Vii V 6
INCREMENT"
V
JI
1I
INCREMENT**) )
ENDMB**
ENDMT**
Where iI-integer number sequentially identifying each
subcommand in the MODIFY command, **
i 2-integer number of electrical branch to be
modified,
vI-decimal number of changed nominal component value,
v2-decimal number of changed worst case component minimum value,
va-decimal number of changed ·worstcase component maximum value,
v4-decimal number of starting component value
for the increment modification,
v5-decimal number of increment steps in modification range,
v6-decimal number of final component value
for the increment modification,
[BJ-Circuit Branch label,
[R J-Resistor Impedance label (data in ohms),
[GJ-Resistor Admittance label (data in mhos),
[EJ-Voltage source label (data in volts),
[IJ-Current source label (data in amps).
Where iI-integer number sequentially identifying
each subcommand in the TMODIFY command, **
i2-integer number of transconductance to be
modified,
vI-decimal number of changed nominal gain
value,
v2-decimal number of changed worst case minimum gain value,
va-decimal number of changed worst case maximum gain value,
v4-decimal number of starting gain value for
the increment modification,
v5-decimal number of increment steps in modification range,
v6-decimal number of final gain value for the
increment modification,
[T J-Transconductance label,
[BETAJ-Current gain magnitude label (dimensionless),
Integrated Computer Aided Design Systems
311
EC.APN(;
...........................................
••
•
Jc.ES EeA'NC
•
•
"E. ~'keUIT DESIGN SU8SYSTEM
•
•
•
•
•••
•
DC ANAlYSIS
•
•••
••
•..........................................••
[GMJ-Current gain BETA divided by the impedance of "from" branch (data in mhos).
Example:
.
TMODIFY
1
T 1 BETA 60.
ENDMT
ole sou.Ji""
The example shows that the current gain is changed
from 50 in the original problem to 60 for the next
problem solution.
SUBSYSTEM RESPONSE TO POL COMMANDS
To use the ECAPNC subsystem, the engineer writes
a Problem Oriented Language program consisting of
the predefined ECAPNC subsystem commands. The
POL program represents a unique problem which
specifies electronic circuit data, analysis, and results.
Each POL program is then transcribed on standard 80
column FORTRAN coding sheets for keypunch. The
engineer can use all 80 columns of the sheet to program
commands, and should be careful to start each command name on a new line. Also, all words and numbers
must be separated by spaces within every command.
The subsystem's response to the POL commands is
given by the Nominal DC Solution which provides
the engineer with a steady-state response for a linear
lumped-parameter electronic circuit. The following
POL program illustrates a problem solution for the
circuit described in Figure 9:
cc. 1
cc.80
I",,,T
1
0
2
It
2000.
E
20.
0
1
It
oouo •
E
ZOe
.,)
1
It
1000.
N
1
1
It
l§O.
E
-O.~
d S
N
3
0
It
WO.
d b
N
Z
)
K
cl
.
8 1
N
It
&)
1l.1El
TKANSCLN.,)ucrANeE
T 1
8
It
~
BETA
50.
ENOT
~ES~RIPTION
EXECUTE
T.,)rA~S
PKINr
AND
BRANCHES
6
e. 1
ev 1
NV 1
NOO~S
til 1
)
OeUR
elV 1
1
8P 1
.... .,JOE \/l)U AlOes
haDES
1-
IfOLIAGES
3
O.2191tlZv8D 01
O.ll01210~O
02
0.226852710 01
f~AN'H VOL uc>£s
a~ANtHES
1-
it
0
5-
IIULJAC>ES
-O.l101Zl00u 02
0.22od!>2110 01
e~AN'HES
15-
ECAPNC
N
d 2
It
0
-0.219lt21080 1)1
0.880lt11200 01
-0.219lt22080 01
0.525093lftO 00
g:!!~~~:~~ g~
-0.279lt22080 01
0.256931350-01
g:!::~:::;g:g~
-0.mmOoD-02
0.73ftOS9570-Oft
0.ft93398060-01
O. 39298ftft50-01
O. TS0166950-02
0.188610630-05
g:!!:~:mg:g~
-0.219lt22060-02
0.13ftOS957D-01t
VOLTAGES
~:;~!!~~~~~ g~
DC SOLUTION
611ANtHES
INPUT
B 1
NO 2
B2 N
B3 N
B4 N
B5 N
B6 N
R
0 1 R
0
1
3
2
1
3
0
3
R
R
R
R
2000.
6000.
1000.
350.
500.
11.1E3
E
E
E -
20.
20.
1-
It
5-
I>
8RAN'HES
1-
it
5-
II
0.5
ENDB
'uRRENTS
g:!::;g::~~g~
PuWtK lUSSES
0.J98.. S333U-01
0.IOl9lit3~ 0-01
EtlAN'H 'URRENTS
eRAN'HES
1!>-
ft
6
'URIlENTS
g:::::~:::~:g~
FINISH
TRANSCONDUCTANCE
T 1 B 4 6 BETA 50.
ENDT
DESCRIPTION TOTALS BRANCHES 6
NODES 3 DCUR 1
EXECUTE AND PRINT
NV 1 BV 1 CV 1 CA 1 BP 1 BA 1
Figure lO-N ominal DC solution
This program is now ready for processing by the
ICES procedure called "Subsystem Execution." The
computer results for the Nominal DC Solution (Figure
10) are tabulated according to the circuit node voltages,
branch voltages,element voltages, element currents,
312
Fall Joint Computer Conference, 1970
element power losses, and branch currents. It is important to note that the POL program is actually a
dialogue of the engineer's commands and the computer
system's solution results. Within the program, the
engineer can specify:
1. Any number of problem solutions on one computer run as long as each solution is initiated by
a DC or MODIFY command and terminated
by an EXECUTE command.
2. Any arbitrary order of the analysis and circuit
data commands (3 through 6) when included
between the DC and EXECUTE commands.
3. Any arbitrary order of the tabulated data within
the INPUT, TRANSCONDUCTANCE, MODIFY commands as long as the data is appropriately labeled.
APPENDIX C
MODIFICATION OF ECAP
The study of ECAP as the first ELECSYS BU bsystem
began with the gathering of source information on the
external and internal program description. The capabilities of ECAP were analyzed for conversion
feasibility as determined by ICES limitations and requirements. The following results became the boundary
conditions for the ICETRAN conversion of ECAP:
1. The ECAP program has satisfied the ICES requirement specifying that engineering computer
programs must be written in FORTRAN IV,
E Level Subset;
2. The size of ECAP and time allotted for the
conversion process restricted the programming
effort to the DC Analysis portion of ECAP; and
3. The modifications will primarily consist of
adding ICETRAN subprograms for the transfer
of engineering data to the appropriate FORTRAN language variables utilized in ECAP.
The study also indicated that the design of the
ICETRAN language subprogram is subject to the concurrent designs of two other interactive data translation programs, the Command Definition Language and
the Proolem Oriented Language. In essence, then, the
design considerations in all three language programming
areas must reflect a mutual satisfaction of constraints
before the subsystem can be declared operational.
ECAP DC ANALYSIS
The ICETRAN conversion process started with the
acquisition of a disposable magnetic tape reel containing
the latest version of ECAP. Using an IBM 360/20 computer, the contents of the tape were displayed in the
form of a program listing and punched-card program
deck. The program listing yielded information on the
internal program logic and structure, while the card
deck served as the physical means of implementing
ICETRAN language modifications.
The DC Analysis card deck contained approximately
1200 FORTRAN IV source cards which were divided
into the following twelve subprograms (subroutines).
1. Subroutine ECA19-Passes control of program
from the ECAP Language
Processor (replaced by
ICES)
to
Subroutine
ECA20.
2. Subroutine ECA20-Controls processing of DC
Analysis, which includes
DC nominal solution, Sensitivity,
Worst
Case,
Standard Deviation, and
component parameter modification solution.
3. Subroutine ECA22-Calculates DC nominal solution.
4. Subroutine ECA23-Calculates DC nominal solution.
5. Subroutine ECA24-Calculates DC Nodal Impedance Matrix.
6. Subroutine ECA26-Calculates DC Nodal Conductance Matrix.
7. Subroutine ECA25-Prints calculations of DC
nominal solution.
8. Subroutine ECA27-Controls Worst Case Analysis of DC nominal solution calculations.
9. Subroutine ECA28-Calculates
Sensitivities,
and Standard Deviation;
and prints Sensitivities.
10. Subroutine ECA29-Prints Standard Deviation.
11. Subroutine ECA30-Modifies component parameter values.
12. Subroutine ECA31-Prints type of modified
component, and modified
value during a particular
interaction cycle.
I t is noted that Subroutine ECA19 is an interface
subprogram between the DC. Analysis subprograms
and a set of subprograms known as the ECAP Language
Integrated Computer Aided Design Systems
Processor. This processor program performs the same
function as the ICES data translation programs
(ICETRAN subprograms, Command Definition Language, and Problem Oriented Language), and will be
partially replaced by a newly created set of ICETRAN
subprograms.
COMPATIBILITY OF ICETRAN AND FORTRAN
The conversion process was divided into two jobs:
1. To insure compatibility between ICETRAN
statement requirements and existing ECAP
FORTRAN IV statements, and
2. To create the necessary ICETRAN subprograms for the ICES data translation function.
Both tasks require a thorough knowledge of FORTRAN, and ICETRAN before any program modifications can be undertaken.
The first job consisted of a complete inspection of all
FORTRAN language statements in the DC Analysis
program. This resulted in the modification to ICETRAN of two types of FORTRAN statements: The
Subroutine Statement, and Literal Constant Statement.
The Subroutine Statement appears as the first statement in any subroutine program. It has the following
general I CETRAN form:
313
Where v is a double precision scalar or variable name
less than six letters.
e is a set of eight or less alphameric characters set off
by apostrophes.
In ordinary FORTRAN, literal constants are defined
as decimal equivalents which are translated into a hexidecimal representation of the literal word. For example,
in Subroutine ECA28, the integer variable N J is used
to output the letter R signifying a particular circuit
component, the Resistor. The following tabulation
compares FORTRAN and ICETRAN statement:
FORTRAN NJ = -0650100672
ICETRAN NJ='R'
After ICETRAN Precompile (System Task 1)
NJ =QQHCNV( -0650100672, +1077952576)
Before ICETRAN, the appropriate decimal equivalent number for ' R' was determined by a special computer program. Now, this program is built into ICES
as a load module program, QQHCNV, and eliminates a
previous FORTRAN programming limitation.
ICETRAN CONVERSION OF ECAP
The second conversion job had to be performed in
order to satisfy the following ECAP and ICES design
limitations:
SUBROUTINE name (aI, a2, ... ,an)
Where name is the subprogram name consisting of
one to six letters or digits. The first must be a letter,
but cannot start with the letters QQ.
aI, a2, . . . , an are the subroutine arguments (variable
names) of data values used in the subprogram for
calculations.
variable arrays.
2. The ICES Command Definition Language
(CDL) rules state that data cannot be directly
translated into subscripted variable arrays.
This statement IS the same as its FORTRAN
equivalent, but, in ECAP, subroutines with arguments
were written without a space between the subprogram
name and subroutine arguments; i.e., SUBROUTINE
ECA20 (ZPRL). This is critical in I CETRAN, especially in the Load Module Generation task in Appendix
A of this paper. I t was found that five subroutines
(ECA20, ECA22, ECA24, ECA26, and ECA28) required the appropriate spacing modification to conform
with the ICETRAN statement format.
The Literal Constant Statement is unique to ICETRAN and facilitates the programming of constants
containing alphameric information. It has the following
general ICETRAN form:
In order to circumvent these design limitations with
a minimum of ECAP programming changes, a solution was devised that would utilize a set of ICETRAN
subprograms in conjunction with the Command
Definition Language to transfer circuit data from
temporary variables into the required subscripted
variables. In particular, the CDL could translate each
type of circuit data into a standard, predefined set of
temporary scalar variables. The CDL can then designate an ICETRAN subprogram to perform the final
translation of data into a unique subscripted variable
within an array. It is important to note that each subprogram is individually executed as many times as
necessary to complete an array. The first step in this
proposed method is to tabulate all ECAP data arrays
and establish a set of temporary scalar variables for
the subprogram data translation. The following tabula-
v='e'
1. All circuit data in ECAP is stored in subscripted
314
Fall Joint Computer Conference, 1970
tion describes the ECAP data arrays, the corresponding
temporary. data variables, and overall data function:
ECAP Variable
Temporary
Function
I
NUMB
Y (I)
YT
YMIN (I)
YMAX (I)
E (I)
EM IN (I)
EMAX (I)
AMP (I)
AMPMIN (I)
AMPMAX (I)
NINIT (I)
YMINT
YMAXT
ET
ET
EMAXT
AMPT
AMPMIT
AMPMAT
NINITT
NFIN (I)
NFINT
I
NUMT
YTERM (I)
YTERMT
YTERML (I)
YTERLT
YTERMH (I)
YTERHT
ICOLT (I)
ICOLTT
IROWT (I)
IROWTT
Circuit Branch
Number
Impedance (R), Admittance (G)
Minimum R, G
MaximumR, G
Voltage Source (E)
Minimum E
Maximum E
Current Source (I)
Minimum I
Maximum I
Initial Node of Circuit
Element
Final Node of Circuit
Element
Transconductance
Number
Transconductance
(BETA, or GM)
Minimum BETA, or
GM
Maximum BETA, or
GM
Transconductance
"FROM" Branch
Transconductance
"TO" Branch
To modify data within these previous arrays, the
following variables are utilized:
VFIRST (1)
VFIRTT
VSECND (I)
VSECNT
Nominal or First I teration value
Minimum or Number
of Increments
VLAST (I)
VLASTT
MOPARM (I)
MOPART
MOSTEP (I)
MOBRN (I)
MOSTET
NUl\IT
Maximum of Last Iteration value
Type of Component
(R, G, E, I, or GM)
Increment Designation
Branch or Transconductance No.
To obtain the engineering results of the DC Analysis,
the following output variables are utilized:
NPRINT (1)
NPRINT (2)
NPR1
NPR2
NPRINT (3)
NPR3
NPRINT (4)
NPR4
NPRINT (5)
NPRINT (6)
NPR5
NPR6
NPRINT (7)
NPR7
NRPINT (10)
NPR10
Prints Node Voltages
Prints Element Currents
Prints Element Voltages
Prints Branch Currents
Prints Branch Voltages
Prints Branch Power
Losses
Prints Sensitivity
Analysis
Prints Nodal Impedance and Nodal Admittance Matrices.
In summary, the ECAP DC Analysis program was converted to ICETRAN in two steps. The first step required that a compatibility study be performed to
check the language interface between ECAP FORTRAN and ICES FORTRAN (ICETRAN). It resulted in the modification of several ECAP FORTRAN
stat~ments which would have created ICES system
errors. The second step was required because of a design limitation concerning the treatment of subscripted variables in the ICES Command Definition
Language. A set of ICETRAN subprograms was developed to accomplish the final translation of circuit
data into ECAP subscripted variables. The completion
of both steps produced a permanently stored set of DC
Circuit Analysis subprograms.
Interactive graphic consoles-Environment and software
by ROBERT L. BECKER]\·1EYER
Research Laboratories, General Motors Corporation
Warren, Michigan
This environment is based on the belief that people
solving a problem using a graphic console should
determine as much of the display and execution logic as
possible. By making the programming language for
display generation and procedure logic use exactly the
communication techniques used during problem-solving
sessions, the application expert feels more at ease in a
programming situation. An additional strong aid to the
programming task is the automatic retrospective programming provided by the operating system. This allows
a console user to "capture" the solution procedure as it
evolves during his problem-solving session.
Program execution is done interpretively on an
internal structure that is, by design, amenable to change.
Most graphic console applications are "cut and try" and
highly dependent on the console user's background and
experience. The approach· and problem solution has to
be individualistic. With a flexible internal structure the
solutions can be altered many times so the final procedure is tailored by the console user.
An operating system to manage screen displays,
accept all user interrupts and supervise execution will
be described in terms of the fundamental modules within
it. This system allows data to be defined by a· new
technique called "association." Association enforces a
uniformity in communication that helps to insure
usability of new programs without much experience by
the user. And yet the system is in no way dependent on
the actual appearance of the displays or assignments of
function buttons. *. The operating system** is table
driven, allowing it to service different applications and
many consoles simultaneously without restricting the
INTRODUCTION
The usual software support for graphic consoles does not
provide system services designed for the· console user
who is a production-oriented application expert. This
paper describes a console environment and high-level
language with a supporting operating system designed
for the application expert.
The aim has been to improve four troublesome areas:
programming a new application, defining input data for
functional routines, screen management and dynamic
error recovery.
The importance and acute need for improved software
of this type is substantiated by the large number of such
systems being designed and languages proposed. RAND
Corporation is developing a programmer-oriented
graphics operation.! At the University of Utah, W. M.
Newman is working on a high-level programming
system for remote graphic terminals,2 and A. van Dam
at Brown University is working on a hypertext editing
system. 3 The list is very long.
At the G.M. Research Laboratories, experience with
the DAC system4 has enabled us to evolve a console
environment incorporating those human factors in
man-machine communication which we have found to
be best. This paper describes the principal parts of that
environment with emphasis on external appearance.
The material is divided into four main sections:
graphic console environment, programming language,
procedure execution, and operating system. The principal features of the DAC programming services and
console man-machine communication techniques will be
outlined for background information. The system
facility and console appearance for selection of values
for input data will be described and illustrated. Control
of displays and interaction with procedure* execution
will also be discussed. Procedures use console displays
for a two-way communication instrument between user
and machine.
* A function button is a key or button that may be programmed
to link to a particular computer code when pushed by the console
user. These buttons may be special keys on the alphanumeric
keyboard or collected together in a separate box on the console.
** Operating system in this paper refers not to the basic system
support like 08/360, but to a collection of routines designed to
interpret pmcedure internal structure, handle all data associated
with this structure and interpret all the console user interactions
with functional parts of the console (keyboard, function button
or light pen).
* The term procedure in this paper is a collection of computer
programs or subroutines linked with a logic structure designed
for several variations of a problem solution.
315
316
Fall Joint Computer Conference, 1970
flexibility required by the user and at the same time
keeping the operations in the different consoles
separated.
Included is a complete example illustrating the
principal parts of this environment. Although only a
small portion of the language symbols are used in the
example, those used are among the most important.
GRAPHIC CONSOLE ENVIRONMENT
Long-range objective
A seven-year study4,5 on computer graphics with
emphasis on programming efficiency has led to the
long-range objective of a more direct path.for console
users to design solutions for their problems. Many
applications have been considered including body
design, statistical analysis, information retrieval and
project planning and controL A characteristic of these
applications is that the procedures continuously change
to incorporate improvements and new approaches. For
programming efficiency, a high-level language allowing
the application expert to program in an environment
very close to that in which they solve application
problems is needed.
DAC background
ForDAC4 system programmers designed what is
called the Descriptive Geometry Language (DGL). The
DGL statement
LN7, PT8, PT9, UF2 = INLIN(SU3, Y = 20.), RG2
makes symbolic references to geometric data. It also
uses a package of functional evaluations and subroutines
to do transformations, generate new data and other
geometric operations on the data. In DAC these
subroutines are called operators. In the DGL statement
above, the INLIN operator is used to find intersections
of surfaces and lines. We take the surface SU3 and the
plane Y = 20 and form an intersection over the range
RG2. The intersection line is LN7 with end points PT8
and PT9 and the surface normal unit vector function
UF2. A large number of such operators are available to
designers. All were written by G.M. Research
mathematicians.
Designers and engineers use these operators in
statements to write a computer program or procedure.
The system then interprets these statements one by one
in an interpretive mode. The designer or engineer, when
at the console, can start and stop at any statement in
his procedure. If need be he can back up and reexecute
any number of the statements to correct or modify the
design. Graphic Displays on the DAC console screen
provide for review and evaluation of the results. We
found, however, that application specialists were not
amenable to the discipline of a written programming
language and a search for a method of defining procedures in a manner more natural to the users continued.
In the next system, groups of operators were made
available simultaneously via DAC console function
buttons (these are similar to those on the IBM 2250
function keyboard). The groups were called "overlays"5
because as each group became available, a celluloid
sheet with identifying labels for that group was placed
over the keyboard. In general, operators were grouped
by function; for example, the SURFACE overlay
operators dealt with surface definition problems. There
were eight overlays in all. The coding for these operators
was done by system programmers and required 13 to 30
man-months per overlay . Using a combination of
Descriptive Geometry Language procedures and overlays, the DAC system is now being used heavily for
production work.
Based on our experience, the next development was to
communicate with the user through pictogram 6 representations of the operators. Through considerable
experimentation with DAC-experienced users we were
led to the amalgam of proven DAC techniques and
pictogram communication which constitutes our present
console environment.
Improved console environment
The new environment provides the same operators as
were available through the function buttons of an
overlay in the previous system. The improvement is
obtained by pictorial communication between the
mathematical function routines stored internally to the
computer and the man sitting at the console who wants
to use them in a problem solution.
Screen management is carried out by dividing the
console display area into three function areas. A typical
screen format is shown in Figure 1. The upper area is
called the work area. The lower right-hand area is known
as the operator area and in some ways corresponds to the
celluloid overlay of DAC. The lower left-hand area is
known as the control area. The operating system
distinguishes between console user actions in these areas
and responds accordingly. The display in the work area
shows three parts of a design problem: a windshield
surface, some lines for the windshield wiper pattern and
Interactive Graphic Consoles
the rear view mirror subassembly. * As the design is
evolved, the modifications and additions are shown in
this area of the screen.
The operator area in Figure 1 contains only text
describing intersection operations and thus wastes
communication potential of a graphic console. Contrast
this with the operator area shown in Figure 2 where a
pictorial representation, a pictogram (6, page 384), of
the functional capabilities of the operator realizes more
of this power.
The pictograms in the operator area show three types
of geometric intersections to determining an intersection
point. These illustrations, if well done, have a "universality" that will transcend the limitations of the
prose equivalent shown in Figure 1. The differences
between these types of intersections and the geometric
elements involved is readily understood by those trained
in elementary geometry regardless of the way in which
they express the concept, as a mathematician or
designer. Consider the problem of designing a tool used
for automobile body panels called a die shoe and having
people from different departments working on problems
related to making this die shoe. Different jargon may be
used by the departments, but all persons will recognize
a blueprint or stylized drawing (or pictogram) of this
part. A simplification of the drawing of this part with
emphasis on the possible design operations can be shown
+
INTERSECTION POINT OPERATOR
Proceed
MrNe Up
Exit
Sign Off
SELECT TWO
SKEW LINES
SELECT A LINE
AND SURFACE
LINE I
LINE
II NE 2
SURFACE
Figure 1-Display area format
* A subassembly is the automobile body designer's term for a
detail drawing of a subpart of a major assembly. For example,
a door lock subassembly of the door panel.
317
+
PrOCeed
Move Up
Exit
Sign Off
Figure 2-External appearance of a graphic operator
in the operator area and the operator will be a useful
tool for people in any of the involved departments.
In the control area there are four possible controls.
The console user transmits his wishes for display control
and execution interruption to the operating system
through this area. Use of the three functional areas is
described in more detail below.
Suppose the user wished to find the intersection of a
surface and a line. These two parameters are indicated
in the center pictogram which represents this operation.
The user must supply the values for the parameters
from the work area display, however. The order in
which the values are defined is arbitrary. The user
starts by selecting with the light pen either the surface
or the line in the middle pictogram. This first selection
tells the system two things, which type of intersection is
to be calculated and which parameter is to be supplied
first.
The choice of parameters is done by associating each
stylized parameter in the pictogram with an actual
counterpart in the work area, using the light pen to
indicate the two members of the correspondence. The
first part of the association is made in the pictogram
allowing the system to limit the user's choice in the work
area to elements of compatible type. This prevents such
erroneous associations as a line parameter with a surface
element. This error prevention is done using the
technique of selective enabling described below. As soon
as all the parameters for the computation have been
defined, the system calls the appropriate subroutine
passing the work area line and surface chosen by the
318
Fall Joint Computer Conference, 1970
user. If mathematically possible, the subroutine computes the intersection and passes the intersection point
back to the operator for display in the work area of the
screen.
At any time prior to the completion of parameter
definition and the subroutine call, the user may redefine
any of the data values by a simple reassociation. He first
selects the parameter in the pictogram that is to be
redefined and the system prepares to override the work
area data choice made earlier. The user's second
selection of a work area item completes the parameter
redefinition.
In the windshield example, the user might associate
the line parameter in the pictogram with the center line
of the rear view mirror and the surface parameter with
the windshield surface. The windshield surface is
selected by placing the light pen over any part of the
boundary lines of the windshield.
The light pen selections make use of both selective
enabling and reactive displays.7 On display in the work
area of the example are lines, surfaces and points. The
operator can cause the system to enable fOl"'selection
lines only, points only, surfaces only or any combination.
This selective enabling is controlled by information
stored with each parameter in the operator and passed
to the system when the user selects a parameter in a
pictogram. All attempts to select items which are not
enabled are ignored. Selective enabling is not used in the
operator area display; all parameter representations in
this area are always enabled, allowing the user to
respecify parameters should he make an error.
The reactive display technique allows the user to
ensure that the intended element is being selected. This
is particularly important in crowded parts of the work
area where elements are close together. When a light pen
is over an enabled item, it is intensified and will remain
so until it is selected by removal of the pen from the
screen or until the pen is moved away from the item.
The user may thus adjust the position of the pen on the
screen until the correct element is intensified and then
make his selection. As a further aid to the user, only
enabled items are intensified.
The words on display in the control area represent
functions which can be executed independently of the
current operator and of the function being performed by
the operator. For instance, if the user selects "lVrOVE
UP," the operator is interrupted and the items on
display in the work area are shifted or translated up
some predetermined distance.
If an error occurs while using any operator, an
appropriate message can be put on display in the
operator area and the entire interpretation of the
operator will stop until the user acknowledges the error
with the light pen. Thus he has an opportunity to take
some immediate corrective action and continue. Response to an error might involve a change to a parameter
value and reexecution of that part of the operator or the
current operator may be pushed down and another
operator called up to generate new data. This new data
may then be used to replace some parameter value that
caused the error condition. The operator may also be
programmed to open an auxiliary path allowing the
user to supply extra data needed to overcome the error
condition. The system can provide some standard error
escapes, but the operator can be programmed to have
almost an unlimited variety of error recovery paths
dynamically selectable by the user.
With the same operating system supporting all
applications for screen management and interrupt
processing, data selection by association becomes paramount and can be fine-tuned giving the console user
good response to his requests. All operators have a
similar internal structure: an APL8 structure generated
by APL statements within a system module from the
graphic operator source program. This structure is
illustrated for the example in Figure 2 later in the paper.
With similar internal structures a more uniform approach to the console environment can be assured.
Uniformity is important because any departure from a
conventional course of action is a distraction for the
user. This became evident while observing DAC users
working in the overlay environment. Each overlay was
considered an experiment in human factors so the
standard course of action varied from overlay to overlay
and resulted in confusion for the user when switching
overlays.
OPERATOR PROGRAlVLLvIING LANGUAGE
Operator programming
The operator in the previous example has shown that
an operator must be able to present displays in the
operator area and associate each parameter of the
operator with the data selected by the console user. An
operator must also be able to invoke subroutines and
other operators, display the output from a subroutine
call, and give the console user the ability to select
alternative ways to solve his problem. The flow of logic
in an operator is such that a subroutine will not be
called until all its parameters have been given values.
As soon as the last parameter receives its value the
subroutine is called. The user has freedom of choice
of the order in which he specifies parameters,. thus he
may define values for the parameters of several subroutines in a mingled sequence. For this reason the order
Interactive Graphic Consoles
in which the statements of an operator will be executed
is indeterminate at the time of programming. This
contrasts with the usual type of program where
statements are executed in strict sequence except for
branching. The language used to program operators
must not only provide for simultaneous flow of data and
logic, but must allow an operator to begin execution at
almost any statement. Once the initial display for an
operator is made in the operator area, the user's selection
of the available parameters determines where the
operating system starts operator interpretation.
+
Graphical operator language and representation
Proceed
Move Up
The illustration of Figure 3 shows both the graphic
operator interface (operator picture) as before and a
graphic representation of the operator program, the
programmer's view of the operator. This program
representation is called a logic diagram since it describes
the logic flow of the operator. It is the programmer's
source program and is never shown to the console user
in an application problem-solving situation; however,
since operators are programmed at the screen in the
same way in which the application user solves his
problem, this diagram forms the work area display for
the operator programmer. The programming language
for operators is really a set of operators which add
symbols to the logic diagram and build the structure
to be used by the interpreter during execution. In
Figure 3 dashed lines show the connection between
symbols in the diagram that represent data parameters
and their graphic display representation in the operator
area.
This operator consists of three alternative waYil of
generating an intersection point. Each alternative is
shown as a horizontal line of symbols and ends with an
X symbol. Each line of symbols is referred to as an
alternative path. The upper path, represented in the
operator picture by the left illustration, covers the case
of intersecting two skew lines, and is made up of two AS
symbols, a CL and a DS symbol. The middle path
represents an intersection of a line and surface and the
lower path the intersection of two straight lines. The
three alternative paths are joined by a vertical line to
the AL or alternative symbol. With the AL symbol the
console user is free to select the intersection construction
that fits his needs for the problem at hand. Anyone of
the parameters may be selected to start the operator
and this selection will determine which alternative is to
be used.
In the first alternative path, the AS symbol representing a data parameter denotes a data association as
described above. Part of the information stored with
Exit
Sign Off
I NTPT
I
+
(iJiJ*
I
~
_____ ,
,
\
'
,
I
~-
319
I
I
L--OO-AL~I
01
I
I
\
I
\
I
I
\
\
,
\
I
,
,
,
,
I
\
'
'
,
,
'
I
I
,
102 031 : 09 ,
AS--AS-+CL-,-, os ~
02
03,09"
I
(X)
"
I I
0405 (X)
I
10
OO---AS-AS~AS--, CL-OS~
04
~/ (X)
10
I
",/ 0708 I 11
.----AS--AS....- - C l - ' DS~
07'"
08
11/
" .......
__ .... ' '"
Figure 3-Example operator
this symbol is a data-type used for selective enabling.
The number 02 below the AS is called a data code. The
data code is no different from a conventional parameter
name except it is a more compact way to display the
parameter. If the parameter name is desired, it can be
displayed along with data declarations and all other
information about the symbol. The data code also
represents an index into the data table (Figure 5) used
at execution time to store the data values assigned to
each parameter in the operator. If a complete parameter
cross reference is desired that data code may be selected
and all references' to that parameter will be shown by
intensifying all diagram symbols using that parameter.
The data code number is a sequence of numbers
generated by the system and assigned to symbols
requiring a data code as they are added to the diagram
by the programmer.
The third symbol, a CL symbol, represents a subroutine call. The subroutine name is stored internally
with the symbol and may be displayed if requested by
the user. The data code 02 from the first symbol and
data code 03 from the second symbol are shown above
the CL. This shows 02 and 03 to be input items for the
320
Fall Joint Computer Conference, 1970
CL. Below the CL in the first path is data code 09. This
is the output data, the intersection point, from the
subroutine.
The DS symbol, next on the first alternative path,
means that a display of a computed data item is to be
made in the work area. Data code 09 above the DS
symbol indicates that this parameter is to be displayed.
All symbols in the logic diagram are interconnected
by a solid line. To follow this line from symbol to symbol
will show a logic flow within the operator. A sequence of
interconnected symbols will end 'with an X symbol
representing a path end. The two AS symbols, the CL
and DS symbol of the first path are interconnected and
terminated with the X signifying a complete path for
one choice of the alternative. When the X is reached the
logic flow returns to the next higher level and continues.
An X symbol on the highest level path terminates the
operator. The logic diagram differs from the standard
flow chart in that a path of symbols has level significance
and the logic flow automatically moves to the next
higher level when the path end is reached. An operator
logic diagram also has a larger set of symbols than the
average flow chart has kinds of polygons.
Further explanation of the alternative CAL) symbol
can now be given. It is possible to make displayed items
a part of more than one illustration, but regrettably,
this is not demonstrated in the example. There must be
at least one unique item to each AL path to allow the
system to determine which alternative the user intends
to use from the selection of a unique combination of
items. The unwanted alternatives are removed from the
operator picture area, further aiding the user by
deleting possible erroneous choices. The remaining
pictogram can then be enriched by additional required
parameters of lesser importance. This is shown in the
example by the OD, operator display, in the middle AL
path.
The OD symbol allows the programmer to determine
the composition of the operator area. Operators may
have one or more operator pictures and additions may
be made to the current picture. The OD symbol serves
both of these functions. Any OD on the principal or
highest level path means that the current picture is to be
wiped out and a new composition begins. An OD serving
this function is shown in the example immediately after
the name INTPT. The second OD in the example on the
middle alternative path shows the second function of an
OD. This OD is a tolerance value, unimportant to the
user of the operator until that path is chosen so the
display for that parameter is held back until needed.
The name symbol, INTPT in the example, is the
initializer for the operator containing required limits
and constants.
The Operator Programming Language Compiler
allows the programmer to start building up the logic
diagram in the work area symbol by symbol. At any
desired time, the logic diagram can be shifted to the
operator area and an operator picture built up in the
work area. Light pen associations between diagram
symbols and items on display in the work area build up
the operator graphic interface. There are many sources
for displays that may become parts of operator pictures
including a picture library, digitizing physical models,
parts of work area displays resulting from a design
session and a sketchpad facility.
The operator programmer can make rapid and
frequent changes to his operators. The display for the
operator picture can be altered in any way and any
change desired can be made to the logic diagrams. The
language compiler will automatically update the internal
structure to reflect the changes.
The operators can be executed with a minimum of the
logic diagram programmed so it can be built "cut and
try." Our DAC experience shows that this is much
faster for this type of work than a conventional
procedural language that requires careful preplanning
of all logic and all too often complete rewriting to
incorporate modifications.
PROCEDURE EXECUTION
Interpretive execution
A module of the operating system called the Executor
proceeds from symbol to symbol performing the
execution as in conventional interpreters. 1\1ajor symbols
like NAlVIE, OD, AL, AS and CL each have subroutines to perform all the functions required. In this
example, the NAME processor sets up tables that drive
the operating system. These are illustrated in Figure 5
and discussed briefly in the operating system section.
After initialization the OD module is called. This
clears the operator area display and searches the
operator structure for symbols with displays, e.g., an
AS symbol. The display information is built up until
another OD symbol is found or the lowest path end
comes up. The picture is then painted on the screen. In
the example the operator picture would be painted as
shown in Figure 2.
Suggesied inpui sequence
In our example the next symbol is the AL and the
suggested input sequence scheme comes into play. This
is a prompting mechanism to aid the user with an
unfamiliar operator and also to reduce the number of
Interactive Graphic Consoles
light pen selections that must be made. Its real function
is to make the first selection of each association for the
user. The first path of the AL and the first AS (with data
code 02 below) is suggested. Externally, the line in the
pictogram corresponding to that AS is intensified,
selective enabling is set up based on the data type stored
with the AS symbol, and the system waits for the user's
work area light pen selection to complete the association.
However, all other parameters in the work area remain
enabled and the user may override the suggestion. The
suggested input sequence is then interrupted by
selecting the parameter he requires. If this changes AL
paths the selected path is used for suggestion, otherwise
the system reverts to where the sequence was interrupted. In the windshield design example above, where
we suggested the operator was used to intersect the rear
view mirror center line with the windshield surface, the
first selection of the line in the middle pictogram of the
operator picture would be an interruption to the
suggested input sequence. The sequence would be
shifted from the upper path of the AL to the middle
path. The suggested input sequence is determined
entirely by programming, according to the order of
symbols in the logic structure. The CL, call, symbol
causes the Executor to check whether all parameters
required for the call have been given values so that the
subroutine may be called.
The CL symbol has a feature not available for
standard subroutine calls. It may be designated as
"once only" or "continuous" execution. The "once only"
form is the standard subroutine call but "continuous"
means that as long as anyone input parameter is
continually being given a new data value the subroutine
will continue to be reexecuted allowing a dynamic
change to an affected part of the design in the work
picture. This allows the user to make many small
adjustments to his work picture and monitor the result.
Operator internal structure
A portion of the internal APL structure and corresponding logic diagram is shown in Figure 4. The
language compiler, as directed by the logic diagram
built by the programmer, generates the internal structure by executing APL9 statements.
The structure is composed of blocks of information or
entities and sets of entities with at least one kind of
entity for each symbol in the language. The entities can
be connected together into a set by internal pointers to
the next entity and to the previous entity in the set.
Entities may be members of one or more sets. There is
an entity type corresponding to each symbol type in the
operator logic diagrams.
321
INTPT
LOD--Al~
OIr-
02 03
09
AS--AS--. Cl--DS~
02
03
09
1
1--I
I
Figure 4-Internal APL structure
There are many ways an operator structure may be
modified. The entities can be changed, deleted or hooked
up in sets in various ways. These are local structure
changes with the advantage that they do not require
regeneration of the rest of the structure.
In the example of Figure 4, the logic diagram symbols
are each translated to an entity type in the internal
structure while logic flow and data flow determine the
set connections. Connected to the AL entity are its
three alternative paths and· most of the entities for the
intersection of skew lines path are shown. Also shown in
Figure 4 are two node blocks which serve to connect the
DATA entity (data code 09) to a set in the CL entity
and another set, but with the same set name, in the DS
entity. 9
Hierarchical program structures
A very important symbol not shown in the example
allows an existing operator to become a substructure to
a higher level new structure being programmed. It is the
primitive operator or PO symbol. An existing structure,
when included in _another structure, is a lower hierarchical structure and therefore primitive relative to
the higher level structure. The PO is like an external
subroutine with procedural language programs. This
means any operator structure can become a substructure
to another operator's structure. Large complicated
322
Fall Joint Computer Conference, 1970
Initializer
Tables:
Control tnfor~ation1
Data Type
Operator
Physical Screen Area
Executor
Figure 5-Console operating system modules
structures can be built up in modular fashion from small
simple structures.
A utomatic retrospective programming
As a problem is being solved using operator after
operator, the operating system can be told to keep a
history trace, i.e., to "capture" the procedure. The
system builds a simple structure and generates a new
PO symbol in that structure for each new operator as it
is called. The system tables generated for executionlO of
that operator are saved with the PO. When this simple
structure is complete, just a string of PO symbols, it is
modifiable in all the standard ways for operator logic
diagram generation and modification. Thus a new
operator is generated without programming a logic
structure, symbol by symbol, in the standard way. The
new operator as a simple linking of existing structures
was automatically generated by the system from the
history trace that was kept. It is retrospective in showing all steps to the new procedure including all data used
as input and even the false starts that were abandoned.
CONSOLE OPERATING SYSTEM
System modules and driver tables
The interpretive processing of the operator internal
structures is done by system modules driven by two
groups of tables as shown in Figure 5. One group of
tables contains information concerning a particular
application, screen formatting, data types, graphic
orders for control area display, function button
assignments, etc. This information remains constant
during execution and thus these tables augmenting all
the individual operator structures may be shared
between a number of consoles working on the same
application. The second group contains information
about the individual console user and the current
operator being executed. The use of a standard set of
system modules which are controlled by tables allows an
application to be tailored to its particular needs. At the
same time a uniform approach to the environment is
enforced. People working in a particular application are
never "surprised" by the kinds of reactions that are
expected from them in using their operators just
because some operator programmer wished for notoriety
by giving his operators a unique set of conventions.
The initializer allocates and initializes the tables
universal to an application. This initialization information is supplied by a programmer using one of the
programming operators. Different initializing information is called in if a switch is made from one application
to another. The control information table determines
the control area display. The data-type table indicates
types of data to be permitted when setting up for
selective enabling for an association. The physical
screen area table formats the screen into work area,
operator area and control area. The operator table
builds up a list of operators used when the user requests
automatic retrospective programming.
The name processor starts interpretation of a
particular operator. The tables it keeps are for the
current operator only. They are saved if a history is
being kept, but otherwise freed when the operator is
completed.
The executor module carries the structure interpretingalong from symbol to symbol. It determines
from the entity encountered what processor to call. If a
user steps out of the suggested input sequence, the
executor must make the change in logic flow and then,
when the association is completed, revert to the
suggested input sequence.
PROJECT DEVELOPlVIENT STATUS AND
PLANS
An experimental implementation of the key system
modules and major symbol processors has been made for
the IBIVI 360/67, a paged time-shared machine, with
several 2250 III graphic consoles attached. Positive
results were shown for the proposed internal structure
Interactive Graphic Consoles
for operators and system management of the three
functional areas of the screen.
Further development for the operator programming
language is in progress. The power of the language needs
to be increased to include dynamic expressions for the
console user while in a problem-solving mode. These are
basic arithmetic expressions on numerical data. A higher
level expression permitting application defined expressions on the application dependent variables is also
under consideration. An example of the higher level
expression is the automatic calling up by the system of
the two skew line intersection point operator when a
point item is needed as data and the console user has
just selected two skew lines. lVlore development for the
automatic retrospective programming facility is also
planned.
SU1VIl\1ARY
The treatment of design problems at a graphic console
demands communication between man and machine in
a manner which is natural to the user so that he may
concentrate on finding application problem solutions.
This type of interaction can be achieved by presenting
the user with pictograms symbolizing concepts and
allowing him to select data by making an association
between elements of the pictogram and items of the
work picture.
Through selective enabling and reactive displays the
number of erroneous selections can be greatly reduced.
Since data selections may take place in any order, the
operators which manipulate the data differ from normal
programs in that the statements are not executed in a
predetermined order.
The programming of these operators is done in the
same graphic environment as application problem
solving using the same operator techniques. Through a
recording technique the sequence of operations at a
console may be captured and used as new operators.
The operating system will manage three functional
areas of the screen and permit extensive user interaction
with the system to control problem execution and the
screen displays. A uniformity of environment can be
achieved throughout all the programs of an application
that will make the user more at ease and minimize
learning to use new programs.
323
ACKNOWLEDGl\1ENTS
The techniques and ideas presented in this paper have
been developed over a period of time at Generall\10tors
Research Laboratories as a cooperative effort of many
people working on DAC I and successor projects.
I thaIlk l\1ichael l\1arcotty for his assistance in the
preparation of the material for this paper.
REFERENCES
1 B W BOEM et al
POGO: Programmer-Oriented Graphics Operation
Proc of the Fall Joint Computer Conference Vol 34 pp
321-330 AFIPS Press Montvale New Jersey 1969
2 W M NEWMAN
A high-level programming system for a remote time-shared
graphics terminal
Conference on Computer Graphics University of Illinois
Urbana Illinois April 1969
3 A VAN DAM
Hypertex editing system for the /360
Conference on Computer Graphics University of Illinois
Urbana Illinois April 1969
4 E L JACKS
A laboratory for the study of graphical man-machine
communication
Proc of the Fall Joint Computer Conference Vol 26
pp 343-350 Spartan Books Baltimore Maryland 1964
5 B HARGREAVES et al
I mage processing hardware for a man-machine graphical
communication system
Proc of the Fall Joint Computer Conference Vol 26
pp 363-386 Spartan Books Baltimore Maryland 1964
6 P A KOLERS
Some formal characteristics of pictograms
American Scientist Vol 57 No 3 pp 348-363 1969
7 J D JOYCE M J CIANCIOLO
Reactive displays: improving man-machine communication
Proc of the Fall Joint Computer Conference Vol 31
pp 713-721 Thompson Book Company Washington DC
1967
8 G G DODD
AP~A language for associative data handling in PL/I
Proc of the Fall Joint Computer Conference Vol 29
pp 677-684 Spartan Books Washington D C 1966
9 G G DODD
AP~ Associative programming language user's manual
Research Publication GMR 622 General Motors
Corporation Warren Michigan
10 G G DODD
Associative information techniques
Associative Aspects of Problem Solving p 51
American Elsevier Publishing Company Inc
New York New York 1970
MDS-A unique project in computerassisted mathematics
by ROLFE H. NEWTON and PAUL W. VONHOF
Rochester Institute of Technology
Rochester, New York
INTRODUCTION-A
But it is in preparing the NTID student for participation in regular RIT classes that the most interesting problems occur. The problem most directly
related to pedagogy is inadequacy of educational
background. The educational backgrounds of incoming
NTID students generaIIy contain serious deficits in
the information, skiIIs, and attitudes necessary to
success in degree programs at RIT. It is the responsibility of NTID to rectify such instructional shortcomings before the deaf student is exposed to the RIT
classroom. The responsibility for filling gaps in the
student's secondary education falls to the NTID
Vestibule Program. The project described in this article
was done by the Computer Assisted Instruction Section of NTID in support of the Vestibule Program.
But how did the remediation of instructional deficiencies become a project in computer-assisted instruction? What special characteristics of the needs
of NTID' students make them susceptive to fulfillment
by computer-assisted instruction? What special attributes does the computer have that justifies its use
in the diagnosis and treatment of ailing educational
backgrounds?
Initially, the answers to these questions will be
given in general terms. First let us say that the remediation of instructional deficiencies became a CAl
project because (1) the nature of the problem seemed
appropriate to solution by computer, and (2) money
had been included in the budget for such an activity.
If the solution of an educational problem is to be
appropriate to the computer, the problem should be
complex enough that its solution requires the computer's capacity for easily manipulating large blocks
of data. In particular, the problem should need to
apply the computer's almost infinite capability for
conditional branching-the ability to sift, winnow,
and select output data-that depend on the nature
of the input. (For example, the computer can pre-
MATHEMATICS
DIAGNOSTIC SYSTEM?!!!
In the education of the deaf, are there problems so
special that their solution justifies the use of a computer? And if there are such problems, how can the
computer best be used to solve them? Early in the
history of the National Technical Institute for the
Deaf, its administrators voted "Yes" on the first
question and "Let's find out" on the second; As a
result of these decisions, an IBM 1500 Instructional
System was included in the Institute's original home
on the campus of the Rochester Institute of Technology.
The National Technical Institute for the Deaf
(NTID), is the only institution devoted exclusively
to education of the deaf in technical and scientific
studies beyond the secondary level. The NTID is
a division of the Rochester Institute of Technology,
and NTID students studying at the degree-level attend
classes that are predominately populated by "hearing"
students, students without an aural impairment. RIT
is justly proud of its status as the only conventional
"hearing" campus in the nation to educate large
numbers of deaf students.
There are, of course, special problems associated
with providing the means by which the deaf student
can adapt to the environment of the conventional
classroom. The instructor's lectures, inaudible to the
deaf student, must be made meaningful by the use of
interpreters and tutoring. The instructor must receive training in the consideration of the special needs
of the deaf. Hearing students volunteer to make their
lecture-notes available to the deaf by means of special
self-duplicating notebooks. These are some of the devices that work toward placing the deaf degree-candidate on an equal basis with his hearing coIIeague.
325
326
Fall Joint Computer Conference, 1970
scribe appropriate instruction if the student's answer
to a question indicated the need for such instruction.
A different response to the same question might
"branch" the student to a different remedial sequence
on the same topic or to a new topic, depending on the
correctness of the response.) It is, however, inappropriate to use the computer unless the computer is
needed.
The implication of this stipulation that the computer's data-handling capability be needed is that it
is usually not appropriate to use CAl unless there
is great need for the program to adapt itself to a
highly disparate set of individual needs. A situation
appropriate to use of CAl might be one in which the
subject area is inordinately broad and/or the educational backgrounds of students are extremely diverse.
Such a set of conditions exists among students entering the NTID. Probably the most prevalent instructional deficiencies are within the subject-area
of pre-college mathematics. IVlany students display
serious shortcomings in this area of study so vitally
important to success in scientific and technical subjects. But, in any large group of students, the defects
generally appear over the entire range of the subject
from arithmetic to analytic geometry, with no means
of predicting what deficiencies any individual will
display. When the range of potential deficiency encompasses the entire mathematics curriculum from
grades 8 through 12, the problem of ferreting out specific
lacks in the mathematical background of any individual student is formidable. General review of
topic-areas over a range as broad as the secondary
mathematics curriculum is too time-consuming and
inefficient to be practical. Therefore, the diagnosis
of problem-areas must pin-point all the specific bottlenecks in the mathematics behavior of each individual
student. The objective of such a precise diagnosis
is that the resulting remedial instruction will encourage the student to acquire all the missing learning
behaviors and only those behaviors that are truly
missing from his behavioral repertoire. The result
of such a program is that the student works full-time
in areas of deficiency and is never exposed to material
in which he has demonstrated proficiency.
Achieving this goal under the conditions described
in preceding paragraphs is a task that is peculiarly
appropriate to the unique capabilities of a computerbased education system. So the first task assigned to
the CAl Section of NTID was to design an instructional
system that would diagnose and remediate defects
in the mathematical backgrounds of incoming and
prospective NTID students. The instructional program
by which we are pinpointing defects in the skills that
comprise secondary mathematics has been. named a
Mathematics Diagnostic System (MDS).
This article not only describes the rationale, design,
and structure of the MDS, but also provides some
insight into its historical and philosophical aspects.
The article also contains evaluative information and
conclusions resulting from the first field tests.
The next few paragraphs very briefly describe the
events that led to the creation and utilization of our
J\t{athematics Diagnostic System (MDS).
HISTORY
With the passage of Public Law 89-36 in 1965, the
National Technical Institute for the Deaf came into
being. By 1968 the Rochester Institute of Technology
had been chosen as its home, and a small cadre of key
faculty-staff personnel became the organizational
nucleus. The Applied Science Building was designated
the location for NTID until permanent housing could
be completed. June, 1968, brought the appointment of
a director for the as yet nonexistent CAl Section of
the NTID. In July, 1968, IBM representatives installed the IBJ\t{ 1500 Instructional System. Between
July and September of 1968, technically-oriented people
joined the section, and by October, 1968, there were,
in addition to the director, an operations manager, a
systems programmer, a computer operator, and a
keypunch operator.
By November of 1968, RIT and NTID faculty
members were trying their hands at writing instructional programs for CAl, and student-assistants were
translating these programs into a computer language
called Coursewriter II. Lacking mediation by trained
CAl course development personnel, this method of
producing CAl materials proved to be not entirely
satisfactory. As yet there were no CAl course development people on board.
Meanwhile, in July, at about the same time the
1500 System was being installed, steps were being
taken that would eventuate in the Mathematics
Diagnostic System (MDS). Once secondary mathematics was identified as an area of study appropriate to
the computer, Dr. Robert L. Gering, then director
of the CAl project, was apprised of the need to upgrade the mathematical backgrounds of NTID students ultimately to be registered in RIT's Calculus
75-101. Though he did not at that time know what
the exact solution to such a monumental problem
would be, Dr. Gering exhibited the educational acumen for which he is justly respected; he decided that,
before a solution was attempted, the problem should
be defined. He decided that before trying to provide
Unique Project in Computer Assisted Mathematics
students with skills prerequisite to learning the calculus, these prerequisite skills had to be defined in detail
and in behavioral terms.
This approach to producing a diagnostic-remedial
instrument resulted in the Summer Mathematics
Workship in July, 1968. The Workshop was charged
with defining the skills necessary to the study of
Calculus 75-101 and therefore consisted of members
of the RIT mathematics faculty as well as members
of the NTID faculty and staff. The efforts of this
group were reasonably successful; it identified 23
subject-matter areas required for success in studying
the calculus, pointed to some of the skills required,
and indicated the emphasis to be placed on the various
topics. As might have been expected, this activity
did not produce a detailed statement of terminal behaviors; what resulted was a fairly comprehensive
statement of projected course content.
Until December, 1968, the Summer Mathematics
Workshop was the last activity that led directly to
the development of the lVIDS.
In December, 1968, I was fortunate (I think), to
be appointed CAl Course Development Leader at
the NTID. Before coming to the NTID, I had spent
six years at Friden, Inc. (a division of the Singer Company), applying educational technology to the problems
of training service technicians. Although the position
at Friden had required the creation and implementation of multi-media instructional systems, use of CAl
had not yet been made available to us. W'hen the Eastman Kodak Company offered the opportunity to
extend the scope of the job to include using the computer in education, I joined that company as an education communications specialist. W'hile at Kodak,
I developed some of the CAl techniques that later
were to facilitate the creation of the MDS.
Although no signs of the existence of an MDS were
to become visible for several months, during the next
eight months every working hour was devoted to some
aspect of the MDS. There were questions of rationale
and instructional strategy to be decided. Objectives
(terminal behaviors) and subobjectives (enabling
behaviors) had to be decided upon. And above all,
when problems of strategy, rationale, and purpose
had been resolved, there remained the overriding
urgent question, "Who will do the enormous amount
of rather specialized work that is required by this
project?"
For, contrary to the somewhat naive expectations
of the NTID administrators, this was not a job to
be done by one lone CAl course development specialist. Even with the cooperation of a few subject-matter experts, if this task were to be completed in time
to have maximum effect, it would require a substantial
327
number of trained instructional programmers working
overtime. Getting additional people was a sticky
problem, for the table of organization provided for
but a limited number of full-time CAl personnel;
and most of these were allocated to technical support
of course development activities. And if authorization
to expand the course development staff could be obtained, where would we find competent CAl instructional programmers who were available and who
would fit into a limited budget? People capable of
this kind of work are rare, usually they are already
employed, and they are expensive. It was obvious
that if instructional programmers were to be added
to the staff, they would have to be "home grown"trained at the NTID. A time-consuming process and
not conducive to producing a l\1:athematics Diagnostic
System.
But what if development of the l\1:DS and the
training of personnel could be done simultaneously?
Why not a sort of "Learn as you earn" operation in
which the steps in developing the l\1:DS coincided with
the acquisition of expertise in educational technology?
In fact, could the production of the l\1:DS be organized
in such a way that it could be fragmentized; so that
it could be done by a large group of non-specialists
having backgrounds appropriate to learning the rudiments of instructional programming? We decided
that this approach was possible, and acted accordingly.
By l\1:arch, 1969, we had employed a group of ten people
having scientific and/or mathematical backgrounds
and had them working under the supervision of l\1:r.
Alex Andres, an educational consultant from the
University of Pittsburgh. The term of their employment was to end June 30, 1969. Because all but one
member of the group were female, the group became
known as the "Distaff Practicum".
By July 1, the Distaff Practicum had, within the
constraint of a predetermined logic, produced the
first draft of the diagnostic portion of the l\1:DS. In
addition, they had produced first drafts of objectives
and subobjectives.Enough training had occurred that,
by excellence of performance and by expressed inclination, three members of the Practicum were considered to be usable on a full-time basis. So when the
term of the Distaff Practicum ended, it had not only
achieved its goals but had also provided the CAl section of NTID with an organizational nucleus of three
excellent people. In addition, one member of the
Practicum, a chemist, was retained by NTID's Division of Instructional Affairs.
Previous paragraphs have presented the Distaff
Practicum's work as being not only design and production but also as a sort of boot-strap training activity;
the members were on a "learn as you earn" basis.
328
Fall Joint Computer Conference, 1970
]Vlost of this training was of informal nature. It is,
however, worth mentioning at this point that some
formal training occurred when 8 to 10 days of the
group's time was spent in going through the Instructional Technology Workshop (ITW) produced by
General Programmed Teaching. Bill Deterline, president of GPT, was the guiding spirit behind producing
the ITW workshop.
Besides ITW, the only other formal training instruments made available to CAl instructional programmers at NTID have been standard texts by
Skinner, Lysaught and Williams, ]\iager, Bloom,
IVlarkle, and others. One text, not so well known as
the others, is this manual The Creation of Remedial
Courses for CAl, written at NTID between January
and June of 1969. While written primarily as a training
instrument, it functions equally well as documentation
of the principles, policies, and procedures used by
CAI-NTID to ensure effective instruction by means
of the computer.
We don't make any extravagant claims for this
little manual--it is just a "how to" book on causing
the computer to be a tutor. Perhaps this much should
be said on the subject of manuals that deal with the
"nuts and bolts" of CAl instructional programming:
They are scarce. The scarcity of such materials probably accounts for most of the interest shown on our
manual. For example, I was surprised and flattered
when Dr. Gabriel Ofiesh, Director of the Center for
Educational Technology of Catholic University, requested multiple copies for use in graduate courses
in educational technology. IBM has requested permission to use the manual in some of its training activities. If you have an interest in, or a use for, such a
handbook, it will be sent to you on request.
Using the manual to set the ground-rules for completing the first rough approximation of the MDS,
the months of July through September, 1969, were
spent in revising and polishing existing diagnostic
test items, formalizing remedial prescriptions, and
translating the diagnostic portion of the MDS into
computer language, Course writer II. (In the first
version of MDS, remedial prescriptions were administered by an instructor-proctor.)
By the last week in September, the writing and
programming of the MDS was sufficiently advanced
that we were ready to work with our first group of
test subjects; we were ready to begin the initial field
test. On September 22, 1969, eight deaf students and
one hearing student sat down at the computer terminals and began item 1 of segment 1 of the Mathematics Diagnostic System (MDS). Three months
later, six of the nine were considered well-prepared
for entry into Calculus 75-101. Because they have
been in calculus for a short time, it is too early to
report positive results, but the prognosis seems favorable.
While the students were working through the MDS
during the fall quarter of the school year, they were
producing performance records that would be the
basis for revising, improving, and extending the MDS.
The winter quarter of 1970 was spent in updating the
MDS from the original version, now known as MDS-Vl,
to the more effective, more reliable, more completely
computerized version designated MDS-V2. No new
students were accepted during the winter quarter
so that this major operation, the production of MDSV2, could be as complete as possible by the time the
next group of students arrived in March of 1970.
When RIT's spring quarter began on March 23,
there were 20 NTID students on-line with the first
segments of the MDS-V2. For a number of reasons,
among the best of which was that our computerated
classroom has but 10 student-positions, the group was
divided into two classes, each containing 10 students.
Because MDS-V2 eliminates much of the administrative and clerical activity that had wasted the instructor's time in MDS-Vl, it was thought that the ratio
of students to instructor could be raised from 4 to 1
in MDS-Vl to 10 to 1 in MDS-V2. Another significant
difference in the administration of MDS-V2 was that,
while remediation in MDS-Vl had been tutored by
the course authors, the instructors for MDS-V2 would
be members of the RIT and NTID mathematics
faculties.
At this point in our narrative perhaps some mention must be made of the role of the instructor-proctor
in the effective presentation of MDS-V2. As "proctor,"
he keeps the mechanical and technical aspect of the
course going smoothly; he sees that each student is
having no difficulty with operating the terminals;
he cooperates with the technical staff in operating
the equipment; he evaluates records of student progress. These are the more mundane and mechanical
features of the job that require some technical ability
but do not evoke much creative effort.
But as "instructor" his knowledge of mathematics
and his tutorial effectiveness may well be strained
to the limit. This demand on the tutorial skill of the
instructor-proctor results from the fact that the nature of the MDS produces a mode of instruction demanding that the full-time job of the teacher is to
teach--not to present instructiona1 materials. The
computer presents diagnostic materials, prescribes
remediation, and tests to see whether or not the desired learning behaviors have occurred. Because there
is no such thing as a perfect program, some of the
program must fail with some of the students. When
Unique Project in Computer Assisted IV[athematics
the program fails to produce the desired results, the
student is directed by the program to consult the instructor. There is another, happier way that can produce tutorial activity; the program may have so stimulated a student's imagination and enthusiasm for the
topic that he requires more information than has been
provided. When this happens, the student may voluntarily seek the guidance of his instructor in going
beyond the limits of his program. Whatever the reasons for the demands placed on his teaching skills, the
instructor who operates in this setting is faced with an
intense, varied, and--I should think--rewarding experIence.
While the combined activities of human and machine are working to produce the most effective preparation for calculus that is within their power, records
are being produced that will permit the effectiveness
of the course to be evaluated. The results of MDS-Vl,
considered by its authors to be a first rough approximation, has been empirically evaluated and revised
on the basis of student performance records. Further
evaluation of MDS-VI will be possible when it becomes
clear how many of the difficulties experienced in calculus by MDS-VI students may be related to lack
of preparation-to failure of the MDS-VI. Such crudity
of method was thought to be not only adequate to
the circumstances of MDS-Vl but necessary if MDSV2 were to appear on schedule.
Because MDS-V2 is considered to be reasonably
close to a finished product, evaluation of this instrument will be carried out by the NTID's Research and
Training staff. It is hoped that applying the talents
of this group to determine factors of reliability and
validity will produce data that are useful in improving
subsequent versions of the MDS. Data for this project
being gathered now during the spring quarter should
produce usable results before the opening of the fall
quarter in September, 1970. By the winter quarter
(1970-1971), it is expected that the MDS will have
reached a point of stabilization; that subsequent versions will be extensions and additions to MDS rather
than revisions.
While determining the effectiveness of the MDS
in educating deaf students is of first priority, there is
reason to believe that it could be equally effective in
performing its function. for hearing students who
anticipate entering first year calculus at RIT. To test
this belief, during the 1970 summer quarter the MDS
will be given to two groups of regular RIT students
who would otherwise have been enrolled in pre-calculus math courses. If this experiment proves to be
successful, it will lend a universality to the application of the MDS that will greatly enhance its economic
feasibility--always an important faCtor in determining
329
the practicality· of any project in computerated education.
Practicality? Well, we here at the NTID think that
the l\tIDS, if not immediately justifiable on purely
economic grounds, points the way to innovations in
education of the deaf that will someday make CAl
projects feasible from all points of view, educational
as well as economical. Although it is much too early
to label the MDS an unqualified success, its existence
and apparent effectiveness are stimulating RIT and
NTID faculty members to cooperate in similar projects.
Several such projects are already under way; courses
in thermodynamics and circuit design are being produced by the combined efforts of RIT faculty and the
CAl Course Development that could herald RIT's
emergence as a front-runner in the field of educational
technology as well as in the education of the deaf.
That is what we hope, and that is the goal toward
which we shall continue to work.
What I have told you thus far has been a history
and description of the first major project undertaken
by the CAl Section of the National Technical Institute for the Deaf. The information you have is but
part of a complete report on the l\tIDS that includes a
description of the underlying philosophy of coursedesign, the rationale and design-principle, and a report
on initial field-tests. If any of those present are interested in these details, please leave your name and
address and you will be sent a copy of the complete
report.
Also included in the final report are details of the
computing system by which the l\tIDS is administered.
This part of the report was prepared by l\tIr. Paul
Vonhof, Technical Support Leader for NTID's CAl
Section.
THE IBM 1500 INSTRUCTIONAL SYSTEM
The IBlVI 1500 Instructional System consists of
two major elements: a "hardware" element and a
"software" . element. All the items of equipmentmechanical, electro-mechanical, electrical, and electronic-make up the hardware element of the 1500
System. The software element consists of the various
computer programs that instruct the hardware in
what it must do to achieve the results desired from
the 1500 System. Both elements must be present if the
system is to work; the hardware is just expensive junk
without the software, and the software in meaningless
symbology without the hardware. It takes both elements working together as a complete system to produce the instructional magic of which the System is
capable.
330
Fall Joint Computer Conference, 1970
For there is an element of magic about a machinebased instructional system that adapts itself to the
specific needs of individual students; that makes allowances for individual differences in learning rates,
entrance behaviors, and intellectual capacities; that
can perform this service for as many as thirty-two
students, not all of whom are working on the same
course; that records and reproduces data on courseperformance and student performance; that, in short,
provides educational services the quality of which
is limited only by the capability and imagination of
the course-designer.
A machine such as we have been describing is, however, only a machine. In the final analysis, it is no
better than the people who use it. Its effectiveness
depends very much on the interaction between the
people who consume its output, the people who control its operation, and the people who design and
implement its input. These are the three general categories of users served by the System: the student, the
instructor-proctor, and the course-author.
Of these three users r the student comes first, for he
is the ultimate consumer, the reason for the existence
of the System. The System prescribes or presents the
instructional materials that uniquely fulfill the needs
of the individual student. Instructions may reach the
student as text on the CRT (cathode-ray tube) display. Or, the CRT may contain graphic information
with which the student must interact. Student interaction with the CRT may require the use of the
keyboard or it may require that responses be made
by pointing at the display with a Illight-pen." (The
light-pen communicates to the computer the exact
location of the spot at which the pen touches the
screen.) The student also may re~eive textual or graphic
information from the image-projector. (The imageprojector is a random-access film-strip projector
with full-color capability.) The IBM: 1500 Instructional System also includes an audio capability that
is not used at the NTID.
The System, of course, accepts and processes all
student responses, whether they are entered by means
of the keyboard or the light-pen. The material presented
to the student usually is contingent upon the nature
of the preceding student response. It should be apparent, therefore, that input and output are each a
part of a total continuum in which each determines
the other. This characteristic of the System allows
us to design courses having a high degree of adaptiveness to individual student-needs; it is the characteristic
of the System that ensures the ability to provide in.;.
struction that is truly individualized.
To enhance the interactive nature of the CAl program, the System provides for student comments at
any time. It also permits the student to request help
from the instructor-proctor at any time the student
thinks he needs it.
While the student interacts with the System, the
instructor-proctor controls it. The duties of the instructor-proctor are covered in a fair amount of detail
within the body of the text of this article, All that needs
to be added is that, because students and courseauthors may simultaneously be using the System, the
proctor exerts control over the "activities of both students and course-authors. The term Iicourse-author"
includes both the instructional programmer and the
Coursewriter programmer. The System provides the
author with services that are essential to him. It
Ilassembles" his courses in a storage device-assembles
Coursewriter II into a format that can be interpreted
by the machine. During the execution, it Iiinterprets"
his courses-implements machine-language instructions. It presents his courses as specified by the logic
of his program. It analyzes progress. The author can
make changes, additions, and deletions that are based
on information received from the System itself.
All the activities and services to author, proctor,
and student depend on human interaction with the
hardware/software complex that is the IBM 1500
Instructional System. Having given some indication
of what the System does, the remainder of this sup-
1442 Cord
ReodPuncn
Datoondprogrom
inputondoutpu',
1131 Centrol Proce"intUnit
1132 li". Printer
Activates Instructionol Stations.
Analyzesltuden'r.'POrI....
Pr...nts coune material.
Directloll,),,'em inputoncloutput.
Houle. tM CAl Programming Systems
which direct all CAl operations.
Perfo,nlOnce
recordsancfoll
print.dlish.
1502StotionControl
Control,movement
ofdoto~t\.'..n
stations OI'dCPU.
2310 Disk Storage
' ....... _--/
Permonently
stores the CAl
Programming Sysmateriols,.tudent
recordt,dic'ionorie.,ete.
telTll, COUf..
InstructionolStotion
AsmonYO$S
Disk StOf'age Units
moybe attoche-d.
Figure I-Interrelationship. of hard ware components
Unique Project in Computer Assisted Mathematics
plement describes its hardware and software components.
Hardware
It is the hardware of the System that is visible to
the consumer or observer. He becomes familiar with
the keyboards, the light-pen, the CRT display, and
the film-strip projector-·all of the facilities to be
found in the computerized classroom. If he is a special
friend of the operations manager, the observer may
be allowed into the machine room, where he sees the
devices by which course materials are stored-the
magnetic disk drives and the magnetic tape units.
He sees the card reader/punch by which course materials and computer software are created, assembled,
and entered into the system. Also located in the machine room are the central processor and the station
control unit, which directs the flow of course materials
from the central processor to the appropriate terminals.
A printer prepares performance recordings and other
lists required in operating the System. (See Figure 1a pictorial representation of how the various units
relate to one another.)
Software
The 1500 software, expressed more formally as the
1500 Programming Systems, supports the 1500 hardware. It supervises and expedites all operations performed by the IBM 1500 Instructional System. In
addition to the Coursewriter II System described in
Appendix B, it includes six major programs that cooperate to keep the 1500 System operating efficiently.
These programs are:
1. Main Control Programs.
2.
3.
4.
5.
6.
Station Command Processing Programs.
CAl Processing Programs.
CAl Support Programs.
CAl Utility Programs.
System Utility Programs.
The Main Control Programs are supervisory programs
and form the basic operating system. These programs
provide scheduling service to each instructional station
that demands individualized service in handling inquiries and responses. They accumulate performance
records and, when necessary, provide the user with diagnostic information about the operation. The operating
331
system routinely stores and maintains all data needed
by the programs executed under its control.
Station Command Processing Programs provide
the language link between the system user and the
computer. It facilitates all communications between
the student terminal and the computer.
The CAl Processing Program is the major CAl
application program, Coursewriter II. This program
contains the Coursewriter II interpreter, which executes the user's assembled course and interacts with
the students at the terminals. The CAl Processing
Program can present textual material on the typewriter or display screen, present problems, process
student responses, and operate the image projector.
It performs arithmetic and logical operations. The
CAl Processing Program also can be called upon to
set and to interrogate a response timer, a device for
recording the speed with which students respond to
questions.
The Coursewriter II assembler translates Coursewriter II language statements into a form acceptable
to the interpreter. The assembler is an important
program within the CAl Support Programs section
of the programming systems. Material can be inputted
by means of either keyboard entry or card input. CAl
Support Programs also allow for modifications to
courses.
The CAl Utility Programs allow certain special
background jobs to be done; these jobs support the
operations for organizing courses on magnetic disk.
The System Utility Programs provide the functions
necessary to preparing and maintaining systems
package.
All of the software briefly described in the preceding
paragraphs are necessary to control the multitude of
operations demanded of the hardware. Students taking
courses, authors .entering Course writer statements,
proctors sending' supervisory commands, and operations people scheduling background jobs-·each makes
demands on the programs included in the 1500 Programming Systems.
SUMMARY
The combined facilities of the 1500 hardware and software present a versatile tool for instructional tech-.
niques. Thirty-two students, each working independently on a different problem or program, can timeshare the system. Textual material, full-color film, and
audio messages can be presented to the instructional
stations under computer control. The computer automatically provides file maintenance to course and
user's records. Course and student information is
332
Fall Joint Computer Conference, 1970
stored and retrieved as required by each station when
it is serviced by the computer.
The operating system controls all interaction between the students and the course material being
presented. The answer analysis of each problem and
the infinite branching through the course is automatically performed by the CAl processing programs.
The system allows for a standard dictionary of 128
characters, three special 128-character dictionaries,
and three graphic sets of 64 symbols each. Coursewriter allows the system to display alternate dictionaries or graphics during course presentation. The
interactive graphic capability allows the student to
point at a position on the CRT and have the system
determine the co-ordinates of the pen .response. Finally, the system is flexible in its software capabilities
and allows the user to make additions or extensions
to it.
But, above all, the IBM 1500 Instructional System
provides the course development specialist with a
means of presenting the student with a course the
effectiveness of which is limited only by human ingenuity. The potential of the System has only just
been scratched; CAl itself is but an infant-giant.
Teaching digital system design with a minicomputer
by lVIARVIN C. WOODFILL
Arizona State University
Tempe, Arizona
chased with a 4,096 word, 16 bit memory with memory
cycle time of 1.8 microseconds. The machine design
provides a bus oriented party-line I/O and a readily
expandable interrupt capability. A block diagram for
this computer is shown in Figure 1. The architecture
of this computer illustrates many of the "pin limited"
design constraints of large scale integration system design which provides a "state of the art" system model
constructed with transistors.
INTRODUCTION
Design education requires a study of the "art" involved
in a given discipline in addition to the study of its
"science." Textbooks tend to concentrate on the science
and leave the art as 'an exercise for the student.' One
solution to this problem is the use of a "real" example
of the discipline involved as a teaching aid and laboratory tool. With this approach the art and science can
be taught in integrated form and with the given system
as a base, these principles can be readily extrapolated
to other systems. The "broad brush" approach to design
education without a base of knowledge tends to leave
the student little net gain.
In digital system design education a minicomputer
can provide a very good example of the discipline.
Minicomputers are superior to "larger" systems for
this use because they are small enough in size and
complexity to be easily understood, but with the addition of suitable software can provide a very useful
computational tool. The Digital Systems Laboratory
(DSL) at Arizona State University was originated in
1966 with the aid of an NSF Educational Equipment
Grant which provided the funds for the computer
which forms the nucleus of this laboratory. The DSL
was conceived to provide: A very flexible teaching aid;
a prototype digital system which students could study
in detail; and a vehicle for student hardware, software,
and application experiments, studies, and projects.
CORE MEMORY
ARITHMETIC
UNIT
THE COMPUTER
A DATA· 620 manufactured by Data Machines Incorporated (now Varian Data Machines) was the computer purchased for this laboratory. The DATA 620
(currently available in integrated form as the DATA
620/i) is a binary, parallel, single address, bus organized,
16 bit, general purpose digital computer with an extensive command repertoire.! The computer was pur-
SELECTION (s) BUS
DATA 620 FUNCTIONAL ORGANIZATION
Figure I-Data 620 functional organization
333
334
Fall Joint Computer Conference, 1970
Figure 2-The initial systom
This computer was purchased with several options
which greatly enhanced its value as an instructional
tool. (A picture of the original system is shown in
Figure 2.) These options include: (1) A large classroom
display, (2) A micro-exec bus providing external processor control; (3) the pulse instruction execution option;
and (4) A real-time clock. The classroom display shows
the contents of the registers in the processor and memory and the state of the system's clocks. The communication paths and interconnections are also illustrated
on this board. This board is used extensively in the
lecture as a training aid and demonstration media.
The micro-exec bus provides a means of external control
of the processor rnicro-signal execution. During demonstrations of the operation of the processor logic, a
switch box is used to selectively enable the processor
micro-signals to illustrate the execution of various instructions and operations. This facility is also, an in-
valuable maintenance tool. The pulse execution option
provides the user with the ability to supply manually,
by a switch closure, the pulses normally supplied by
the 2.2 MHz master clock. This allows the observation
of the execution of machine instructions at the microstep level which provides a very graphic display of the
operation of the processor logic. The real-time clock
which provides a time base interrupt capability is used
to illustrate real-time operation and provide "clever"
displays, i.e., the functioning of a multiplication algorithm in slow motion. The system also contains a
maintenance panel which facilitates oscilloscope observation of the major processor microsignals for display
or maintenance use.
These options are very convenient but should not
be considered an absolute necessity. Most minicomputers (including the DATA 620ji) have, for example,
a much more limited console than the DSL system.
Teaching Digital System Design with Minicomputer
However, the most meaningful interaction a student
has with. the computer is through the on-line teletype
and other peripherials so a limited register display is
inconvenient but not disabling. It should also be noted
that the DATA 620 is only one example of many minicomputers that could· be used in a laboratory of this
type.
The original system functioned well as a teaching
aid and display device but was not a satisfactory
"hands-on" tool for student laboratory use, because of
its slow and inefficient I/O facilities and its limited
software.
THE SYSTEM HARDWARE
The first problem to be solved in the realization of a
useful student tool was alleviation of the I/O bottleneck. An off-line ASR-35 teletype was purchased to
allow off-line preparation of student tapes but the slow
input speed (25 char/second) of the on-line ASR-33
tape reader still limited system through-put. The graduate college at Arizona State University requires all
lVlaster of Science students to write an' Engineering
Report or Thesis as a final step in fulfillment of graduation requirements. The expansion of the hardware of
this computer system has provided and will continue
to provide numerous Engineering Report and Thesis
project topics. To date, the following peripheral hardware has been interfaced to the system in this fashion:
(1) A paper-tape reader and punch with 50 character/
second capability (the reader and punch was an industrial gift); (2) A Holly-Line Printer (also an industrial gift) with 300 character/second capability;
(3) A 1000 character/second paper-tape reader; and
(4) A 150 character/second paper-tape punch (the latter
two were purchased with funds remaining in the NSF
Grant); (5) A patch panel facility for the micro-exec
bus to allow the implementation of patched machine
instructions (complex algorithms accomplished as one
machine instruction). Many other projects have involved the modification of the basic command structure
of the computer. The conditional jump structure of the
machine was augmented to essentially double the number of, useful jump conditions. The mechanical sense
switches of the original computer were replaced with
logical switches (flip-flops) under program and/or mechanical control. Extended addressing capability was
added which provides direct, indirect, and indexed
addressing to 32K words of memory was added. Fixed
point multiply and divide hardware was added to the
central processor. A hardware parity testing instruction
and hardware instruction to save the volatile state
335
indicators (overflow and sense switches) was added.
Logic was added which causes the execution of a halt
instruction to control return to the Operating System.
These changes and others have resulted in a dynamic
system hardware configuration tailored to the needs of
the system users. See Appendix A for the DSL instruction format. Although the original computer was
composed of "discrete parts" most of the hardware
modification projects have been accomplished with
integrated logic. The hardware of the system is continually being improved and expanded.
The following hardware projects are currently in
progress: (1) The addition of an auxiliary 64K words
of primary memory to the CPU (the memory was an
industrial gift); (2) The interface of a magnetic tape
system of four tape drives (also an industrial gift);
(3) The interface of a magnetic drum memory (also an
industrial gift); (4) The addition of a GE 115 computer
with card reader and line-printer as a secondary processor (also a gift); (5) The construction of a priority
interrupt facility and analog to digital and digital to
analog conversion facilities. (6) The interface of three
additional ASR-33 teletypes which will provide the
basis for a time-sharing facility.
THE SYSTEM SOFTWARE
The development of adequate software to interface
the user with the physical capabilities of the system is
a never ending task. As each hardware change is realized
the system software must be redesigned to take fullest
advantage of the hardware. In a system with 4K words
of main memory and no secondary storage, the primary
system software design goal was to provide maximum
capability in minimum memory. All of the software
used in this system was designed expressly for this
system. Figure 3 shows the normal configuration of
memory in the laboratory system.
The primary operating system is called the Monitor
Utility Driver PACkage. (MUD PAC) which provides:
(1) Subroutines used by students (and the other system
software) to accomplish I/O (monitor); (2) A comprehensive set of on-line debugging utility routines; and
(3) A driver system which allows on-line teletype control of the entire system. Teletype control is essential
to the efficient operation and maximum through-put of
the system. The MUD PAC was designed to provide
the user with all the computational tools necessary for
the operation of the system with minimum interference
to the user. The MUD PAC requires 14008 or 76810
memory locations.
The monitor is organized into 3 subroutines: CHAR,
336
Fall Joint Computer Conference, 1970
OCTAL LOC
CONTENTS
00000
01000
MAS
02000
ASSEMBLER
03000
04000
STUDENT
WORK
AREA
05000
OVERLAY
AREA
06000
(KORR)
07000
MUD
PAC
Figure 3-DSL system memory map
for character (8-hit) I/O; NU1\1B, for octal number
(6 digit) I/O; and MESG, for message (strings of
ASCII characters) I/O. In all cases, the setting of the
sense switches, which is under program control, designates the I/O device involved and the direction of
data transfer. See Appendix B for further subroutine
description and the coding used for the accomplishment
of I/O operations under monitor control.
The utilities provided include the usual types of
utilities: Pseudo register manipulation, memory change,
memory initialization, memory dump, selective memory
search, location flagging, and program trace capabilities.
In addition, the routines to load and punch object
information in the object formats of this system are
provided. The more nonconventional of these formats
is known as monitor format and is an inefficient format
using octal numbers represented as ASCII characters
on paper tape to fill sequential memory locations. This
format is used by the students in the initial phases of
their laboratory course to enter their machine language
programs. This object format can be generated on an
off-line teletype and thus provides much better turn
around time for machine language programs than would
manual entry.
The driver routine accepts keyboard inputs of single
letter mnemonics, which correspond to one of the defined MUD PAC operations, then the driver accepts
the required number of parameters (octal numbers from
the keyboard) and transfers computer control to the
routine which performs the function of the particular
mnemonic. l\1UD PAC mnemonics are listed in Appendix B. In addition to the utilities, driver mnemonics
are also provided to accomplish linkage to the other
system software, namely the Monitor Assembly System
(MAS) assembler and the overlay area programs, usually the source tape correction program (KORR).
The l\1AS assembler was expressly made to take advantage of the hardware of this particular system.
l\1AS possesses all the capabilities available in most
non-macro assemblers including page titling and source
line numbering. Current l\1AS operation codes are listed
in Appendix C. l\1AS contains predefined values for the
monitor subroutines and its syntax has been chosen to
complement the machine language structure of the
computer. The fixed portion of the l\1AS assembler
occupies less than 4000 8 or 204810 memory locations
and uses the student work area for tempo:rary storage~
The overlay area of the lab system normally contains
the KORR source tape correction which provides the
efficient source correction capability available automatically only in a punched card environment. Whenever a source tape. is assembled or pre-listed (which
can be done with KORR) each source line is assigned
a decimal identification number determined by its sequential position on the source tape. Using these numbers and the KORR mnemonics provided, during the
duplication of a source tape any combination of source
lines can be deleted, replaced, or added. This process
Teaching Digital System Design with Minicomputer
can be accomplished under on-line teletype control or
by preparing the corrections off-line and using the
auxiliary paper-tape reader as the on-line correction
device. The latter approach is used in the laboratory
to increase system through-put.
The efficiency of expressly designed software is illustrated by the IVIAS assembler. In comparison with the
DAS assembler (supplied by the manufacturer) for this
system: (1) Both assemblers are self-contained (perform
their own I/O), however for DAS all I/O was through
the ASR-33 teletype (8ince that was the only I/O device
in the original system), whereas l\1AS uses the Remex
Reader, Holly Line Printer and Tally Punch; (2) The
fixed portion of DAS used 5776 8 or 307010 memory
locations, l\1AS uses 04000 8 or 204810 ; (3) DAS had
13410 defined op-codes, MAS has 16310 ; (4) DAS allowed
only four character labels, l\1AS allows 6 character
labels; (5) Within the 4K memory DAS would allow
the assembly of a program with 2241O-four letter labels,
l\1AS will allow 6401O-six letter labels. (6) l\1AS provides
source line numbering, parity checking of source input,
page titling, and automatic symbolic formatting. These
were not provided in DAS. The MAS assembler then
is clearly superior to the DAS assembler in every respect.
In defense of the manufacturer, the DAS assembler is
conditionally assembled from an assembler which can
be made to match the hardware configuration of any
DATA 620 system and thus is necessarily less efficient
in any given system. This a8sembler was designed and
coded as part of the graduate software design course.
SYSTEM USE
This laboratory system is used extensively in a senior
elective/ graduate course in Logical Systems Design
(enrollment about 80 per year) and in a graduate
Integrated Systems Engineering Program (enrollment
about 20). Both courses are preceded by a course in
Logical Component Design using Chu, 2 and followed
by graduate courses in Digital System Hardware Design and Digital System Software Design.
The logical systems design courses have no programming prerequisite and the students begin by
learning to program the DSL system in assembly language and machine language. This process takes about
half of the course and results in the students acquiring
programming ability, knowledge of the use of the arithmetic hardware, and knowledge of the applications of
a small computer. During the second half the students
become familiar with· the micro-level processor signals,
system timing signals, system logic, instruction execution logic and the significance and handling of inter-
337
rupts. The class is conducted in the classroom-laboratory and frequent use is made of the available display
tools. In the laboratory portion of the course, the
students practice their skills in the writing, testing,
and debugging of programs of increasing complexity,
employing an increasing amount of the system hardware and software. In a typical laboratory sequence
the students first lab (about the second week of the
course) will include a simple program in machine language entered and executed manually by the students
through the console (with no software). Each subsequent lab period the students are given more complex
problems and more software to work with. By about
mid-term the students are using the total system and
by the end of the semester the students are solving
problems requiring several weeks of coding and debugging. The students also spend some laboratory
periods involved with the hardware signals and the
micro-exec bus. When the students finish the design
course they have a common familiarity with the machine and assembly language, use, logic, logical language, and micro-signals of this computer system and
limited exposure to alternate techniques. Primarily,
they have a solid base of knowledge about the processor
of this particular computer and an intuitive understanding of what a computer can do and how the
internal functions are accomplished.
The emphasis in the subsequent graduate hardware
and softWare design courses is system oriented but they
are not restricted to the laboratory system, although
the base of knowledge or common language developed
in the DSL system is exploited. Even though these
courses are engineering based, they have no engineering
prerequisites and attract computer science students
from many other disciplines.
FUTURE PLANS
The most urgent problem presently facing the Digital
Systems Lab is the student load. With 3 hour laboratory
periods of 10 students each and one on-line teletype,
each student has about 18 minutes of computer time
per week to accomplish his assigned tasks. To provide
some relief a DSL DATA 620 simulator was built and
is available on time sharing service from a GE 600
system. This system is not the ultimate answer since
it tends to remove the student from the hardware
completely and it suffers from the "finite" lag problem
familiar to time share users. For the purpose of the
advanced students, however, the simulator provides an
excellent algorithm testing media.
A more tractable system will be achieved with the
338
Fall Joint Computer Conference, 1970
realization of a local time sharing capability. The system
will consist of three additional ASR-33 teletypes, which
will provide a total of four "user ports" to the system.
The design goal is to provide each user with a 4K
memory of his own, a utility capability roughly equal
to the present system, and, of course, the feeling that
each user has the complete system at his command.
Needless to say, successful completion of this project
depends upon the realization of additional memory
capability. The final system will of necessity separate
the user from the hardware to a greater extent than
the present system, but the alternative would be to
duplicate the hardware of the system and economics
forbid that solution. Since each system addition makes
the system more complex and difficult for the students
to comprehend, the basic 4K machine will continue to
provide the basis of instruction for the beginning course,
and the more sophisticated capabilities will be exploited
primarily in subsequent courses.
The digital systems laboratory has proven to be a
very successful and well received addition to a pre-
viously pedantic curriculum. The choice of a mllllcomputer for a digital systems design education laboratory model is considered essential since such a machine
is large enough to perform many useful functions, but
small enough to be understood by an average student,
and small enough so other uses need not be found to
justify its cost. The development of this facility has
been a painstaking process of evolution and improvement requiring a considerable amount of time and
effort. However, the knowledge and experience gained
by all concerned has certainly justified the investment.
REFERENCES
1---
Varian Data 620ji computer manual
Varian Data Machines Irvine California 1968
2 Y CHU
Digital computer design fundamentals
McGraw-Hill Book Company Inc New York New York
1962
APPENDIX A
. DSL DATA 620 INSTRUCTION FORMAT
INSTRUCTION
HALT
JUMP
JUMP&MARK
EXECUTE
SHIFT
OP CODE 1V1 FIELD
U15-U12
U11-U9
00
00
00
00
00
0
1
2
3
4
U8
A FIELD MICRO INSTRUCTIONS
U7
U6
U5
U4
U3
U2
S
S
S
S
2
3
(1) A&B A
(0) AorB B
REGISTER
CHANGE
00
5
Cond
on OF
IMMEDIATE
EXTENDED ADDR
00
00
6
6
0
0
INDICATOR
CHANGE
00
7
CHG
OF
S
S·
1
RT
LF
°TTRAN]
B
X
R
R
0
0
LOG
ARTHI S H
A
R
0
0
F
U1
A
R
+
UO
C
M
P
1FT COUNTI
DESTINATION
01 INCR
SOURCE
10 COMP. i XR BR AR' ·XR BR ARt
11 DECR
OP CODE FOR SW INSTR
IX
xi 0
0
0
X
X
0
Y
X
X
X
X
0
YI
IY
M FIELD FOR SW
CHG SOF (1) RS3 RS2 RSl SS3 SS2 SSl
SS ROF (0)
Teaching Digital System Design with Minicomputer
EXT CONTROL
10
0
SENSE
10
1
DATA INP
DATA OUT
10
10
2
3
IF
NI
UNCTIO
CLEAR
REG
339
[DEVICE ADDRESSI
[0001 AR
MEM] ID E V ICE
10 BR
ADDRESsl
11 A&B
1\/1
I
LOAD AR
01
LOAD BR
02
LOAD XR
03
INCR MEM
04
M FIELD CODES
STORE AR
05
0-3 DIRECT
STORE BR
06
4
REL to PR
STORE XR
07
5
REL to XR
INCL OR
11
6
REL to BR
ADD
12
7
INDIRECT
EXCL OR
13
SUB
14
AND
15
MUL
16
DIV
17
ADDRESS (A) FIELD
I
APPENDIX B
1\1:0NITOR UTILITY DRIVER PACKAGE (1\1:UD PAC) DIRECTORY
Monitor Subroutines:
CHAR:
CALL* CHAR Loc. 07000
Inputs one 8 bit char into LS 8 bits of cleared AR or Outputs AR, MS 8
bits first then LS 8 bits.
NUMB:
CALL* NUMB Loc. 07001
Inputs a terminated octal number (in ASCII char) into BR (right
justified), or outputs the 6 ASCII char representing the input value
of BR plus 2 ASCII spaces if AR=O or the 2 characters in AR if ¢O.
Neither effect AR or XR.
MESG:
CALL* MESG, 1\1: Loc. 07002 Inputs a string of ASCII chars delinated by , and stores them (2
char/word) in sequential locations starting at M and indicates E01\1:
with a cleared loc, or outputs a string of chars starting at M and
returns when a cleared loc is found. Neither effect AR, BR, or XR.
340
Fall Joint Computer Conference, 1970
Device Coding:
SSI represents mode: on is output-off is input
SS2 & SS3 determine device according to the following: 1 is on, 0 is off.
SS3
SS2
Device: (Input/Output)
0
0
T-R R/P
0
1
R-M/R/P
1
0
TTY Tape/ Line Pntr
1
1
TTY Keyb/ TTY Type
Utility and Driver Mnemonics:
Parameters are STRT, STOP, KEY, MASK Registers are AR, BR, XR, PR
Code:
Parm:
Description:
A
0
change AR
B
0
change BR
C
1
Change STRT
D
2
Dump loc STRT through STOP in SYST FMT
E
1
Elect (change) pseudo sense switches and overflow.
F
1
Flag location STRT
G
1
Go to loc in STRT
H
0
Halt return, go to PR
I
3
Initialize STRT through STOP with KEY
J
1
Jump to MAS, STRT determines pass
K
0
Korrect, source tape correction routine
L
1
Load or compare object tape SSI = L/C (0/1). SS2 = lVlont/SYST (0/1) format.
M
2
Memory dump of STRT thru STOP on line pntr.
N
0
New-Load new MUD PAC with BOOT loader.
0
1
Overlay linkage STRT is linkage code.
P
2
Punch loc STRT thru STOP in Monitor fmt.
Q
0
Query parameters and reg. (display all).
R
0
display Registers
S
4
Search STRT thru STOP looking for KEY considering only bits with 1 in IVIASK
T
2
Trace from STRT to STOP
Teaching Digital System Design with Minicomputer
U
0
Untrace
V
0
Vector reestablish interrupt vectors
W
0
Convert flex tape to ASCII.
X
0
change XR
Y
0
list entry to Korrect
Z
0
Zero all pseudo reg & reset pseudo overflow and sense switches.
APPENDIX C
l\10NITOR ASSEMBLY SYSTEl\1 (MAS) MNEl\10NICS
SINGLE WORD ADDRESSING
LDA
LDB
LDX
INR
STA
STB
STX
ORA
ADD
ERA
SUB
ANA
MUL
DIV
LOAD AR
LOAD BR
LOAD XR
INCREMENT AND
REPLACE
STORE AR
STORE BR
STORE XR
INCL OR TO AR
ADD TO AR
EXCL OR TO AR
SUB FROM AR
AND TO AR
MUL BR BY MEM
DIV A-B BY MEM
DOUBLE WORD NONADDRESSING
LDAI
LDBI
LDXI
INRI
STAI
STBI
STXI
ORAl
ADDI
ERAI
LOAD AR IMMED
LOAD BR IMMED
LOAD XR IMMED
INCR AND REP
IMMED
STORE AR Il\1MED
STORE BR IMMED
STORE XR IMl\1ED
INCL OR TO AR
IMMED
ADD TO AR
IlVIMEDIATE
ENCL OR TO AR
IMl\1ED
SUB FROM AR
IMMED
ANAl AND TO AR
IMMEDIATE
MULl MULT IMMEDIATE
DIV IMMEDIATE
DIVI
LDAE LOAD AR EXTENDED
LDBE LOAD BR EXTENDED
LDXE LOAD XR EXTENDED
INRE INCR AND REPL EXT
STAE STORE AR
EXTENDED
STBE STORE BR
EXTENDED
STXE STORE XR
EXTENDED
ORAE OR TO AR
EXTENDED
ADDE ADD TO AR EXT
ERAE EXCL OR TO AR EXT
SUBE SUB FROlVI AR EXT
ANAE ADD TO AR EXT
MULE MULT EXTENDED
DIVE DIVIDE EXTENDED
SUBI
INDICATOR CHANGE
ROF
SOF
SSI
SS2
SS3
RSI
RS2
RS3
IDCN
RESET OF
SET OF
SET SSI
SET SS2
SET SS3
RESET SSI
RESET SS2
RESET SS3
EXECUTE
341
342
Fall Joint Computer Conference, 1970
PRE-DEFINED EQU
AR,BR,XR,
AP,OF,AZ,BZ
XZ,Sl,S2,S3
MONITOR LINKAGE
CHAR FOR CHAR I/O
NUMB FOR NUMB I/O
MESG FOR MESG I/O
DOUBLE WORD
ADDRESSING
JMP
JAP
JOF
JAZ
JBZ
JXZ
JSS1
JSS2
JSS3
JAN
JNOF
JANZ
JBNZ
JXNZ
JNS1
JNS2
JNS3
JIF
JUL
JMPM
JOFM
JAPM
JANM
JAZM
JBZM
JXZM
JS1M
JS2M
JS3M
JIFM
JULM
XEC
XAP
XAN
XOF
JUMP UNCOND
JUMP IF A POS
JUMP IF OF SET
JUMP IF A ZERO
JUJHP IF B ZERO
JUMP IF X ZERO
JUMP IF SSl
JUMP IF SS2
JUMP IF SS3
JUMP IF A NEG
JUMP IF NO OF
JUMP A NOT ZERO
JUMP B NOT ZERO
JUMP X NOT ZERO
JUMP IF NO SSl
JUMP IF NO SS2
JUMP IF NO SS3
JUMP IF
JUMP UNLESS
JUMP & MARK
JMPM IF OF
JMPM IF A POS
JMPM IF A NEG
JMPM IF A ZERO
JMPM IF B ZERO
JMPM IF X ZERO
JMPM IF SSl
JMPM IF SS2
JMPM IF SS3
JUMP & MARK
IF
JUMP & MARK
UNLESS
EXECUTE UNCOND
XEC IF A POS
XEC IF A NEG
XEC IF OF
XNOF
XAZ
XANZ
XBZ
XBNZ
XXZ
XXNZ
XS1
XS2
XS3
XNS1
XNS2
XNS3
XIF
XUL
XEC IF NO OF
XEC IF AR ZERO
XEC IF A NOT ZERO
XEC IF BR ZERO
XEC IF BR NOT
ZERO
XEC IF XR ZERO
XEC IF XR NOT
ZERO
XEC IF SSl
XEC IF SS2
XEC IF SS3
XEC IF NO SSl
XEC IF NO SS2
XEC IF NO SS3
XEC IF
XEC UNLESS
MISCELLANEOUS
HLT
NOP
ENTR
SYST
HALT
NO OP
ENTRY POINT
SYSTEM
COMMAND
SKIP
SKIP NEXT LOC
TINA TRAN IND TO AR
TPAR TEST PARITY O:F AR
MCRO ENABLE MICRO
EXEC
REGISTER CHANGE
TZA
TZB
TZX
TAB
TAX
TBA
TBX
TXA
TXB
IAR
IBR
IXR
CPA
CPB
CPX
DAR
DBR
DXR
TRAN ZERO TO AR
TRAN ZERO TO BR
TRAN ZERO TO ZR
TRAN AR TO BR
TRAN AR TO XR
TRAN BR TO AR
TRAN BR TO XR
TRAN XR TO AR
TRAN XR TO BR
INCR AR
INCR BR
INCR XR
COMP AR
COMP BR
COMP XR
DEeR AR
DECR BR
DECR XR
Teaching Digital System Design with Minicomputer
ZERO
TRAN
INCR
COMP
DECR
TRAN ZERO TO
TRAN
INCR
COMP
DECR
SHIFT INSTRUCTIONS
LSRA
LSRB
LLSR
LRLA
LRLB
LLRL
ASLA
ASLB
LASL
ASRA
ASRB
LASR
LOG SHIFT RT AR
LOG SHIFT RT BR
LONG LOG SHIFT RT
LOG ROTATE LF AR
LOG ROTATE LF BR
LONG LOG ROT
ARITH SHF LF AR
ARITH SHF LF BR
LONG ARITH SH LF
ARITH SHF RT AR
ARITH SHF RT BR
LONG ARITH SM RT
PSEUDO OF CODES
ORG
BSS
ORIGIN
BLOCK STARTING
W/SYMB
BES
BLOCK ENDING
W/ SYMBOL
SYMBOL EQUALITY
EQU
SPAC SPACE
EJEC
EJEC
DATA CONSTANT
DECLARATION
CALL SUBR CALLING SEQ
MORE INTERRUPT INPUT
STREAM
END
TERMINATE
PROCESS
TITL
PAGE TITLE
DEFINITION
I/O INSTRUCTIONS
EXC
SEN
IME
INA
INB
CIA
CIB
OME
OAR
OBR
EXTERNAL CONT
SENSE
INPUT TO MEM
INPUT TO AR
INPUT TO BR
CLEAR INP AR
CLEAR INP BR
OUTPUT MEM
OUTPUT AR
OUTPUT BR
343
Computer jobs through trainingA preliminary project report
by M. GRANGER MORGAN, MARY R. MIRABITO, and NORMAN J. DOWN
The University of California at San Diego
La Jolla, California
entry level jobs. The only real prerequisites to training
someone as a semi-technical or business programmer are
an ability to organize ideas in a logical way and some
basic math skills.
A number of workers around the country have recently developed programmer training projects designed
for the disadvantaged. These workers have come to the
problem with different backgrounds and perspectives.
The various projects which have evolved display a rich
range of ideas, many of which might never have been
tested had the central planning and coordination that is
widely advocated by educationalists been applied to this
development from the outset. What is now needed is a
literature which describes these several efforts in detail
so that future workers will not have to rediscover what
has so far been learned, but can build on the basis of the
experience of others. This paper will describe one of these
projects, the University of California at San Diego's
project, Computer Jobs Through Training.
INTRODUCTION
Job training directed toward the disadvantaged population in the United States has been under way for
many decades. Traditionally this training prepared
people for lower entry level skilled and semi-skilled jobs
such as plumbers' aides, welders, clerks, and secretarial
help. Only recently, with the expanding awareness of
the significant social inequalities which continue to
characterize U.S. society, have large numbers of people
begun to realize that job training-for just any old
job-is not enough. If training is to have any appreciable
impact upon the social stratification that characterizes
the employment structure, efforts must be made to find
high entry level-jobs which are suitable for such special
training projects.
Of course job training is not the ideal-solution to the
problem. Something that might honestly be called a
"solution" will not come until the children of the disadvantaged receive a quality primary and secondary
education and an equal opportunity for college level
training. There are plenty of people working on reforming the school system so that such educational equality
will one day be a reality. But despite some progress this
task is proving exceedingly difficult. In the meantime
there is a whole generation of young people who have
not enjoyed the advantages of an improved school system and who are without significant job skills. The question is, can we devise job training programs which will
train these young people for a career other than in low
entry level jobs?
A number of workers have looked to semi-technical
and business computer programming as a high entry
level job area in which disadvantaged students could
perhaps be trained. l They have viewed programming
as attractive because it does not require many of the
social prerequisites, such as the ability to speak dialect
free English or a working familiarity with business world
interpersonal relations, that are necessary for most high
The basic approach
Work at UCSD on programming instruction for the
disadvantaged began in the summer of 1968 when we
offered a course in digital logic and basic FORTRAN
programming to a group of high school students who
were working on the campus in summer jobs made
available through the Neighborhood Youth Corps program. This initial course had no long term job training
intent. It was offered strictly as enrichment, as something we thought would be a "good thing to do."
We were surprised by how well the course went, and
especially by how exciting the students found the subject matter. We began quickly to see that programming
and other aspects of computer science were potentially
very useful topic areas for reaching and turning on
students who previously had not gotten very interested
in formal education.
345
346
Fall Joint Computer Conference, 1970
But while it is easy to get these students "hooked"
on programming, the standard teaching methods, particularly the formal lecture situation, are totally inappropriate. Programming is best taught to these students
the way modern languages are now being taught. Rather
than listening to lectures on the grammar of the language students learn the language by using it. Beginning
on the first day, the instructor gives a bit of basic introduction and then writes a simple program. He explains it, but doesn't really expeet his explanation to be
fully understood. The students copy this program,
punch it onto cards, which is a painful process since
many have never typed, and after some brief instructions run the job themselves on a small computer. Inevitably there are errors but sooner or later the job runs
and you see the first glimmerings of understanding and
excitement. In the weeks that follow you build on this
basic understanding, slowly enlarging on the student's
repertory until he has a command of most of the language.
The physical facilities
This hands-on approach works, but only if there are
adequate computing facilities available for all students
to use on a continuing basis. Economically the simplest
approach is to take the students to a central training
facility. In the compact inner cities of our major urban
centers this approach also makes good social sense. But
in San Diego, while the Black community is somewhat
localized, the Chicano or Mexican American community
is spread all across the city in a collection of widely
spaced communities. In the early portions of the course,
motivation is the single most important considerationand one good way not to motivate people is to make
them sit on a bus for an hour or more every day riding
to and from a class.
The prospect of establishing a number of training
facilities throughout the community was financially unreasonable. In addition, we were reluctant to choose any
one portion of the community for our efforts at the expense of others. The solution we chose was a mobile
instructional facility housed in a forty foot trailer truck,
which through careful scheduling can simultaneously
support up to a half dozen courses at different locations
all around the city.
A used forty foot trailer was acquired in the spring
of 1969 as a gift from Safe way Foodstores, and with support from the Rosenberg Foundation of San Francisco,
Montgomery Ward, and the University, the training
facility was constructed in this van during the summer
and fall of 1969, Figure 1. Our small project staff was
considerably aided in this work by a group of Neighbor-
Figure I-General exterior view of the Computer Jobs Through
Training mobile computer classroom facility. Both the tractor
and the forty foot trailer are used equipment which have been
reconditioned by the project staff
hood Youth Corps students and UCSD undergraduates,
largely from the Black and Chicano communities, who
contributed many long hard hours of work at low pay
along with much enthusiasm and a number of first rate
ideas.
The UCSD Computer Center is in the process of installing a large Burroughs B6500 system. Until sometime in 1971 when that system will be supporting a full
complement of remote operations, our hardware in the
van consists of a small computer with free standing
FORTRAN capability and remote batch COBOL ability. When the B6500 system is in full operation this
small machine will· probably be replaced by a terminal
consisting of a small card reader, a line printer and a
teletype.
One important hardware requirement is the ability
for students to interact with their program during execution. We stress this kind of programming in the early
portion of the course because it helps significantly to
motivate students and keep interest high. We find too
that a drum plotter is a very useful device. Students
Computer Jobs Through Training
work up cartoons and other line drawings with considerable enthusiasm, and the systematic operations involved in pen control make for good practice in step by
step logic.
The floor plan in this facility is completely flexible.
This results in part from the admissions policy we have
adopted. The problem of identifying potentially successful programmers even among college graduates is substantial.Making this identification for disadvantaged
young adults is an almost impossible task. It is widely
recognized that aptitude tests display a cultural bias.
More importantly, since many of the students we hope
to reach "turn off" in a testing situation, we feel that
massive pre-testing, which has been the approach of
some experimental programs, is not the answer.
Obviously. we must require basic math and logic skills,
and a level· of intellectual development on the part of
our students roughly equivalent to that of a high school
graduate. We do not specifically require a high school
degree, though most of our students have one or are in
the process of getting one.
To check for math and logic skills we administer a
short entrance test, which like all of our introductory
347
material is bilingual,with English on one side of each
page and Spanish on the other. But our basic approach
to entrance has been-anyone who seriously claims he
wants to be a programmer may enter the course. If he
has not done well on the entrance exam we warn him
that he will have trouble. But no one who is really
serious ip. claiming that he wants to take the course has
been excluded. Actual performance during the first
weeks of the course is the real entrance test.
All this is fine, but one must be realistic. Many
students will quickly discover that programming is just
not "their bag" and will drop out of the course in the
early weeks, others will stay with the course for some
while, but despite good motivation will just not be able
to do the work. These latter students we are trying to
direct towards alternative more appropriate forms of
training, such as the San Diego Urban League's key
punch school, so that their CJTT experience will not
represent a failure, but rather a first step toward some..:.
thing else.
Given the diminishing class size which results from
this approach to admissions we have designed the van
so that we can start out accommodating relatively large
Figure 2-Two interior views of the classroom van. Above, a student prepares to run her program. Below, a
general view of students in the first adult evening class
348
Fall Joint Computer Conference, 1970
numbers of students and then eventually switch over to
a more spacious floor plan once the class size has fallen
off. In addition, arrangements have been made to allow
the van to be subdivided into smaller areas for group
work with teachers aides. A laboratory set-up with
normal work benches is also possible. Figure 2 shows two
interior views of the van.
Curriculum considerations have dictated a number of
other aspects of the physical facilities. In our work with
Neighborhood Youth Corps students during the summer
of 1968 we looked at a large number of the 16mm films
on various aspects of computer science which are available from industry. Almost none of these films are suitable for use with our students. They are either much too
technical, or much too simple minded. As a consequence
a large set of 35mm slides has been developed for use
with the course. These slides come in three types:
course slides, which directly support· the curriculum
with flow charts, diagrams, drill exercises and· similar
materials; computer science orientation slides, which
provide students with an introduction to the physical
components of computer science, explain how they work,
and introduce the student to a large number of typical,
system applications such as airline reservation systems,
medical diagnostic systems, scientific systems, production control systems, and so on; and social orientation
slides which consider things like how to act and what to
expect in a job interview. So that these slides can be
used as an integral and natural part of the course,
without disrupting the flow of thought when slides are
introduced, the van has been equipped with a remotely
controlled projection system and variable intensity
lighting. The instructor is able to use slides easily and
at his convenience.
Finally, to support the hardware portion of the course
which is described below, the necessary DC logic voltages t signal lines, and 110 volt lines are distributed to
convenient plug panels located for student use throughout the van from power supplies and signal generators
located in a small, shop area in the forward portion of
the van.
The instructional program
Before describing the details of the curriculum which
has been developed for the CJTT course it is important
to explain what kind of person, with what kind of programming skills, we are training in this project and
what he will most likely do when he finishes the course.
Clearly we will not be producing systems programmers.
What we will produce are competent coders and programmer/trainees, who unlike the graduates of many
private data processing schools will have a solid founda-
tion in the logical aspects of programming. Our graduates will be able to take a well stated word problem,
work up the necessary logic, develop the flowchart,
produce the necessary code, debug the program, and
make it run.
But despite our earlier observation that the only real
prerequisite to success as a programmer is an ability to
think logically and a command of fundamental mathematics, it is nevertheless important to realize that while
many of today's successful programmers worked their
way up with only ~ high school degree, this is becoming
increasingly difficult to do. More and more a two year
AA in data processing or, better still, a four year BA
is becoming prerequisite to substantial progress up the
data processing ladder from the lower coder and programmer positions,
Recognizing this, and understanding that we can
reasonably expect to train people who at the outset are
employable only in the lowest positions, we have attempted to design both our own project, and the kind
of job placements we have arranged, in such a way as
to maximize the possibilities of further education for
our students. Hence in our course we emphasize a str~:mg
foundation in the basic logical techniques of programming rather than the sort of cook-book introduction to
existing operating systems that is characteristic of
many of the private data processing schools. We treat
specific programming languages as secondary in importance to the fundamental ideas of program organization. But, in our choice of languages (FORTRAN and
COBOL) we have been careful to select those languages
which we think have the best potential for immediate
employment, consistent with our long term objective
of further education.
We begin with FORTRAN. Most of the semi-technical programming jobs in the San Diego area require
FORTRAN, as do almost all of the major employers
with good programs for continuing employee training
and education. FORTRAN has two other important
advantages. Unlike COBOL, which requires a substantial knowledge of syntax before even simple programs
can be written, it is p()ssible for students to run and
understand simple FORTRAN programs on the first
day of class. A second advantage is the easy use of subroutines, an aspect which we consider essential in teaching basic programming concepts.
The basic curriculum for the CJTT project was
evolved during the summer of 1969 with the support of
the Rosenberg Foundation and received preliminary
field testing on a second group of 15 Neighborhood
Youth Corps students in a 8 week summer course at
UCSD, Figure 3. The organization of the course is shown
in Figure 4.
The formally developed curriculum material con-
Computer Jobs Through Training
349
thing most of them have done only rarely in their previous activities.
Along with this graduated difficulty in program logic
goes a review of basic math concepts. This review takes
place as part of the programming rather than as a
separate topic since most of our students have been
"turned off" by math in school, largely because they
never could see any need or use for math. Having gotten
the student hooked on programming, it is then possible
to undertake a math review in the context of programming which students would never tolerate as a simple
abstract review.
All of the early material in the course is available in
English on one side of the. page, and Spanish on the
other. Clearly no programmer can be placed in a job in
this country if he is not fluent in English. Fluency in
English is a prerequisite for entrance to the course.
But being fluent in English and being comfortable in
English are two different things. During the 1969 Youth
Corps course we found that several of our Chicano
students became much more interested and did much
better work when problems were available bi-lingually
and when instructors showed a willingness to use
Spanish. It is clear that even students who when given
a choice frequently use the English version of problems
nevertheless appreciate having the Spanish version
Introduction to the basic logical
Figure 3-Neighborhood Youth Corps students from the eight
week pilot course run during the summer of 1969
sists of a carefully graduated sequence of problems designed to be as familiar and interesting to the student as
possible. The order of presentation of basic FORTRAN
instruction in the first third of the course is:
I.
II.
III.
IV.
V.
VI.
as
Ui'. L<; POSITIVE')
CONTI;\;UE
IF (NUZ" Z.:-;SUM) Zil. ZZl:. Z IZ
• •
In this t:iUH' If NUZ·'l-"'SUM IN· U('1t411vt', lllC' IHO,:t"'cUlI
zero it ~U"S to lll. and if it is positlvc It J.:"e·!t tel l \Z.
J.t(J(·S to
ZIZ, If it is
Sonl(' fric'nds, of yuurtl who art' pub1i!thanJ: oJ, nc.·wspapt'r for the BI ... \.k, and
Chica.lu':. ,·Ulllnlumtac',. hav(' h'arnt·d that yuu oar..' oil prul!ranlOu'r .. iHI hav,' a~kcd
you tn h"lp t~ ..'tn autulnat,· tlu- b,lhng" and re, ord. for th,-u adv(·rt1:it:·nlt.·nts.
I.
Flowchart y escribe un pro~r3ma qu,,· V3)'3 a r~ad tn la" t .. rU.1s de cambia
desde las tarj~tas (as,,~guratc d ...• qUl~ tl'Rt:as-.-a-;'--t-arj ..·tas c.'n ordl'n ('orrecto). Despuc"s-t rcad in un pr':-cio en dolares :mc.'ricano$ y un ni.rri... ro
de co'digo que cspccifuat..·l raIs qu ..· tu quicre::>, y wrih' out ..,1 p ... (>do
equivalente en 1a moncd3 d-.·} pOlis es('ogido.
----
•
Ad~c'rhli('nl\-lits .1rc· suld by th,' , .. Iuum ind).
1 hc.· ra.h' i5 SZ. SO p('tr
column in(·h for tht· f,rtit S ",du'6, $l.OO V..'r (·oluum lnc.:h fo·r all spat·t.'
bc.·yund; Inc,h,,!t. Flu\~'(hart .and-wrIte.· a pJ'ugr.uli ",-,:hJch wIn f('ad m the:
ai7.(· tll ... n -adv,·rusrlllc.'ni In c.:ulutnn Inc. he'::> II'"'Ull tht- kc.'rb{1ard and ~YPl· i)ut
th,' pru·c.', Wrlt,·,the prOJ.!rdrn lUI tlM-t It WIll c.·cmUnUt' to IHop back ~nd r(·ad
in n",w nUlllbc..'rs lur as lout: .. s yuu·wlsh.
•
• •
•
•
U NUZ is n('~ati.Y(· tilt' progranl jUlups to LOt JI It is 7.e·", it jUlups to l4, If it
i. PUI.a II v.' it junlps tn lH. 10 plac,' of ~UZ you ..:an put SUIll" l"XI"~('SSlon bk,,·:
d~larC'6
La compania haec 1.1 mayor parte de su nC'gocio con cinco pa{sl's:
1) ~tcxico, 2) Francia, 3) Alemania, 4) Brazil, y ~) (;tlan.1.. I.as tarifas
de cambio de estos pals('s SE' cncuentran en tar jet as (>n 1.. siguh'nte
forma
111··1-0
The IF Htatcnwnl is .L FOltTltAN jn~trudJOn to allt:r tIl(' opc· ...... holls- th.tt ...
prugraln performs dl'pc'ntling upun till' (·ondlt!Clns whit II ... "ist. flc-rt· JS ,I
Sinl))l ..• t·xanlph' usillA til(' H'stah'lnt.'nt! A pro~ri.ull t Otllputc's til(' v ... lu,- of
NUZ. 1'hc l>roAr,;ulUllC'r W.Ul15 tu knuw if til(' valuc' of NUZ is nq,:atlvc. ·1.c'ro,
or positiyr. lit· wrilt,s:
I'csos! $ t:.U.
Cruzeiros! $ F..U.
Sucre! $ E.U.
Francos! $ E.U.
Deutsch" H.nea/ $ E.U.
Cedls! $ E.U.
Pcsos! $ E.U.
Dlrhan! $ t:.U.
Gulld.rs! $ E.U.
Soles} $ L.U.
Libras! $ F..U.
Libra cst.rHn.! $ E.U.
1.
t
prnhlt·tn numlu'r
11-6-0
Est.1S empIcado como programador por "Oradhy Imports Inc. ," unil compaii!a
que haec ncgocio con cmprC"sas cn Europa, Africa y Anu!rlca Latina. t:n
cstc moml'nto, 13 comp.1ilia th'nc (,Ul~nt3s aettvas en 12 pa{s(>s quI..' ticnen
las siF,uicntcs tarifas de cambio.
ArgentinO!
Brazil
Ecuador
Francia
Alemania
Ghana
Mexico
Harruecos
I
pal~(' I of
2
I
pac" I of
prohl.,," "uml,,",
•
palle I of
I
UI. \.u
You have saved up enou,::h mORry to tT(,,,t yuurs"l1 tu chnnc.·r tlut. II yuu It.IV,'
$5.00 or more you (-an go- tt) Sish'r PCC'W(,(·I S ; If yuu h., ..-c.' $l. 00 Clr mv,.,. yuu
can go to Huifnlanls Barbt.'qur for c:hithnls .tnd J:f(· ..·ns;·if yuu hay ..· $1.00 ur
more, you can go tn l\,·1ac Donaluls fur a hamburJ:('r; it ~'CJU h.lVC.' lc.·ss th.1ll .,
dollar, you have to cat at honle. Fill in the flowchart beluw and Wrltc a pru-
,um
0
'0 '" ~, .,"',.
I
prob) ... ,... 11111'11bc.·J'
• •
111-8-0
\U·'·1I lur, d til lu 11) .,\It'''II_.I. th ..· lIo •• II':, rc· ..·urd:. HI ol c,h:icount storc.
'Iht- ".th·:-. In.ll1·H':1 r tJ.. , .. I~IOI- uncI. r:.I.lI'cI tit" Itlu .. h ... bout lUInpUl(.'rs and proItr.:uununJ!" .. IHI " 0 ":0. .. ,"uII,.I,· .·,.uni'll· ¥tJU otrt' ):"Ina! 10 ""rill' hun a program
th •• t wall mo'Io.:.,' lin ''''''I,uh'r \\ur" II"'· .a ..... ,)' ... n"y ,·.uh rtoJ:lster.
,"Ull h.IY.·
•
Yuu "'·.ant- tCt tH' •• blt- 10 I'"(·,H' HI tlu· pru c,' of .1 numbt'r of it('n1l. Coml)ute thC' tax
un lh., ,.a".tbl. tit In!to .•• rod th, n .. ,Id Ih,r:):!to .. II up t.~ 'It:urC' (Jut huw nlul-h the
(:uatunu-, ., ....... )'IU,
,.151' ",.tlll I I ' ttt.:urt' Ilut huw til-lily t:,C'en stanlpS to
It'v,' hun. ,.,,1.£ "'·.lnt til ri .. tln1'> ....·.. r .. nd !lv,'r ... t:~HI lor ,·.aeh (·ustomer.
'.,u
Il.
In add,tI"n. )UU ......
thc.· lut .. 1 ~ "!'oil !to .• h ..
I I
C·f. tr ... ~ k ot thc.· tCJt~1 • .:as coUc,"H.. d during the day, and
I. h • ,'h t.:",) of Itc'nl:
t .. ~01
If!
I
~
Ih·n)
.l.!.!.
'oud.
hq-..".r
non~
Isr..
at.atlulI ..".,.
h.rdw.r.
("loth.n,
•
• •
"",.. '6 • ah p by
att p ,II,., "phltn uf huw your
S~.
~"4
Sf.
prolr~nl
Ihould work:
ud.' ... lId vrH ~ ul .. Ol..:h .t~m.
1.
Typc.·
l.
Wh .. n yHU- h.v .. t'ntt· re'd All the' ''''n16. "lAke." the 'progranl write out the total
p",.c.::h ... " pra'"" th~
tlnd the" numb.r 01 ,re~n .tamps (one stamp for
~ach lOt p •• d IO-r pUh·h.at'. lc.·sa th,an $10.00. double that if you buy more
thAn $10.00, tor th .. ul~.
1.
ThC' prOar.nl IO-e-I b.,-·k .nd II r(".d.,. to work on the next
purch •• (' ••
4.
At the cmd of the day you In.ak ... lht' p'Olr&l.nl writ·" out:
In
till'
t
'.x.
•
custonlC~r's
The total 01 aU pur( holst'S tnAd", that day in each llf the 5 categories
•• We'll i l l the.' tot .. l ... Ito'. fur all t.'"liot"goncs.
f
•
o
1
b.
The t.otai of ,all taxe. paid th..lt
Thi. problenl i. ,a Jittl,' 'rlc.'ky.
you try to code the prugraln •
~ .. y.
Bc.· 5llre to dt'sian a (·orrc'ct nowchart before
• •
Figure 5-Typical problems from the early stages of the course. All early problems are available in English
on one side of the page and Spanish on the other
•
Computer Jobs Through Training
available and feel more relaxed in the course as a consequence.
A few examples of some of the early problems for the
CJTT curriculum are given in Figure 5. Along with these
problems, brief non-credit drill sheets are used massively
in the early portions of the course. Unfortunately it is
not possible in the written version of this paper to give
a proper impression of the 35mm slides which have been
developed to accompany the course. This will be attempted in the oral version of the paper.
A knowledge of digital logic is hardly prerequisite to
most programming jobs, though it does make some of
the fine points of programming more intelligible. But
hardware can serve as an excellent motivational tool.
We explain to our students that computers are complicated in just the way that a house is complicated. The
bricks, nails, and boards which make up a house are
conceptually simple. It is only when thousands of them
are combined in a building that you end up with something that is complicated. In much the same way,
AND-gates, OR-gates and flip-flops are logically simple
devices. It is only when thousands are wired together to
make a computer that you end up with a complicated
system.
We introduce hardware with as little talk about actual
circuit elements and abstract symbolism as possible.
The AND gate is introduced with a demonstration
which solves the problem "if it's sunny AND your friend
can come, you can go to the beach." The truth table is
worked
out in terms of English:
1
is sun out?
can friend come?
do you go?
no
no
yes
yes
no
yes
no
yes
no
no
no
yes
Once such a truth table is introduced for several simple
problems, the jump to more abstract levels of binary
notation is not too difficult. Likewise, more complex
circuit configurations such as two AND gates with their
outputs ORed together are used to solve day to day
problems. For example the circuit:
caD/::~:o
friend
c::>
weekend/not weekend
go/don't go to beach
action/no action at home
solves the problem, "it it's sunny AND your friend can
351
Figure 6-A student wires a simple circuit with one of the
digital logic plug boards
come OR if it's the weekend AND there's no action at
home, you go to the beach".
In keeping with the hands-on philosophy of the project, individual logic plug boards which will allow each
student to work up his own circuits have been developed
as shown in Figure 6. The development of this equipment has been made possible with a grant of T -series
logic from Xerox Data Systems.
To conclude the hardware unit there is a final class
project. In an introductory class for engineers, the class
might build tape controllers, parallel to serial converters,
or similar devices. Many of our students find such examples rather unexciting. Instead, we have chosen a
problem which is technically just as demanding, but
which is substantially less abstract. A model N-guage
rapid transit system for the city of San Diego has been
built and outfitted with appropriate micro-switches
which provide information on the trains at all times. The
set up is shown in Figure 7. The class is asked as a group
to develop the control logic necessary to automate the
system.
With this hardware background, an introduction to
machine organization and the fundamental ideas of as-
352
Fall Joint Computer Conference, 1970
they can develop a feel for the comparative strengths of
the two languages.
Well before the end of the course it is clear which
students are doing well enough for job placement. When
these students complete the course they enter a Terminal Workshop of intensive full-time training for a
period of about seven weeks which prepares them for
their job. If the potential employer has indicated that
he requires specific skills, such as COBOL proficiency
or extensive magnetic tape experience, these are emphasized. The Terminal Workshop is run at the UCSD
Computer Center and at nearby Gulf General Atomic.
Though we have serious financial difficulties, it is our
intention that all students who require financial assistance during this full time terminal workshop period will
receive a stipend.
Job placement
lflgure
'I-~tudent
staff member, Belton Flournoy, works on the
development of the model rapid transit system
l::leIIlbly language programming follow in a natural way.
We teach no specific assembly languages in this course,
but we do try to give our students a good idea of how an
assembly language works so that if later he must learn
one he will know what is going on.
The tab equipment unit is designed to give students
a very brief introduction-it is not designed to train
experts. We quickly outline the use of the program drum
on the keypunch and then briefly introduce and use the
sorter and accounting machine. The project has acquired 62 surplus type 910 control boards so that each
student is able to wire one simple listing problem.
As indicated in Figure 4 the middle third of the formal
portion of the course is devoted to more advanced programming concepts such as file organization and maintenance, extensive use of subroutines, and similar techniques which are required for simple system work. The
final third of the formal curriculum introduces COBOL.
This portion of the course involves few new logical
ideas. Indeed, students do many of the same problems
that they have already worked in FORTRAN, so that
It is not sufficient in a project such as this one to
count simple placement in a programming job as success. What counts of course is the number of people
who continue to work in: the field long after initial placement. In order to minimize difficulties in the early
months after placement our students will be followed
carefully once they are out on the job by a Placement
Aide who will try to detect difficulties, either of a social
or technical nature, well before they become serious,
and take the necessary corrective action.
Our first course for young adults got under way in
February 19'70 on a nighttime basis. We made arrangements with local employers for placement of the modest
number of graduates that we expected from this first
course before the course began. However it is not reasonable to expect to get massive commitments for placement for many students before a project such as ours
has produced its first graduates. Programmers are not
plumbers' aides. While industry will commit itself to
hire large numbers of low entry level people from training programs, any reasonable employer will insist on
seeing the quality of the graduate before he commits
himself to hiring someone like a programmer.
To sell the project to employers we are using the mobile aspect of our facility-setting up in a potential
employer's parking lot with the van and a number of
our students and asking the employer to come have a
look at what we are doing. We are also seeking employers' commitments to hire our graduates through
local organizations such as the Urban Coalition. At
the time of this writing the first full adult class has not
yet been graduated. Further details on the placement
aspects of the project will be provided in the oral version
of the paper.
Computer Jobs Through Training
Other aspects of the CJTT program
While job training is the principal objective of the
CJTT project, the two Youth Corps classes that we ran
during the summers of 1968 and 1969 were valuable in
their own right as courses which stimulated and motivated disadvantaged high school students toward further education and careers in computer science or in
other technical fields. We have been operating with a
small staff and a very small budget, and this together
with the fact that our primary objective has been organizing the job training project has prevented a careful systematic follow-up on all of the NYC students.
However, judging from those students with whom we
have maintained contact, the courses have had a significant impact.
During the summer of 1970 we have made more
formal arrangements to continue this motivational type
of instruction for high school students. With financial
support from the San Diego Unified Schools we are
running three special motivational classes for credit as
part of the city school's summer session. These classes,
two for high school students, one for entering seventh
graders, are being conducted in schools with very high
enrollments of disadvantaged youths. The instruction
is being done by four UCSD Black and Chicano undergraduates who are majoring in computer science. Progress in these classes has been excellent and we expect
to expand our in-school activities.
CONCLUSION
We have restricted ourselves in this paper to a straightforward description of the CJTT project but it would
not be proper to conclude without giving some indication of the very serious financial difficulties that we have
encountered. On the local UCSD campus we have received strong moral and financial support from Professor Kenneth L. Bowles who directs the Computer
Center and Professor Henry G. Booker, Chairman of
the Department of Applied Physics and Information
Science. Outside of this support, which had totaled just
under $40,000 by July of 1970, we have pieced together
an additional $40,000 from dozens ,of separate sources,
most of which are listed in the acknowledgments.
Much of this $80,000 of support which had been
organized as of July 1970 was in-kind assistance. With
t.his support the CJTT project has accomplished what
by normal University operating methods would have
cost slightly more than $150,000. This savings did not
come easily. It results from substituting labor for capital.
It was accomplished at times by turning highly qualified
programmers into painters and carpenters; by scroung-
353
ing used electrical conduit from old buildings about to be
razed; scrounging lumber from construction. site foremen; putting Ph.D.s to work doing carpentry and digging telephone pole holes.
Despite more than a year of strenuous salesmanship
and much proposal writing, the project had still not received any State or Federal anti-poverty monies as of
July 1970. Our evaluation of the funding situation is
that this experience is not unique, that others planning
similar programs can anticipate similar very serious
funding difficulties unless they can find strong sources of
local or private financial support.
Our estimated costs are roughly $150,000 per year or
just over $3,000 per student placed. Something like 80
percent of this cost is for salaries. No student stipend
costs are included in these figures. While we began this
work with great optimism, our experience to date has
led us to seriously question whether long term funding
of this magnitude can be organized. There is much talk
in the country about how important it is to do this sort
of thing but not very much money to do it. Future
workers would do well to explore the financial climate
with great care before launching new projects.
REFERENCES
1 While a number of workers have undertaken projects in
this field, the literature is still very spotty. A review of some
of these projects is available in:
DB MAYER
The involved generation-Computing people and the
disadvantaged
AAPS Proceedings of the Fall Joint Computer Conference
1969 p 679
In addition to the work reviewed in Mayer's paper we are
aware of work undertaken by:
R BELLMAN J BLOOD C FORD-LIVENE
Project Soul: Computer training for high school students
from disadvantaged areas
University of Southern California Technical Report
UCSEE-375 November 1969
T I BARTHA
Computer programmer training program
Report of the Computer Education and Research Center
Pratt Institute Brooklyn New York 11205
L H HARRIS
of Shell Development Corporation (P. O. Box 481) in
Houston, Texas, has run a training program for a number
of years.
ACKNOWLEDGMENTS
We wish to acknowledge the invaluable assistance of
Kenneth Bowles, Henry Booker, Jack Douglass, Frank
354
Fall Joint Computer Conference, 1970
Saiz, Roy Cazares, Ken Hicks, Qneeta Alexander and
Bob Sadler of the UCSD staff,along with the assistance
of many UCSD undergraduates and Neighborhood
Youth Corps students of whom Belton Flournoy, Susan
Halfon, Calvin Manson, Beverly Andrews, and Boyd
Pearson deserve special mention.
In addition, we gratefully acknowledge the financial
assistance of the University of California, The Rosenberg Foundation, Gulf General Atomic, Safeway Stores,
Xerox Data Systems, Montgomery Ward, Bekins Van
Lines, Pacific Gas and Electric, Pacific Telephone, and
other local supporters.
Technical and human engineering problems in
connecting terminals to a time-sharing system
J.
:F.
OSSANNA
Bell Telephone Laboratories, Inc.
Murray Hill, New Jersey
and
J. H. SALTZER
Massachusetts Institute of Technology
Cambridge, Massachusetts
ideas expressed here are the outgrowth of experience
obtained during the growth and use of Project MAC's
CTSS system 3 ,4 and during the development of
J\1ultics. 5
Good user performance becomes possible when the
user can easily and rapidly do what he wants to do.
Consequently, many of the human engineering factors
to be discussed relate to the user's ability to provide
input as rapidly as desired, to control output, and to
avoid unnecessary interaction.
First, we will discuss input/output strategies, since
they broadly affect most of the other areas to be
covered. Then we will discuss in turn, terminal features,
the terminal control hardware, and the terminal control
software-working from the user into the system.
Finally, we will briefly mention character sets and
character stream processing.
INTRODUCTION
Today, an increasing number of computer systems are
used interactively by their user communities. Interactive use of computers, involving more prolonged
man-machine contact than non-interactive use, requires
a well human engineered user-system interface. The
interactive user's performance-his rate of doing work
and his ability and desire to utilize system capability-is
a sensitive function of the success of this human
engineering. In turn, the computer system's effectiveness
depends on achieving a satisfactory level of user
performance with reasonable efficiency.
This paper will be concerned with the human
engineering of connecting typewriter-like terminals to
general purpose time-sharing systems. Examples of such
systems are Digital Equipment's 10/50 system for the
PDP-lO, IBM's Time-Sharing System for the 360/67,
the Dartmouth Time-Sharing System, and the Multics
system at MIT. Such systems are used by a wide range
of users doing many kinds of work. Typewriter-like
terminals constitute. the majority of general-purpose
remote terminals in use today; examples are the
Model 37 teletypewriter! and the IBIVI Model 2741. 2
Although more complex terminals, such as those
providing true graphical capability, are not specifically
treated, many of the factors to be discussed apply to
them. The special behavior and needs of specialized
systems are not treated, but some of the ideas presented
will apply in individual cases.
Value judgments about human engineering factors
always involve a degree of individual taste which in turn
depends in part on individual experience. J\1any of the
INPUT/OUTPUT STRATEGIES
The user's input consists of system commands,
requests to programs, data, answers, etc. From the
user's point of view, input can be divided into components according to whether or not it is expected that
the component will cause output to occur. Some input is
expected to cause output to occur-for example, a
command to list a file directory. Other input may be
expected to cause output only conditionally; for
example, a command to rename a file may output an
error comment only if the named file doesn't exist. Still
other input may be expected to cause no output-for
example, continuous text input into an editor.
355
356
Fall Joint Computer Conference, 1970
From the system's point of view, the user's input can
be considered a character stream containing certain
characters indicating that action should be taken. In
the common line-by-line input case, a return or new-line
character is the only action character. In general, there
may be a number of action characters. In certain
applications treating all characters as action characters
may be .appropriate. The user ordinarily should know
what action characters are currently in effect, since
typing dne of them initiates execution, which may in
turn cause output.
The human engineering problem in collecting a user's
input arises primarily because the user frequently knows
much of what his input is to be well in advance. He may
know the next several commands or the next several
editing requests he wishes to input. In general, the
components of this known-in-advance input can fall
into all three output relationship classifications.
Although the user often knows when to expect output,
the system cannot.
The user should not be unnecessarily prevented from
providing such input as fast as he can think of it and can
type it. By collecting input asynchronously rather than
synchronously with respect to the system's utilization
of the input, the user and the computer can work
asynchronously and in parallel rather than synchronously and serially.
There are four mechanisms that can individually or
collectively facilitate providing input.
First, input can be collected whenever there is no
output occurring. If the operation is full-duplex, * it is
even possible to collect input while output is occurring.
The typing of action characters should trigger program
execution but not inhibit further input. Such asynchronous collection of input is usually referred to as
read-ahead or type-ahead. A number of present day
systems 4 ,5 provide a read-ahead strategy.
Read-ahead permits overlap of input with both
system response time and program execution. Also, it
permits programs such as text editors to gather text
'input continuously. Because erroneous input may be
encountered, programs must be able to produce
conditional output and also discard existing read-ahead
to prevent compounding of errors.
A second mechanism is to allow more than one
independent input component between action characters. For example, a system using new-line as an
action character should permit more than one command
* In full-duplex operation, transmission can occur independently
in both directions. This requires independent keyboard and
printer operation at the terminal, as well as independent input
and output at the computer. The modems (or data sets) typically
used to connect the kind of typewriter being discussed to the
telephone line ordinarily provide full-duplex transmission.
on a line. Editors in such a system should permit more
than one editor request per line. This outlook should
pervade every level of programming.
Third, commands and other programs should be
designed to avoid unnecessary interaction. One aid in
doing this is to allow the typing of arguments to a
command on the same line as the name of the command.
For example, typing "edit zilch" is preferable to typing
only "edit" and later answering the question,
"Filename"? Default parameter values can frequently
be assumed in the absence of typed arguments. Permitting both multiple commands and arguments enables
various schemes for inputting factored command and
argument sequences. 5
Fourth, it is convenient if the user can create a file
containing potential input and subsequently cause the
system to take input from this file.
The use of these mechanisms can also improve
system efficiency by reducing the number of separate
program executions, since the program may find more
input and be able to do more work during each
execution.
The user should have reasonable control over his
output. For example, whenever a stream of unwanted
output occurs, it should be possible to stop it without
undesirable side effects, such as losing too much of the
results of immediately previous interactions. An interrupt mechanism, such as that detailed later, can be
used to stop the output, cause execution to halt, and
discard any read-ahead. If the system allows an
interrupted program to catch the user's interrupt signal,
a program desiring an extra degree of sophistication can
be designed to recover from various conditions such as
unintended execution loops or unwanted output due to
unwise input. User control over output code conversion
is desirable and will be discussed later. The ability for
the user to direct program output to destination(s)
other than his terminal is quite useful. For example, the
output from a program which generates a large volume
of output can usefully be directed to a file for later
printing.
REMOTE TERMINAL CHARACTERISTICS
An excellent treatment of features desirable In
typerwriter-like terminals can be found in Reference 6.
We will treat here certain important terminal design
features which strongly affect the system designer's
ability to human engineer the system-user interface.
A typewriter may be viewed as a collection of data
sources-the keyboard, the receive-data lead of the
modem or data set, and possibly a paper-tape readerand data sinks-the printer, a control detector, the
Technical and Human Engineering Problems
DATA SET
Receive
Send
Data
Data
PRINTER
CONTROL
TAPE
DETECTOR L~~-----::l,L--""---:~OU-""1 READER
TAPE
PUNCH
Figure (la)-Typewriter data sources and sinks and possible
interconnections
send-data lead of the data set, and possibly a paper-tape
punch. Figure CIa) shows such a collection and possible
interconnections. Flexible user and/or system control
over these source-sink interconnections permits implementation of various input/output strategies.
As a specific example, Figure CIb) shows the interconnection control of a Model 37KSR teletypewriter.
Control of the switches occurs by detection of control
character sequences by the control detector associated
with the printer. The interrupt detector and generator
are discussed below. When the keyboard-to-printer
connection is closed the terminal is in half-duplex mode
and local printing of keyboarded data occurs. When this
connection is open the terminal is in full-duplex mode,
and the relationship between keyboarded data and
printed copy is under control of the computer system.
One common use of the full-duplex mode is to collect
passwords without printing them. The full-duplex mode
allows the printed characters to be simple mappings,
or even arbitrarily elaborate functions, of the keyboarded
characters. The ability to lock and unlock the keyboard
allows the system to constrain the user to type only
when input is able to be collected by the system.
The program interrupt ability previously mentioned
can be achieved by full-duplex operation of both the
terminal and computer, which permits an interruptimplying character to be typed at any time. Another
method, which does not require full-duplex operation,
is the "line-break" technique, * where an always
generatable unique signal can be transmitted. In
addition, the ability of the terminal to respond to a
break or interrupt signal from the computer regardless
* The "line-break" or "break" signal usually consists of approximately 200 milliseconds of "space" ("0" bits). This is distinguishable from ordinary characters and is easily detected independently
without the necessity of being able to receive characters.
357
of its state provides a method of restoring the terminal
to a desired state-typically ready to receive control or
text information. As an example, the 1Vlodel 37 responds
to a break by locking the keyboard; the Model 37 break
generator and detector are shown in Figure (Ib).
The system should be able to maintain knowledge of
and control over the states of the terminal. In particular,
the system should be able to force the terminal into a
state where the system can print on the terminal
without user interference. As many terminal actions as
possible-for example, those causing carriage and paper
motion, color shift, source-sink interconnectionsshould be initiated by character sequences whether
terminal or computer generated. This implies that the
character set used should be sufficiently rich in control
characters.
The terminal should not inherently hinder implementation of a read-ahead strategy. For example, the
keyboard should not lock automatically after the
typing of what the terminal assumes is an action
character, such as at the end of a line; such terminal
behavior is a violation of a general rule that the terminal
shouldn't try to "outguess the software."6 When a
system controls input by keyboard locking the user
should know when the keyboard is usable without
having to test it. For example, the Model 37 lights a
"proceed" lamp when the keyboard is unlocked. Using
a "new-line" function (combined carriage-return and
line-feed) is simpler for both man and machine than
requiring both functions for starting a new line; the
American National Standard X3.4-1968 7 permits the
line-feed code to carry the new-line meaning. The
terminal should have adequate functions for speeding
up both input and output. Horizontal tabs are essential,
form feed and vertical tabs are useful. They are the most
useful when the user can easily set the stops himself
DATA SET
Receive
Send-
Data
Data
BREAK
DETECTOR
CONTROL
DETECTOR
Figure (lb)-Model 37KSR teletypewriter interconnections
358
Fall Joint Computer Conference, 1970
using control character sequences; this is possible in
some present day terminals.! ,8
When a terminal has reached the system via a
switched telephone network, the system may not
a priori know anything about the calling terminal, and
it can be useful if the terminal can send an identification
sequence to the system upon demand. This sequence
can be used to uniquely identify the terminal, to
determine the terminal type, and to indicate terminal
options. The Model 37 answer-back scheme is an
example of a more than adequate identification. The
economic advantage of having different terminal types
statistically share computer ports is a strong motivation
for the system to be able to experimentally determine
the terminal type. It is necessary only that each
terminal to be supported be able to respond to a
transmission from the system and that either the
transmission or the response be unique. Multics currently supports four types of terminals and determines
which type by performing an experiment involving
identification responses.
The Model 37 teletypewriter and the Genera] Electric
TermiNet-3008 (Registered Trade Mark of the General
Electric Company) provide nearly all of the abovementioned features. Consider the standard version of
IBM's ~10del 27412 terminal, which is widely used as a
time-sharing terminal. This terminal can only be used
in the half-duplex mode, so there is no way to inhibit
direct local copy or to exploit full-duplex operation. The
terminal cannot be interrupted by the system while the
keyboard is unlocked; thus the system can't force the
termin~l to accept output while the user is able to type.
This property makes read-ahead a somewhat dangerous
strategy, since conditional output is impossible while
the user is able to type. The keyboard locks as a result
of typing "return" (new-line), and requires the system
to respond and unlock the keyboard before the user can
proceed. Even with instant system response, the delay
before typing can continue (caused by the transmission
of control characters) is noticeable, so that any readahead strategy is degraded. No keyboard-unlocked
indication is provided for the user. Adding an identification mechanism, enabling interrupt to be always
generatable and receivable, adding a local-copy suppress
mode, and eliminating the automatic keyboard lock, are
possible modifications; unfortuna~ely, as is characteristic
of post-initial design changes, they add significant cost.
program controller; the other is the hard-wired controller operated directly by the main computer. The
major difference between these in practice is in the way
the control software is modularized. The various
functions to be performed by the terminal control
hardware and software together can be divided between
them almost arbitrarily. The decisions made when
allocating logic between a main machine control program and a hard-wired or stored-program controller
involve a variety of economic and other management
considerations; it is not our intention here to discuss
relative virtues of hard-wired and stored-program
controllers. In either case, if the controller provides a
primitive but complete set of functions, the terminal
control program in the main computer can assume
primary logistic control over the terminals. Such a
controller is assumed in the following discussion, which
describes suitable controller functions.
Because it may be safely assumed that new and better
terminals will continue to be introduced, the terminal
controller should be flexible enough to permit operating
these new terminals with minimum modification.
Specifically, parameters such as the number of bits per
character, the character parity, and the bit rate should
be program controllable or at least field modifiable. At
any given time, there are usually several terminal types
worth supporting. The controller must be able to
handle the corresponding variety of line control
READ START SEQUENCE
1. SET TRANSMIT MODE.
2. TRANSMIT LITERAL "EOT" CHARACTER.
3. SET READ MODE.
4. READ ONE CHARACTER (SWALLOW "EOA" CHARACTER).
s.
SET ACTION CHARACTER LIST TO (JUST) NEW-LINE.
6. TRANSFER TO READ SEQUENCE.
READ SEQUENCE
7. READ INTO BUFFER 1.
S. READ INTO BUFFER 2.
9. TRANSFER TO KEYBOARD-LOCKING SEQUENCE.
KEYBOARD-LOCKING SEQUENCE
COIVIPUTER SYSTEJVI TERMINAL CONTROL
HARDWARE
lO~
SET TRANSMIT MODE.
11. TRANSMIT LITERAL "BREAK" SIGNAL.
12. STOP.
The terminal control hardware used today broadly
falls into two categories. One is the peripheral stored-
Figure 2-Command list to read the keyboard of an IBM 2741
Technical and Human Engineering Problems
requirements without undue programming effort and
without undue main processor intervention; this implies
suitable controller command chaining, which is descri bed later.
When terminals reach the system via a switched
telephone network, the system needs to be fully aware
of call-ins, disconnects, and line failures. Thus the
controller should make available to the software all
status available from the modem or data set, and allow
the system to enable interrupts for status changes.
Similarly, the controller should allow the system to set
all the control leads of the data set, so the system can
control data set answering, make lines in hunt groups
appear busy, and initiate disconnects. Such control
allows the system to disabJe improperly working lines
and to exercise system load control.
Certain terminal functions (tabs, form-feed, new-line,
etc.), require that a delay sufficient for completion
follow its initiation. If this delay is provided by the
inclusion of "fill" characters (causing no terminal
action), only the needed number should be transmitted.
Experience suggests that accurate delay calculation,
providing only the actual delay necessary, speeds up
output and gives the system a smoother and speedier
image. * Preferably, delays should be calculated to the
nearest bit time rather than to the nearest character
time.
An important controller feature is the ability to act
on a list of queued "commands" from the control
software. The command repertoire should include
commands to set controller and data set modes, obtain
controller and data set status, transmit from a buffer,
read into a buffer, transmit a literal bit string, and
transfer to another command. The tandem execution of
two or more read or write commands is usually called
"data chaining." The tandem execution of a list of mixed
read and write commands is usually called "command
chaining." A transfer command allows the list to be
conveniently built of sublists and dynamically threaded
together. The ability to transmit literal bit strings allows
the transmission of delays (all Is), breaks (all Os), and
canned control character sequences.
The ability to data chain while reading is an important help in allowing continuous input, because it
allows a more relaxed software response to an exhausted
buffer. To simplify buffer management, the controller
should be able to interrupt on an action character but
continue reading sequentially into the same buffer; an
interrupt should also occur on data-chaining to alert the
* This effect was noticed during the early deveiopment and use
of Project MAC's CTSS. S~bsequently on both CTSS and
Multics, users quickly noticed longer-than-needed delays on new
terminals or due to untuned new software.
359
software of an exhausted buffer. It is useful if the action
character(s) detected can be dynamically set by the
software. If the action character(s) can be associated
with each individual read command and the action to
be taken individually specified, the ability to chain a
list of mixed read and write commands permits handling
a variety of terminal types and the design of good
read-ahead strategies. The detection of a received
"break" signal should halt the controller and cause an
interrupt.
Figure 2 shows a hypothetical command list similar
to lists implemented in Multics. The list illustrates
reading the keyboard of an IBM 2741 (modified to
accept break signals), and employs several sublistK
After an interrupt from the controller indicating the
exhaustion of buffer one, the control software would
ordinarily replace the transfer in step 9 with a transfer
to another read sequence. The keyboard-locking
sequence stops input should the system fail to obtain
another buffer prior to exhaustion of buffer two.
General Electric's General Input/Output Controller
(GIOC) used with the GE 645 system (on which Multics
is implemented) is an example of a communication
controller that provides most of the above-mentioned
controller functions. Reference 9 describes the design
of the GIOC.
TERMINAL CONTROL SOFTWARE
The following discussion will be concerned with
terminal control software in a main computer using a
flexible terminal controller. We will discuss the need for
flexibility of design and operation, the implementation
of input/output strategies, some of the responsibilities
to other system software, and a little about the interface
tq user programs.
The maj or areas where flexibility is important in
terminal control software are the ability to operate
various terminal types, and the ability to adapt to the
variable behavior and needs of users.
The advantages of being able to operate a variety of
terminals are: (1) freedom from dependence on one
terminal supplier; (2) ability to take advantage of newer
terminals; (3) user access to terminal features not all
found on one terminal; and (4) satisfaction of individual
user needs and preferences. The ability to operate
various terminals and to easily extend operation to new
terminals requires a flexible and convenient method for
converting between internal system character codes and
physical device codes, and for handling the different
kinds of terminal control.
If the terminal control software is designed to· be
driven by a collection of tables, it should be possible to
360
Fall Joint Computer Conference, 1970
embed device differences and perhaps user options in
the tables rather than in the harder-to-change program.
Flexibility and extensibility can be achieved by
sufficient ingenuity in choosing what information is to
be relegated to tables. The generality required in such
tables depends on the range of terminals to be controlled.
Control driving tables can include the following:
1. Input and output code conversion tables.
2. Device parameter tables.
3. Tables of controller command sequences for
identifying and operating the various devices.
The system-device code mappings contained in the
code conversion tables would include suitable "escape"
character sequences for handling system-defined characters not present on some terminals. * Also, additional
tables could be provided for alternative conversion
modes on the same terminal, ** and to accommodate, for
example, the user who wants to use a non-standard
print element on an IBM Model 2741 or an extendedcharacter type-box on a Model 37 teletypewriter.
The device parameter table would contain such
information as default action characters, default output
line overflow length, default code conversion table name
.
'
carnage return speed for delay calculations, character
parity, etc.
The operating command sequence information includes sequences for initiating a write, writing, terminating a write, initiating a read, etc. The identification
command sequences are the ones used for terminal type
determination; often the terminal identification code is
obtained as a by-product of type determination.
If the hardware controller can interrupt on an action
character and otherwise continue, then only a small
fixed buffer space need be associated with each active
terminal-that needed for current physical input/
output by the controller. All other buffer space can be
pooled and assigned to individual terminals on demand.
A simple read-ahead strategy can· be implemented by
copying input characters from physical collection buffers
at action character interrupt time into a linked list of
input buffers obtained dynamically from the buffer
pool. When the user program requests input, the input
is taken from the user's input buffer list. Similar buffer
schemes have been long used for handling devices such
* For example, the sequence "¢ <" could be used to represent
a "[" on an IBM 2741,10
** If the default mode utilizes escape sequences for missing
characters, an alternative mode could print blanks for such
characters to permit inking them in.
as magnetic tapes, but are not often seen used for
terminal control.
Similarly, a user program's output can be copied into
a dynamically grown buffer list. Physical output occurs
by refilling from the output list the physical buffer
associated· with each terminal every time its contents
have been output. With half-duplex operation, emptying
the output list should reinstate read-ahead. Letting a
user program emit substantial output before suspending
its execution (referred to as permitting write-behind)
usually improves system efficiency by reducing the
number of separate program executions. Physical output
should be initiated as soon as there is any, and not
delayed perhaps waiting for a buffer to fill. Aside from
distorting the sense of program progress, such output
delay can make program debugging very difficult. For
example, debugging often involves inserting additional
output statements in various program branches to
obtain flow information. It is misleading not to see this
flow information prior to a program entering an
unintended loop, because of inappropriate output delay.
Of course, reasonable limits must be put on how much
read-ahead and write-behind is permitted, lest a single
user or his program seize all available buffers. Adequate
total buffer space should exist to cover reasonable
fluctuations in total demand. Algorithms to limit the
buffer space that can be claimed by one user should be
generous when conditions permit to avoid losing the
advantages of read-ahead and write-behind. During
peaks in total demand that tax the available space, these
algorithms should be graceful1y restrictive. Some
successful limiting algorithms 4 involve allowing each
user to accumulate a fixed fraction of either the total
buffer space set aside for all such terminals, or of the
current remaining space. Because the average output
character rate is typically ten times the average input
character rate,11 the limiting algorithms must prevent
write-behind demands from completely depleting the
available buffer space, so that some space is kept
available for collecting input.
The terminal control software is responsible for
blocking further execution of the user's program when
it requests input and none is available, and whenever it
exceeds the write-behind limit. In the waiting.;.for-input
case, the program must be restarted when an action
character is detected. In the waiting-for-output case,
the program should be restarted when the back-logged
output has dropped to an amount whose physical output
time will approximately correspond to the restart delay
(system response), so that the physical output can occur
continuously.
Another responsibility of the control software is to
detect and report disconnects and the user's interrupt
(break) signals. Disconnects should be reported to the
Technical and Human Engineering Problems
system module responsible for reclaiming the communication line and making it available to other users. The
interrupt should be reported to the system module
responsible for suspending the execution of the user's
program, pending input from the user indicating the
reason for the interrupt.
The subject of the interface between the terminal
control software and a user· program is too large to be
covered thoroughly in this paper. The flexibility built
into the control software should be available to the user
program. It should be possible, for example, to request
a different code conversion table, specify a new lineoverflow length, discard existing read-ahead input, turn
off and on the terminal's local copy, disconnect the
terminal (if it is on a phone line), request the terminal's
identification code, etc. A particularly bad interface
example occurs in some systems in use today, in which
it is not possible to simply read from the terminal. The
user program can only issue a write-read sequence.
Output is forced to occur between each line of input.
Consequently, the user program is scheduled and
executed to perform this obligatory output. The overall
effect is to degrade system efficiency as well as seriously
slow down the user at the terminal.
The typewriter control software in the Multics
system is almost completely driven by tables organized
along the lines described above. A single control
program currently operates the Model 37 teletypewriter,
IBM Models 1050 and 2741, and the General Electric
TermiNet-300. Full read-ahead and write-behind are
implemented with a maximum limit which corresponds
to about 700 characters for both the read and write
buffer lists. A buffer pool of 250 14-character block has
proven adequate in a 35 user system. In addition each
active typewriter has physical read and write buffers of
about 100 characters each. After a program exceeds the
write-behind limit and is blocked from execution, it is
restarted when the write...;behind has dropped to about
60 characters.
CHARACTER SET AND CHARACTER STREAM
CONSIDERATIONS
The choice of a suitable character set and suitable
processing of the input and output character streams
are extremely important human engineering issues
which can affect the user's view of the system as much
as any of the factors already discussed. An earlier
paperlO contains a detailed treatment of these issues; it
includes discussion of character set choice, input and
output code conversion, input text canonicalization,
and input line editing.
361
CONCLUSIONS
The total effectiveness of a time-sharing system and its
user community depends a great deal on the human
engineering of the system-user interface seen by the
user from the vantage point of his terminal. We have
concentrated on the factors affecting the user's ability
to provide input at the rate he wishes and to· control
output. Suitable input/output strategies can allow the
user to work in parallel with the computer. We have
maintained that a coordinated design of the terminal,
the terminal control hardware, the terminal control
software, the system's command stream interpreter, the
commands, and other programs, are all necessary to
achieve the desired goal.
Many of the individual factors discussed, of course,
have been recognized as important in the design of
various systems. It is rare, however, to find a sufficient
set of these factors implemented to a satisfactory
extent. One reason for this is that the system designer is
often faced with using previously designed terminals
and terminal control hardware, and even previously
written software. Another reason is that even with
experience using a variety of interactive systems it can
be difficult to assess the sensitivity of the human
interface to differences in design. Too often, this lack
of complete design control together with insufficient
experience results in a system design lacking some
important features.
ACKNOWLEDGlVIENTS
Many of the techniques described here were developed
over a several year time span by the builders of the 7094
Compatible Time-Sharing System at MIT Project
MAC, and by the implementors of Multics, a cooperative research effort by the General Electric Company,
the Bell Telephone Laboratories, Inc., and the Massachusetts Institute of Technology. Among those
contributing to the understanding of how to effectively
implement typewriter input/output were F. J. Corbat6,
R. C. Daley, S. D. Dunten, E. L. Glaser, R. G. Mills,
D. M. Ritchie, and K. L. Thompson.
Work reported here was supported in part by the
Advanced Research Projects Agency, Department of
Defense, under Office of Naval Research Contract
Nonr-4102(01). Reproduction is permitted for any
purpose of the United States Government.
REFERENCES
1 Model 37 teletypewriter stations for DATA-PHONE
(Registered Trade Mark of the Bell System) service
362
2
3
4
5
6
Fall Joint Computer Conference, 1970
Bell System Data Communications Technical Reference
American Telephone and Telegraph Company September
1968
IBM 2741 communications terminal
IBM Form A24-3415-2 IBM Corporation N ew York
P A CRISMAN
The compatible time-sharing system: A programmers' g'uide
Second Edition MIT Computation Center The MIT Press
Cambridge Massachusetts 1965
J H SALTZER
CTSS technical notes
MAC Technical Report No 16 Project MAC Massachusetts
Institute of Technology March 15 1965
The multiplexed information and computing service:
Programmers' manual
MIT Project MAC Cambridge Mass 1970 (to be published)
T A DOLOTTA
Functional specifications for typewriter-like time sharing
terminals
Computing Surveys Vol 2 No 1 March 1970 pp 5-31
7 American National Standard X3.4-1968
American National Standards Institute Oct 1968
8 Programmers' manual for the General Electric-TermiNet-300
printer
No.GEK-15002 General Electric Company 1969
9 J F OSSANNA L E MIKUS S D DUNTEN
Communications and input/output switching in a multiplex
computing system
AFIPS Conference Proceedings Vol 27 Part 1 1965 (1965
Fall Joint Computer Conference) Spartan Books
Washington D C pp 231-241
10 J H SALTZER J F OSSANNA
Remote terminal character stream processing in multics
AFIPS Conference Proceedings Vol 36 1970 (1970 Spring
Joint Computer Conference) AFIPS Press Montvale
New Jersey pp 621-627
11 P E JACKSON C D STUBBS
A study of interactive computer communication
AFIPS Conference Proceedings Vol 34 1969 1969 Spring
Joint Computer Conference AFIPS Press Montvale
New Jersey pp 491-504
Multiprogramming in a medium-sized
hybrid environment
by W. R. DODDS
Bell Helicopter Company
Fort Worth, Texas
simultaneous execution of two real time jobs. As the
setup and checkout software was originally specified
. resembled more of a "wire-checker", and the FOR-'
It
TRAN statements specified the outputs of amplifiers
in terms of preceding amplifiers and potentiometers.
However, it was soon found to be advantageous to
speci!y every component in terms of physical variables,
physICal constants and scale factors. This permitted
easy rescaling, facilitated reallocation of components,
and provided good documentation of potentiometers
and amplifier outputs.
An important feature of the setup software is that
it is user-oriented. The FORTRAN definitions of pot
settings, etc., are manipulated into a subroutine by
a job control procedure library. Scale factors and
static check conditions are usually read in at execution time on data cards, providing a rapid means of
optimizing the static check. This constitutes the "paper
INTRODUCTION
Of the many roles that the digital computer plays in
a full hybrid environment, few are amenable to multiprogramming. Usually, the speed mismatch between
a ~o~ern h~g~-speed analog computer and the typical
sCIentIfic dIgItal computer used in hybrid systems
demands that the digital be fully dedicated to the
particular task in progress. However, the use of the
digital computer for analog computer setup and checkout is a function which is performed several times a
day in an active hybrid computation laboratory and
t~i~ task does not make any severe demands upo~ the
dIgItal . computer. This paper describes a multiprogrammmg system used to effectively set up and check
out an analog computer whilestiH performing routine
background processing such as compilation ..
SYSTEM CONFIGURATION
A block diagram of the Bell Hybrid Facility is shown
in Figure 1. It consists of an IBM 360/44 digital computer linked to two SS-100 analog computers manufactured by Hybrid Systems, Inc. This hybrid system
is. appl.ied to problems in the areas of structural design,
vIbratIOn analysis, rotor dynamics and flight simulation. It is used on a one shift basis with a staff of three
applications engineers.
276
56
12
132
AMPLIFIERS
MULTIPLIERS
DFGS
POTS
PRIORI~_~~TERRUPTS
111M 360/44 G
131, 072 BYTES
FLOATING POINT
FUroRE
PRIORITY INTERRUPT
FUroRE
I---'~=:.....-.It--"::'::PR~IO""'RI""TY-I~NT-ERR-UP-TS--I
276
56
12
132
DESIGN PHILOSOPHY
The software to be described has evolved after two
years of use in an active hybrid facility. A hardware
li~itation of the Bell hybrid system prevents the
8~multaneou8 addressing of both analog consoles from
the digital; hence, the software was not designed to
set up two analog consoles at the same time. In fact
the operating system DAMPS does not permit th~
AMPLIFIERS
MULTIPLIERS
DFGS
POTS
1 "SEC CYCLE TIME
16-31
Figure I-Configuration of Bell Helicopter hybrid computer
facility
363
364
Fall Joint Computer Conference, 1970
PRIORIlY
LEVELS
31
QUEUE
o
RECEIVE I/O
INTERRUPT STARTED
BY TASK IN Q~
ISSUS SVC
CHSCK
QUeuE
1
QUeuE
2
QUEUE
""PlY
./
START PROCESSING
TASK IN Q1
be initiated quite independently of any background
job that may be running. Likewise, either the background or the real time job may be cancelled prematurely by the operator, each independently of the
other.
It is important to understand the mechanism of
switching between tasks. Only two events can cause
control to pass to a lower level queue.
PROCESSING TASK
IN Q2
f)lPlY
3
--====-----==__
BACKGROUND L - -_ _ _ _ _ _ _ _ _ _ _
Figure 2-Illustration of task switching under various conditions
work" debug of a static check. This phase is kept distinct from the hybrid execution of a static check, at
which time the actual wiring of the patch panel is
checked. This natural breakdown of the debugging
procedure into two phases permits one programmer
to be optimizing his static check while another is debugging the wiring of his problem.
OPERATING SOFTWARE
The heart of the multiprogramming software. is
the Data Acquisition Multiprogramming System
(DAMPS), which has been tailored to suit the specific
requirements of the Bell Hybrid Facility. DAMPS
is a "priority based" system operating on three levels,
viz., priority, foreground and background. The system
comprises 32 priority interrupt levels, four foreground
queues and a background queue. Processing is performed at the highest priority active at any given
instant. When a real time task (RTT) runs to completion, lower level RTT's (if any) are initiated. If there
are no pending priority interrupts, then the foreground
queues are examined and the foreground task (FGT)
with the highest "priority" in a given queue gets control. While the system is waiting for completion of
any data processing type I/O (DP I/O) command
issued by the current FGT, control is passed to lower
level queues or to the background. Foreground tasks
within a given queue are executed serial1y according
to the. specified priority of each task. This system of
priorities is illustrated in Figure 2.
Two fixed partitions of core storage have been allocated for the real time jobs (priority interrupt routines and foreground tasks) and the background jobs.
Background jobs are initiated using the norma] job
control processor and jobs may be stacked in the card
reader for sequential execution. Real time jobs (RT.J's)
are initiated from the console typewriter using a special
real time loader. Consequently, real time jobs can
a. The execution of a supervisor routine 'SVC
DONE' which indicates the termination of the
current FGT, at which time the queues are
then re-examined to determine which task should
be executed next.
b. If the current FGT issues an SVC WAIT or
an SVC CHECK, and the system is waiting
for completion of the I/O, then control is passed
to a lower level queue.
Similarly, two events can cause control to pass from
a lower level queue to a higher level queue.
a. If a routine is queued by a program operating
on a priority interrupt level, then upon completion of the real time task, the queues are
examined to determine if the "newly queued"
routine is in a higher queue than the task currently in control. If this is the case, the multiprogramming monitor is called and a task
switching occurs.
b. If an I/O interrupt occurs, the queue from
which the I/O command was issued is examined.
If it is of a higher priority than the task currently in control, then again a task switching
occurs, and activity on the lower level task is
suspended.
INPUT/OUTPUT DEVICE ASSIGNMENTS
In any multiprogramming system, the allocation of
the various I/O devices must be chosen with care;
Under DAMPS, the normal division of I/O devices
between the real time jobs and the background jobs
is shown below.
Real Time Job
Console Typewriter
Card Punch
Background
Console Typewriter
Card Punch
Line Printer
Card Reader
However, a modification was made which permitted
the use of the line printer by both an RTJ and a back-
Multiprogramming in Medium-Sized Hybrid Environment
ground job. The resolution of a printer conflict between
the RTJ and the background is presently left up to
the operator.
CHANNEL OPERATION
Basic to the operation of this multiprogramming
scheme is the concept of the IBM 360 channel. In this
particular application, for example, a channel program
is set up to set an 120 servo-set potentiometers, or to
scan all 346 addressable components. Once the I/O
is initiated, the channel accesses main storage on a
cycle stealing basis, and the CPU is free to perform
other processing. The I/O operations involved in setting up an analog computer typically take several
minutes (pot set, pot scan, amplifier scan) and this
time can be used to advantage for background processing. However, the multiprogramming scheme offered by DAMPS was only designed to work on DP
I/O type operations and not "real time" I/O operations. A special program was written which made a
real time request control block (used for starting up
an I/O operation) resemble a DP I/O request control
block, prior to issuing an SVC CHECK.
ANALOG SETUP SOFTWARE
The essential requirements of a software package
to set up and check out an analog computer include
the following:
1. A means of defining all potentiometer settings
in terms of physical variables and scale factors.
2. A means of defining all amplifier outputs, either
in terms of physical variables, or as a product
of a preceding amplifier output and a pot setting.
3. Tabulation of theoretical values of all pots
and all addressable components with flagging
of outputs exceeding the scaling of the variable.
4. A means of setting up all the servo set potentiometers.
5. Provision of a potentiometer scan and comparison of theoretical values and actual analog
values.
6. Provision of a component scan with a comparison between theoretical values and actual
analog values with error flagging.
There are two distinct stages in debugging a static
check program. The first task is to ensure that the
problem is correctly scaled and that static check values
have been realistically chosen. This constitutes a
"paper work debug" of a static check program. The
second phase is to perform the static check on the
analog computer, checking the wiring and correct
365
functioning of the components. This can sometimes be
a time-consuming stage requiring several iterations.
The Bell Analog Setup Software Package (ANASET)
thus consists of two main stages.
The first program uses pot setting and amplifier
output definitions to generate three major arraysan array containing the theoretical pot settings in
floating point format, an array containing the theoretical amplifier outputs in floating point format, and an
array containing the servo-set pot addresses interleaved with pot settings in BCD format for only the
pots being used. An option is available to write these
three arrays out to a disc. This is used when the "paper
work debug" is finally complete. This first program
also prints out a listing of the theoretical values of
all pot settings and amplifier outputs. Perhaps the
most important feature of this program is that it can
be executed at the background level.
The second program is compiled to be executed as
a real time job using the real time partition. It accesses the three arrays on the disc, sets up the potentiometers, scans the potentiometers and compares
the theoretical values with the read values. The program then pauses to permit adjustment of any erroneouspots.
The static check is then performed by scanning all
components in the analog STATIC CHECK mode,
and comparing the theoretical values with the actual
analog values. Being an RTJ, it is initiated from the
console typewriter, and during the periods of prolonged real time I/O, the background is free to continue processing. Options are programmed into the
RTJ to bypass any of the I/O operations. This facility
is provided to permit re-execution of the static check
without the setting up of potentiometers which may
have just been set up and checked. Some salient details
of these two programs will now be discussed.
A naset (background array preparation)
A detailed flow chart of this program is shown in
Figure 3.
An intrinsic part of the ANASET program is a
subroutine caned STMTS. This subroutine contains
all the user-defined pot definitions and amplifier outputs. The parameter list of this subroutine consists
of the names of an the arrays used to define components. A typical (and simplified) STMTS subroutine is shown in Figure 4. Its operation is best
described by a simple analog program.
Let
dV/dt = - ClV
and
dX/dt = C 3V
+
C2F
366
Fall Joint Computer Conference, 1970
INITIALIZE THEORETICAL
ARRAYS
ORIG(SOO)
POTSEC(132)
CALL S'IMTS TO
CALCULATE THEORETICAL
VALUES OF POT SETTINGS
AND AMPLIFIER OUTPUTS
ANALYZE THEORETICAL POT
SETTINGS FOR 'OUT OF
LIMITS' SORT INTO
SERVO-SET AND HANDSET POTS
BUILD A TABLE OF SERVO
POT ADDRESSES INTERLEAVED
WITH POT VALUES IN BCD
FORMAT - PTARAY(240)
SUBROUTINE STMTS (PO,Pl,P2,P3,P4,P5,MO,Ml,M2,
M3,M4,M5,AO,Al,A2,A3,A4,A5,DA1,DA2,DA3,DA4,DA5,
VGO,VG1,VG2,VG3,VG4,VG5,SC4,SC5,SH,DR,RM4,RM5,DI)
REAL*4 PO(26),Pl(26),P2(26),P3(24),P4(15),P5(15),
1 MO( 6) ,Ml( 6) ,M2( 6) ,M3( 6) ,M4( 3) ,M5( 3) ,AO( 26) ,Al( 29) ,A2( 29),
2 A3(31),A4(32),A5(35),DAO(15),DA1(15),DA2(15),DA3(15),
3 DA4(9),DA5(9),VGO(3),VG1(3),VG2(3),VG3(3),
4 VG4(10),VG5(10),SC4(42),SC5(24),SH(16),DR(16),
5 RM4(l9) ,RM5(l9)
.
1
2
12
F = 4.92
V = 29.3
X = 19.002
15
16
17
Cl = 8.294
C2 = 3.142
C3 = 16.8
18
DVDT = -Cl*V+C2*F
20
21
22
EKl
50.
EK2 = 1000.
VOLT = 100.
30
35
P1(01) = C2*F/EKl
Pl( 04) = Cl/10.
P3( 09) = C3*EK1/EK2
P4(02) = V/EK(l)
40
41
A2(01) = V/EK1*VOLT
A2(03) = -X/EK2*VOLT
42
DA2(01)
OR
DA2(01)
10
11
43
=
= -DVDT/EK1*VOLT
= -Pl(01)*100.+Pl(04)*A2(01)
RETURN
NO
TABULATE THEORETICAL
VALUES OF POT
SETTINGS & COMPONENTS
Figure 4-Subroutine STMTS showing parameter list and typical
statements specifying pot settings and amplifier outputs
settings. The first method is more rigorous as it relates
a specific component to a physical equation, facilitating
debugging.
The remaining routines in program ANASET employ
usual FORTRAN techniques to manipulate the arrays
produced by STMTS, to test for components specified
out of limits and to tabulate the theoretical values
of all components.
Program SSS (real time setup program)
Figure 3-Flow chart of program 'Anaset'
The analog program is shown in Figure 5.
Referring to Figure 4, statements 10-12 specify initial conditions of prime variables used for the static
check. Statements 15-17 specify the values of any
constants. All of the above could also be read in using
the card reader. Statement 18 represents a physical
equation describing the time derivative of V. Statements 20-22 are analog scale factors, etc. Statements
30-35 are the pot definitions in terms of the physical
constants. Statements 40-41 define amplifier outputs. Statement 42 defines a check derivative in terms
of the physical equation. Statement 43 shows an alternative means of specifying a check derivative in
terms of previously defined amplifier outputs and pot
This is the program which uses the three major
arrays previously stored on the disc by AN ASET.
All messages in this program are directed to the console typewriter with the exception of the final static
check output which uses the printer. Afiow chart of
program SSS is shown in Figure 6.
-100
x
- EK'('2)
-100
Figure 5-Analog diagram of sample program
Multiprogramming in Medium-Sized Hybrid Environment
367
THEORETICAL VALUES OF POTENTIOMETERS
P108
Pl14
P121
HANDSET P125
P302
P401
P512
0.5000
0.2020
0.7642
0.1000
0.6459
1.6321 **OUT OF LIMITS**
0.0
THEORETICAL VALUES OF COMPONENTS
Component
MOOl
M002
AOOl
A002
Al09
DFG 410
Figure 6-Flow chart of program SSS
As discussed earlier, a special subroutine is used to
effectively issue an SVC CHECK after a real time I/O
operation has been initiated. This allows control to
pass to any background processing until the I/O is
complete. During pot set, the I/O can be terminated
abnormally if a certain pot fails to set properly. If
this occurs, the program SSS regains control from the
background, determines which pot did not set (by
examining the residual byte count from the channel
status word) and sets up a new channel program to
continue setting pots starting at the failed pot. If the
same pot still fails to set correctly, a warning message
is output on the typewriter and the program continues
to set up the remaining pots. This type of abnormal
I/O recovery procedure is so rapid that it causes no
apparent delay to the background.
There is one very important problem area related
FUNCTION
ANASET Compilation and
Linkage Edi t
ANASET
sss
Execution
Execution
MEMORY
R~UIREMENTS
Background Partition 48K Bytes
Background Partition 3U( Bytes
Real Time Partition 34K Bytes
rIME FOR !!XOCl'TlON
,?:l Minute!l.
2 Minutf's
Approximately'} Minule
1.
Set 1?0 Servo Pots
2.
Scan 132 Pots
3.
Adjust Out of Limit
Pots
4.
Scan All 346
Addressable Components
41 seconds
5.
Print Out Static Check
Results
1 Hinute
6 Mioutes
16 Sec-ond.
1 Minute
SIH 004
D/R 009
-1. 324
36.429
10.000
-15.462
168.562 **OUT OF LIMITS**
-16.829
1.621
49.998
Figure 8-Typical theoretical printout generated by Anaset
to the execution of program SSS. Toward the end of
the routine after the amplifier scan is complete, SSS
tabulates the results on the printer. However, if the
background is processing a compilation and the real
time job were given immediate control, the results
of the static check would be interleaved with the back-
TYPEWRITER LISTING
IASSI 135106
IIXFHD01 JOB, 671S31DDT0100038
rtload
//rtj
IASSI 135329
Ilexec rrr
***END OF REAL TIME J08***
rtload
IASSI 135412
/ /sysOl8 access dsdick,09l=' rel tim'
IA891 M091 RELTIM
/ /exec sss
IA90A M ALL REQ DISCS
ENTER CONSOLE NUMBER •• 0 OR 1
o
CHECK P1l3=SOOO
lASSI 140943
//AGHD09 JOB,676728DDP0200006
CHECK P320=6782
PAUSE TO SET our OF LIMIT POTS
nlESE POTS OUT OF LIMI TS
P026=.SOOO DIFF=.OOl1
PAUSE TO ADJUST POTS
PAUSE TO ALLOW BKGR. TO FINISH
FA83A INT REQ 000
STOP 0
END OF REAL TIME JOB
Note:
Figure 7-Execution times and memory requirements for
Anaset and SSS
Theoretical
Value
COMMENT
Time of day output by system
Job card of background job
Call real time loader
Indicate that an RTJ is to be executed
System provides time of day
Start execution of RRR (provides standard job control)
Indicates end of job
Call real time loader
Sys tern provides time of day
Access disc data set for arrays
Message for information
Start execution of SSS
Mount the disc specified above
Indicate which analog is to be set up
Analog console 0
Pot Pll3 did not set propE'\rly
System provides time of day for new background job
Job card for background job
Pot P320 did not set properly
All pots set up, adjust faulty ones
Pot scan complete, list out of limit pots
Correct value of P206 is .5000
Pause to adjust pots just listed
Amplifier scan complete, allow background to complete
if necessary
Background job complete
Printout of static check complete
Progran SSS complete
Only messages appearing in small letters are input by the operator.
Figure 9-Typewriter log during multiprogramming an analog
setup and a background job
368
Fall Joint Computer Conference, 1970
STATIC CHECK RESULTS
Theoretical
Values
Actual Analog
Values
MOOl
-1. 324
-1.320
M002
36.429
36.300
Comeonent
:
A001
Difference
10.000
9.542
0.458
A002
-15.462
+15.462
30.924
-16.729
.
DFG 410
-16.829
S/H 004
1.621
D/R 009
49.998
Note:
0.0
49.800
1;621
0.19~
The fourth column is only printed out if the
difference exceeds 150 MY.
Figure lO-Typical static check results produced by program SSS
ground compilation listing, which is, of course, totally
unacceptable. Prior to the listing of the static check
results, a pause message is output on the typewriter,
giving the operator the option of waiting until completion of the background job. If this is impossible, then
before the real time job gets ('ontrol of the printer, the
background job is suspended. The static check results
start at top of form and at completion of the printout,
the last page is ejected. Thus, the background job can
continue processing and any output appears on a new
page.
PROGRAM TIMINGS AND MEMORY
REQUIREMENTS
Figure 7 shows the various steps involved in setting
up an analog computer program using the full complement of the computer. Once the static check program is debugged, it is rarely changed, and only program SSS is executed on a recurring basis. Experience
has shown that a complex analog simulation using the
full complement of a computer takes about 30-40
minutes to set up. Since the complement of the analog
computer is fixed, the memory requirements of program
SSS do not vary and the operator merely accesses his
own particular data set containing his arrays. The
memory requirements of AN ASET depend upon the
size of the user's STMTS routine defining the pot
settings and amplifier outputs. An upper limit on this
routine (STMTS) is of the order of 25K bytes (defining every component in terms of physical variables) .
Figure 8 shows a typical printout of the theoretical
values of components produced by ANASET. Figure
9 shows part of the typewriter listing produced while
multiprogramming a background job with the execution of program SSS. Although this may appear confusing at first glance, the messages in lower case letters
are actually input by the operator, the remainder are
messages output by the system or the real time program. Figure 10 shows some typical static check results
produced by program SSS.
CONCLUSIONS
A sophisticated software package for setting up and
checking out an analog computer while multiprogramming background tasks has been outlined. The
operating software is based upon the 360/44 DAMPS
along with special modifications to permit multiprogramming on real time I/O operations. The analog
setup software provides a means of checking analog
wiring directly against physical equations, offers
excellent analog program documentation and facilitates paper work debugging of a static check program
without tying up the real time facilities of the hybrid
system. An entire static check of a program using the
full complement of the analog computer can be performed in less than forty minutes.
ACKNOWLEDGMENTS
This material is presented by kind permission of Bell
Helicopter Company.
The binary floating point digital
differential analyzer
by J. L. ELSHOFF and P. T. HULINA
The Pennsylvania State University
University Park, Pennsylvania
expand that technology. The emphasis is placed on increasing the speed, reducing the cost, and improving
the utility of the DDA in such a way that the DDA
would replace the analog computer and provide a more
practical hybrid system.
INTRODUCTION
Twenty years ago the digital differential analyzer,
DDA, was developed to replace the analog computer
in the solution of differential equations. Although the
DDA is slower than the analog computer, the DDA is
capable of more accurate results since its accuracy is
not bounded by its component characteristics. The cost
of solving differential equations with the DDA is
quite low compared with other methods such as a
general purpose machine, since the DDA is a more
simple device.
As time has passed, advances have been made in
DDA technology. These advances have resulted in
increased speed and accuracy/,2 reductions in cost/
and improvements in man-machine interface. 3 Still the
DDA is seldom used except as a special purpose device.
Despite the dependence of the problem solution on the
quality of the components and the higher cost of the
analog computer, analog computation continues to
grow in popularity. Similarly, general purpose computers continue to be more widely used even though
they cost more and solve differential equations at a
slower rate than the DDA.
In recent years analog and digital computers have
been combined into hybrid systems. 3 ,4 In theory, the
hybrid system takes advantage of the high speed of the
analog computer and the easy programmability and
decision capabilities of the digital computer. In practice,
however, the speed of the analog computer is greatly
reduced in operation~l performance by digital software
and the digital-to-analog and the analog-to-digital
conversion hardware. The general purpose digital
computer can be programmed in an easy problemoriented language like Fortran while the analog portion
of the problem must be physically patched.
This paper concerns itself with a brief review of DDA
technology and an investigation of ways in which to
THE DDA
The vector form of the general linear homogeneous
constant coefficient ordinary differential equation can
be written
(1)
i;=Ax,
x(O) = xo
where A is a constant m X m matrix, and x and x are
m X i column vectors. In rectangular integration the
vector difference equation that replaces equation (1)
is
y(n+ 1) =y(n) +iJ(n) t>.t = yen)
+ t>.y(n)
(2)
where from equation (1)
t>.y(n) =iJ(n)t>.t= (t>.t)Ay(n).
For any given value of y(O), an iterative solution of
equation (2) can be obtained. If yeO) =Xo, then x(t)
is approximated through the relation
x(ndt) =y(n) +O( (dt)2)
where 0 ( (t>.t) 2) represents the truncation error and
nt>.t= t.
In a DDA the fractional part of yen) t>.t is held in a
residue register (R register) and only the integer part
is used in equation (2). Let R(n) be the contents of
the R register at t = nt>.t. Then the equation for y (n) t>.t
is modified to
yen) t>.t+R(n-l) =t>.Z(n) +R(n)
where t>.Z (n) is a signed integer and I R (n) I < l.
Bartee, Lebow, and Reed,5 Huskey and Korn,6 and
369
370
Fall-Joint Computer Conference, 1970
...-----4--.. l!.Z
l!.y--~
l!.t
o.
BLOCK DIAGRAM
l!.y
~Z
l!.t
b.
PROGRAMMING SYMBOL
Figure i-Basic DDA integrator
McGhee and Nilsen2 explain the mathematical principle of the DDA in detail.
Figure 1 displays the block diagram and a programming symbol for the DDA integrator. The Y register
contains the value of y(n). The AY input holds the
value of Ay, the incremental change of the integrand,
at each step. The AZ output and R register contain the
integral and residue of y (n) At, respectively. Finally,
the At input holds the value of At, the step size of the
independent variable.
With these values available, the iterative solution
to equation (2) can be completed. A single step of
rectangular integration is performed by the transfer
equations
Integration phase: Y At+ R--'?AZ + R
Incrementation phase: Y + A Y --'? Y
where AY is a weighted sum of AZ outputs. By alternating the integration and incrementation phases, the
solution to equation (2) is iteratively realized.
In operation the inputs and outputs in a DDA are
represented by two binary bits, the sign bit and coefficient bit. For an arbitrary problem the input and out-
put increments each represent a fixed magnitude. For
example, if AY = c, where c is a constant, then the coefficient bit is one or zero depending on whether or not
there is a AY during each particular incrementation
phase. The sign bit is one or zero depending on whether
AY is negative or positive. Thus, the value c is fixed for
the problem during the programming and is not actually
transferred during the solution. Only a signed coefficient of one or zero is transferred.
In practice the inputs and outputs in a base e DDA
are coefficients of incremental values that are equal to
integer powers of e. By choosing a step size equal to
2- i in a binary DDA the Y At term can be calculated
by a simple shift instead of a multiplication. Let
At = 2- i for i a positive integer, then the Y register is
assumed to be shifted right i positions so that the R
and Y registers have their bits aligned. Thus, the integration phase is reduced to a simple addition.
The method of programming a DDA resembles that
of programming an analog computer. A certain quantity
is assumed to be known. The other values are calculated
from the assumed value. Finally, the assumed value is
derived back from the known values. The actual program must then be physically patched.
The fixed point arithmetic used in the DDA is a
major disadvantage of the DDA. Problems must be
magnitude scaled for solution. Although GilF and
Knudsen8 have developed a completely systematic
procedure for scaling a DDA,the scaling problem is
difficult and solution accuracy depends upon estimated
maximum values.
Since the DDA has not enjoyed widespread use, most
of the developments in DDA's have been pointed at
particular problem solutions. Usually emphasis is
placed on increasing the speed and accuracy of the
DDA, which happen to be inversely proportional. An
improvement in one aspect of DDA's is often compromised by added complications and new problems in
other aspects. Like the analog, the inconvenience in
using the DDA contributes to its lack of popularity.
Because of the lack of popularity, only slight attention
has been focused on improving user convenience.
The emphasis in this work was aimed at user convenience in a hybrid computing system. Since the
major problems seemed to be in programming and
scaling, they were given a high priority. Being digital)
two components can be connected or disconnected by
passing their connection time through an AND gate
with a switching variable that is either on or off,
respectively. Thus, in a hybrid system, the general
purpose computer can be used to program the DDA.
The obvious answer to the scaling problems seemed to
be floating point arithmetic. The use of floating point
arithmetic was also expected to be more accurate which
Binary Floating Point Digital Differential Analyzer
is a very desirable effect. Floating point arithmetic
was implemented in a DDA design and the design
simulated on a general purpose digital computer. The
implementation and simulation results appear in the
remainder of this paper.
THE BINARY FLOATING POINT DDA
The purpose of this section is to present the binary
floating point digital differential analyzer (BFPDDA).
The BFPDDA differs from the conventional DDA in
that the incremental units being transferred between
the components are exponents. Multiple bits must be
used to transmit an exponent instead of the usual one
or two transmission bits in the regular DDA. Yet with
as few as seven bits, signed quantities ranging from
2- 31 to 2+31 can be passed from one component to another
component in the BFPDDA.
In the BFPDDA floating point arithmetic is introduced into the conventional DDA structure in place
of the normal fixed point arithmetic. The floating point
arithmetic transforms the conventional DDA in many
ways without losing its basic structure. The altered
structure, the mathematical algorithms, and the operati9n of the BFPDDA are presented in the following
sections.
-. 1
Y
+
~
SHIFT
AY ADDER
EXPONENT
1
r--==l
RESCALE
CONTROL
1
~ I
Y REGISTER
INTEGRATE
CONTROL
T
I
IT
Y- EXPONENT
REGISTER
~
R + Ydt ADDER
~!
R REGISTER
1
•
r-
OUTPUT
CONTROL
1
AZ
Figure 2-BFPDDA integrator block diagram
371
THE BFPDDA INTEGRATOR .STRUCTURE
The BFPDDA should operate at the fastest speed
possible in order to effectively replace the analog computer; therefore, the integrators should operate in
parallel. Each integrator with its own adders and control units is assumed to be on an integrated circuit chip.
Figure 2 is a block diagram of a proposed BFPDDA
integrator showing its basic units and the lines of communication among these units. Note that the four units
directly under the il Y input are the same as the units
in a DDA.
Let the current value of the integrand Y be represented by
Y = ±.yyyy*2k
where yyy is the mantissa and k is the characteristic.
Similarly, the residue R is represented by
R= ±.rrrr*2k+j
where Ij I is the number of positions the Y register is
shifted right so its bits are aligned with the bits of the
R register. The value of j is negative so that R < Y.
Using these definitions, general descriptions of each of
the units making up the integrator are briefly given as
follows.
Y +ilY Adder-This adder is used to increment the
value of the integrand.
Y Register-The Y register contains the mantissa of
the integrand.
R + Y ilt Adder-This adder performs the integration.
R Register-The R register contains the mantissa of
the residue.
Y-exponent Register-The Y-exponent is the characteristic of the integrand.
Rescale Control-The rescale control normalizes the
integrand.
Shift Exponent-The shift exponent is the number
of places which the R register is shifted left in order to
be aligned with the Y register.
Integrate Control-This unit controls the information
flow during each iteration.
Output Control-This unit calculates the output
increment.
The Y and R registers contain mantissas of floating
point numbers in binary coded form. In this paper the
left most bit of the register is assumed to be the sign
bit. The radix point is assumed to lie between the sign
bit and the second bit of the register. Thus, the high
order significant bit of the Y and R registers is the
second bit. Thus, the R + Yilt adder is a simple integer
adder.
Similarly, the Y-exponent and shift exponent registers
contain exponents in a binary coded form. The Y-
372
Fall Joint Computer Conference, 1970
exponent register contains the number of shift positions
the Y register must be shifted to the left for the radix
point to be properly positioned. The shift exponent is
the number of places the R register is· shifted from the
Y register.
THE MATHEMATICAL ALGORITHMS FOR
THE BFPDDA
The implementation of floating point arithmetic in
the BFPDDA slightly alter the integration calculations
used in the conventional DDA. The change in number representation requires an additional calculation to
determine the output exponent. Finally, in order to
make effective use of the dynamic scaling capabilities
of a DDA with floating point arithmetic, algorithms for
rescaling are included.
The integration phase of each iteration realizes the
transfer function
Noticing that reqUIrIng i~j is a very practical
restriction in the BFPDDA structure. The Y register
is considered to be shifted I j I positions left in order to
be aligned with the R register. Therefore, if the step
size of the independent variable is not at least as small
as 2 j , a multiple bit overflow, which the DDA is not
prepared to handle, could occur.
Algorthim II.-Output calculation
1. If the carry flag is set, transmit k+j as ~j along
with the sign bit.
2. If the carry flag is reset, transmit no output.
During each iteration, the integrand must be updated so that it is as accurate as possible. The incrementation phase performs the transfer function
Y+dY~Y.
The value of the integrand Y is the same as previously
defined. The value of ~ Y is of the form
R+Ydt~dZ+R.
The Y and R values are represented by
and
where m is the exponent being received on the d Y input
lines along with the correct sign. The procedure used
for the incrementation of the integrand is now given in
Algorithm III.
Algorithm III.-Incrementation of the integrand
where yyyy and rrrr are the contents of the Y and R
registers respectively. The Y-exponent register contains
k and the shift exponent register contains j. Let
1. If k ~ m, invoke Algorithm IV;
Otherwise,
a. Shift ± 1.0 right k-m-l positions.
b. Add the shifted value to the Y register.
c. If the Y register overflows, invoke Algorithm
where i ~j. Then the integration phase is described in
Algorithms I and II, where the carry flag is a simple
set and reset flip-flop.
Algorithm I.-Integration
d. If the magnitude of the Y register is less than
one-half without considering the Y -exponent,
invoke Algorithm VI.
V.
1. Shift the Y register j - i positions to the right.
2. Add the shifted Y register to the R register.
3. If the R register does not overflow, reset the
carry flag;
Otherwise,
a. If the R register is positive,
1. Decrement the R register by 1.0.
11. Set the sign bit associated with ~Z to
positive.
lll. Set the carry flag.
b. If the R register is negative,
1. Increment the R register by 1.0.
11. Set the sign bit associated with ~Z to
negative.
lll. Set the carry flag.
An overflow condition occurs when the magnitude of
is larger than the magnitude of Y. Since this means
that the change in Y is larger than Y itself, the Y value
is considered to be negligible. In this case the integrator
is reset as defined in Algorithm IV.
Algorithm IV.-Resetting the integrand
~Y
1. Set the Y register to ±0.5 depending on the
sign of dY.
2. Set the Y-exponent register to m+ 1.
3. Set the R register to zero.
During the incrementation phase of each iteration,
the Y register is treated as a fixed point value. When
the Y register overflows, a rescaling of the integrator
is performed as described in Algorithm V.
Binary Floating Point Digital Differential Analyzer
Algorithm V.-Rescaling for an increasing integrand
1. Shift the Y register one position to the right.
2. Shift the R register one position to the right.
3. Increment the Y-exponent register by one.
Just as the value of the integrand may get larger in
magnitude, it may also get smaller. By keeping the
fractional value of the integrand normalized in the Y
register, output overflows will tend to be smaller but
will occur more frequently. The procedure for rescaling
for a decreasing integrand is shown in Algorithm VI.
Notice that this algorithm does not alter the R register.
Many tests seemed to indicate that ignoring the R
register gave the best results.
Algorithm VI.-Rescaling for a decreasing integrand
1. Shift the Y register one position to the left.
2. Decrement the Y-exponent register by one.
THE OPERATION OF A BFPDDA
As with the conventional DDA, the basic cycle of the
BFPDDA is a two phase iteration. The integration and
incrementation phases are outlined in Table I.
In phase I the integration is performed. While the Y
register is being shifted and added to the R register,
the output value is calculated. Then if an overflow occurs, the calculated output value is transmitted, otherwise, no output is transmitted and the calculated output value is ignored.
In phase II the integrand is incremented. An overflow
in the addition causes the incremented value to be stored
one position to the right and Y -exponent register to be
incremented by one. An increment that is larger than
the current value of the integrand causes the Y, Yexponent, and R registers to be reset. On the other hand,
if the mantissa is small enough, the result is stored on~
position to the left in the Y register and the Y-exponen1
.
et
A~
6t
Figure 3-DDA program for et
6(et )
373
TABLE I-BFPDDA Operational Iteration
I. Integration Phase
R+ Y !1t~!1Z +R
1. Integration
2. Output Calculation
II. Incrementation Phase
Y+.!1Y~Y
1. Incrementation
2. Rescaling
is decremented by one. In this way the integrand remains normalized.
THE ELIMINATION OF IVIAGNITUDE
SCALING
One of the major drawbacks of the ordinary DDA is
the fixed point arithmetic it employs. Each integrator
must be magnitude scaled in order that the integrand
register doesn't overflow during the problem solution
causing the program to abort. On the other hand, if the
maximum value is overestimated by a significant
amount, the error being delayed in the R register of the
integrator is much larger, causing the problem error to
be increased.
Consider the DDA solution of if - y = O. The program
for this equation is very simple as is shown in Figure 3.
Despite the simple program, et is one of the more difficult solutions for the DDA to calculate. The exponential represents a continuously increasing function
with a large variation in magnitude. Since the accumulated error will never be canceled, the magnitude of
the error increases as the value of the independent
variable t increases. Also, the initial value of the exponential function is its minimum value which results in
very large initial errors since the integrator must be
scaled for the values of increasing magnitude of the
function.
Table II illustrates the effect of magnitude scaling
on accuracy. When the integrator was scaled for a maximum value of 23 , the error in calculating e2 with a step
size of 2-8 was approximately equal to the error in
calculating e2 with a step size of 2-13 in an integrator
scaled for a maximum value of 28. Although et may be
the extreme case, the exponential demonstrates the loss
of accuracy in DDA problem solutions with variables
that have a large variation in their magnitude .
The standard DDA has another scaling problem
which the exponential exhibits. When the DDA is
programmed, the step size must be fixed since the shift
between the Y and R registers of the DDA is directly
related to the step size. Thus the output line represents
a fixed quantity and each output pulse is one unit of
that quantity. If the step size is then changed, the out-
374
Fall Joint Computer Conference, 1970
TABLE II-Comparison of Maximum Errors in Calculating
e2 =7.3891 with a DDA Using Varying Magnitude Scalings
Step Size
Maximum Integrator Value
23=8
28 =256
0.1553
0.0803
0.0406
0.0201
0.0102
0.0051
0.0026
3.3891
1.8891
1.0103
0.5141
0.2623
0.1309
0.0657
put quantity also changes. The new output quantity
then must be reprogrammed at each point where it is
used as an input to another component.
In calculating the exponential the integrator is
magnitude scaled. Suppose the maximum value is set
at 23 and a step size of 2-10 is selected, then each overflow
or output bit represents 2-7• The value of eO is loaded as
the initial condition and e2 is calculated. According to
Table II an error of 0.0392 has occurred. If this error
is determined to be too large, a smaller interval must
be chosen. Choosing an interval of 2-12 makes each output bit represent 2-9 • Each increment of Y is then onefourth of the previous increment size and the integrator
must be reconnected to allow for these smaller incremental values.
Fixed point arithmetic in the regular DDA also
causes scaling problems for integrators with more than
one input incrementing its integrand value. Since the
DDA is incremented by receiving a pulse, the increment value is fixed within the integrator being incremented. Therefore, when the integrator receives
increments from two or more components, the inputs
must represent the same value.
The magnitude scaling problem does not exist in the
BFPDDA. As the integrand values become larger the
integrator rescales upward. Similarly, the integrator
rescales downward as the values become smaller in
magnitude. The user does not have to estimate the
maximum values or even know much about the relationships among the integrators since each integrator
functions independently of the other integrators without
regard to the integrand magnitude.
Since the BFPDDA integrators rescale themselves,
the accuracy of the BFPDDA is better than that of a
regular DDA. When the integrand magnitude becomes
smaller, the integrator rescales downward causing the
fractional error of the integral in the R register to be
reduced. A smaller overflow then occurs in the integration; however, the overflow occurs much sooner and
introduces much less delay error than in the standard
DDA. Thus the BFPDDA causes more, but smaller
overflows than the ordinary DDA in solving most
integrals which leads to more accurate solutions.
Two solutions of et were calculated using the
BFPDDA. After each iteration the calculated value
was compared with the actual value and the error determined. The maximum errors in calculating e2 and e5 for
varying interval sizes is shown in Table III. The same
values were also calculated with a regular DDA and
also appear. When the magnitude scaling was done for
e2, only a three bit binary shift was necessary and the
DDA was practically the same as the BFPDDA. However, when an allowance of eight bits was made for e5
in the DDA and two and one-half times as many iterations were performed, the BFPDDA was over ten
times as accurate as the DDA. The BFPDDA could
then solve e5 ten times as fast as the DDA for the same
accuracy, since speed and accuracy are inversely
proportional.
The values appearing in Table III indicate that the
BFPDDA is more accurate because of its rescaling
techniques and floating point arithmetic. Over the
shorter solution of e2 the accumulative error wasn't too
critical. When a slightly longer problem was solved
with a larger range in integrand magnitudes, the accumulative error in the DDA greatly impaired its advantages but only minimally effected the BFPDDA.
Other factors not appearing in Table III also make
the BFPDDA preferable. In changing from one interval size to another, the shift exponent register was
merely reloaded with the exponent of the step size
chosen for maximum accuracy. Otherwise, there was
no reconnection for the new problem solution. The
values taken from the BFPDDA were directly readable.
There was no multiplication by a scaling factor necessary to put the calculated result in a form relative to
that of the unscaled, original equation.
TABLE III-Comparison of BFPDDA and DDA in Accuracy
Solving et
Maximum Error in
Calculating e2 = 7.3891
DDA
BFPDDA
0.1553
0.0803
0.0406
0.0201
0.0102
0.0051
0.0026
0.1524
0.0790
0.0392
0.0198
0.0099
0.0050
0.0025
Step Size
2- 8
2-9
2-10
2-11
2-12
2-13
2-14
Maximum Error in
Calculating e5 = 148.41
DDA
BFPDDA
65.413
35.624
18.413
9.393
4.726
2.367
1.187
5.543
2.835
1.413
0.716
0.359
0.180
0.091
Binary Floating Point Digital Differential Analyzer
Another advantage of the BFPDDA appears when
second or higher order equations are solved. An integrator receives its integrand increments in the form of
an exponent instead of a pulse. Since the magnitude of
/ the increment is passed between the integrators, the
integrator may receive increments of different magnitudes during the problem solution. Thus, the integrator
may have two or more increment inputs without having
the multiple inputs scaled to represent the same
magnitude.
In the BFPDDA magnitude scaling has been eliminated. Each integrator dynamically rescales itself independently as the magnitude of its integrand varies.
The accuracy in the BFPDDA is not dependent on the
estimated maximum value used in the magnitude
scaling. With the BFPDDA the independent variable
step size may be changed easily with no reconnection
necessary. Finally, an integrator receiving an increment
from more than one component does not require all of
the incremental values to be of equal magnitude.
BFPDDA SOLUTION OF THE HARMONIC
EQUATION
The BFPDDA program for solving the harmonic
equation, x+w 2x=O is shown in Figure 4. The result of
the solution is obtained at any given time during the
solution by reading the current value contained in the
sin wt integrator, which in this problem is simply used
as a summer. In the results shown in this section, sin wt
was read after each iteration and the error calculated
at each point.
The BFPDDA can solve the same problem with
many different parameters without being rescaled or
reprogrammed. Even large variations in the magnitudes of the parameters have almost no effect. Table
Il( ...
Ilf
Il (Sin (...f»
cos (.. f))
Sin (.. f)
375
TABLE IV-Maximum Errors in One Cycle Sine Wave Solutions
0.4437
0.5653
1.8120
3.3890
2- 10
Step Size
2-12
2-14
0.00662
0.00881
0.01093
0.01328
0.00165
0.00217
0.00271
0.00361
0.00040
0.00055
0.00064
0.00081
IV displays the maximum error that occurred during
the one cycle solution of a sine wave. The frequencies
were generated randomly from successive ranges
bounded by powers of two.
In the BFPDDA all the values shown in Table IV
were calculated without reprogramming or rescaling.
In the standard DDA a change to a smaller step size
, would necessitate reconnection so that the proper values
were represented. Similarly, the DDA has to be rescaled each time the step size changes or the magnitude
of the frequency is significantly altered. In the case of
the BFPDDA the step size is changed by simply reloading the shift exponent registers and setting a smaller
exponent on the independent variable input lines. A
new frequency is simply reloaded in the Y register of
the integrator being used for constant multiplication
and the initial condition reset on the w cos (wt) integrator in order to solve the harmonic equation for a
new w2 value.
The maximum errors increase as the frequency increases since one cycle of the sine wave is broken into
fewer intervals. Thus, as higher frequency sine waves
are generated, smaller intervals may be necessary in
order to maintain accuracy. The smaller intervals will
not increase the overall problem time, however, since
the range of one cycle is much smaller.
The harmonic equation was also used for comparing
the accuracy of the BFPDDA against the accuracy of
the DDA. For this test w2 = 1 and the integrator containing w2 was replaced by an inverter on the sign transfer bit. The results which appear in Table V show that
the BFPDDA is twice as accurate as the DDA.
Ilf
CONCLUSIONS
Figure 4-Interconnection of BFPDDA integrators to solve
harmonic equation
The emphasis in designing the BFPDDA has been on
improving user convenience. 9 By reconstructing a
standard DDA to use floating point arithmetic and to
transfer exponents between its components, an easily
programmable device requiring no magnitude scaling
resulted. Moreover, the floating point arithmetic
proved the BFPDDA to be more accurate than the
376
Fall Joint Computer Conference, 1970
TABLE V-Maximum Errors in a One Cycle Solution of the
Harmonic Equation with w = 1
Step Size
2-8
2- 9
2-10
DDA
BFPDDA
0.03209
0.01477
0.00709
0.01605
0.00797
0.00406
ordinary DDA. The accuracy improvement becomes .
more significant as the variation in magnitude of the
problem variables increases. The BFPDDA also allows
for alterations in the rate of integration during a problem solution since no new scaling is necessary.
Considering current technology and the BFPDDA,
the hybrid computing system could be headed for new
horizons. The BFPDDA with all main advantages of
digital computation in an analog environment will be an
excellent special purpose differential equation solver
on-line with a time-shared digital computer. Dynamical
systems with unknown solutions can quickly be solved
since the solution will not depend on estimated maximum parameter values; Being digital the whole field
of automatic patching by program can make the
BFPDDA easier to use. Making the DDA floating
point and greatly increasing user convenience at only
a very slight cost increase should make hybrid computation very popular.
REFERENCES
1 M W GOLDMAN
Design of a high speed DDA
AFIPS Conference Proceedings Fall Joint Computer
Conference pp 929-949 1965
2 R B McGHEE R N NILSEN
The extended resolution digital differential analyzer: a new
computing structure for solving differential equations
IEEE Trans on Computers Vol C-19 pp 1-9 January 1970
3 T C BARTEE J B LEWIS
A digital system for on-line studies of dynamical systems
AFIPS Conference Proceedings Spring Joint Computer
Conference pp 105-1111966
4 M
HOYT W T LEC 0 A REICHARDT
The parallel digital differential analyzer and its application
as a hybrid computing system element
Simulation Vol 4 pp 104-113 February 1965
5 T C BARTEE I L LEBOW I S REED
Theory and design of digital machines
McGraw-Hill New York pp 252-265 1962
6 H D HUSKEY G N KORN
Computer handbook
McGraw-Hill New York Chapter 3 pp 14-74 1962
7 A GILL
Systematic scaling for digital differential analyzers
IRE Trans on Electronic Computers Vol EC-8 pp 486-489
December 1959
8 H K KNUDSEN
The scaling of digital differential analyzers
IEEE Trans on Electronic Computers Vol EC-14 pp
583-590 August 1965
9 J L ELSHOFF
The binary floating point digital differential analyzer
PhD dissertation The Pennsylvania State University
University Park Pennsylvania September 1970
,;y
Time sharing of hybrid computers
using electronic patching
by ROBERT M. HOWE
University of Michigan
Ann Arbor, Michigan
and
RICHARD A. MORAN and THOMAS D. BERGE
A pplied Dynamics
Ann Arbor, Michigan
of an automatic-patching system for the AD/FOUR
analog hybrid computer shown in Figure 1. As of the
writing of this paper more than 60 AD/FOUR computer systems are operating in the field, many of them
interfaced with general-purpose digital computers.
Because the AD/FOUR design tends to minimize the
number of switch elements needed to mechanize an
efficient automatic-patching system, it was decided to
add this capability to the existing system as opposed to
designing a completely new system from scratch. This
has the further advantage that any AD/FOUR systems
in the field can be updated to include automatic
patching.
The next section describes the configuration of the
AD /FOUR automatic-patching system. Following sections present an example application, discuss diagnostic
considerations, and summarize the system capabilities
when operating in a time-shared mode using remote
terminals.
INTRODUCTION
Ever since the introduction of patchboards for allowing
storage of analog computer programs, the desirability
of having a remotely-controlled switch matrix to replace the analog patchboard has been evident. Only recently, however, has automatic patching received widespread interest and study.l,2,3 One reason for this is the
current widespread availability of hybrid computer
systems, with the result that the automatic-patching
program can be stored and implemented through the
general purpose digital computer. Not only have hybrid
computers made automatic patching of the analog subsystem, therefore, more feasible, but also hybrid computers have emphasized the desirability of having
automatic patching.
Additional technological developments have made
automatic patching feasible. The availability of lowcost, high-performance solid-state switches for implementing the necessary switching matrices is very important. Also, low-cost integrated circuit chips can be
used to provide the storage of the switch settings.
Finally, the availability and widespread use of digitallyset coefficient devices for the analog subsystem allows
high-speed setup of all the parameter values as well as
component interconnections. This in turn allows complete problem reprogramming within milliseconds
which means that timesharing of a single hybrid computer through remote stations is practical. The resulting
increase in computer cost effectiveness far exceeds the
extra cost of the hardware and software necessary to
implement automatic patching of the analog subsystem.
In the paragraphs to follow we will describe the details
DESCRIPTION OF THE SYSTEM
In the AD/FOUR conventional analog programming
is achieved using patchcords for interconnections between holes in the large removable patchboard in the
center of the console shown in Figure 1. This patchboard is divided into four quadrants (hereafter called
fields) , with a matrix of 32 X30 = 960 holes in each field.
The fields are numbered 0, 1, 2, and 3, as shown in
Figure 2, and the fields are normally filled with computing components in the order 2, 3, 0, and 1. Thus
field 1, in the upper right corner of the patchboard, is
377
378
Fall Joint Oomputer Oonference, 1970
which includes the following component count:
16
12
64
Figure l-AD-4 computer system
the last to be filled with analog components, and very
few AD/FOUR systems are expanded into field 1. For
this reason it was decided to terminate the electronicswitch matrices for automatic programming in field 1.
These are then patched to the appropriate holes in
fields 0, 2, and 3 to mechanize the automatic-patching
capability. Thus a single analog patchboard is permanently wired with the automatic program configuration. Note that this patchboard can be replaced by a
conventionally-wired patchboard at any time when it
is desired to operate the AD/FOUR in the normal
patchboard mode.
As can be seen in Figure 1, there is a second patchboard on the right side of the console. This is just half
the size of the central analog patchboard, and terminates the logic-level signals associated with the hybrid
and digital computing elements in the AD/FOUR. No
attempt has been made to implement general-purpose
automatic-patching of the logic elements. Instead, it is
proposed to accomplish all logic functions in the digital
subsystem of the hybrid computer. The logic patchboard is wired to implement the necessary control and
timing functions when the AD/FOUR is operating in
the automatic-patching mode.
If completely flexible automatic patching were
needed, then it would be necessary to be able to connect every analog element to every other element.
Since this would require a prohibitively large number
of switches, one invariably divides the analog system
into identical modules when mechanizing an automatic patching system. Flexible interconnection of
analog components within each module is then provided, along with programmable interconnections between modules. In the AD/FOUR computer the
module size for automatic patching is an analog field,
bipolar summer integrators
multipliers, each with a bipolar
input 'buffer amplifier
digital coefficient units (DOU's)
In addition, each of the 16 summer integrators and 12
multiplier buffer amplifiers has a digital reference unit
(28 in all). Function generation is performed using
DOU's updated from the digital computer, with special
dual comparators used to provide the necessary interrupts for DOU updating.
Figure 3 shows the circuit schematic within a given
AD/FOUR field for the summer-integrator and DOU
switch matrix. Each bipolar output of the summerintegrators in the field is permanently patched to a pair
of DOU's, utilizing 16X2=32 DOU's (amplifiers 200,
201, etc., in Figure 3). Each output of an additional 8
bipolar amplifiers (100, 101, etc., in Figure 3) is patched
permanently to four DOU's, utilizing 8 X 4 = 32 DOU's.
The input to each of these 8 amplifiers can be switched
to any of the 16 summer-integrator outputs. Thus all
summer integrators drive a minimum of 2 DOU's, and
can be programmed additionally to drive a total of 6,
10, 14, etc., DOU's.
The output of each of the 64 DOD's in the AD/
FOUR in Figure 3 can be programmed to any of the 16
summer-integrator input summing junctions, or any
of the 12 multiplier Y-input buffer-amplifier summing
junctions (see Figure 4). Thus a 64 X 28 summingjunction switch matrix for DOU outputs is represented
by the circuit in Figure 3, as well as a 16X8 switch
matrix for the DOD buffer amplifier inputs. Each
DOD is the standard 15 bit AD /FODR single-buffered
MDAO, with the most significant bit providing a
negative analog polarity. Thus a given DOD can be
programmed between a gain of -1.6384 and· 1.6383
using two's complement logic and with a minimum bit
size of 0.0001. Since the DOD is a summing-junction
+
ANALOG
COMPONENTS
TERMINATED IN
FIELDS 0,2,3
Figure 2-Analog patchboard
Electronic Patching for AD4 Hybrid Computer
output device, summing-junction switching can be
used throughout the switch matrix.
A digital reference unit (DRU) is permanently
patched to each of the 16 summer-integrator amplifiers,
allowing a programmable bias. Also, the output V re,
of an initial-condition amplifier is patched to all of the
16 integrator-summer input terminals. This allows
initial conditions for the entire field to be set sequentially using the single DRU which drives the initial
condition amplifier. The procedure starts with all integrators returned to the IC (Initial Condition) mode
with the DRU set at zero (i.e., VIC=O). This puts zero
initial conditions on all integrators, which are then all
switched to Hold. Following· this, each integrator is
switched to IC sequentially with the DRU programmed
to yield the desired initial condition for that particular
integrator. The integrator is then returned to Hold
and the next integrator switched to 10, etc. After all
initial conditions have been established in this manner,
the integrators can all be switched to Operate.
Figure 4 shows the schematic for the connections to
the 12 multipliers within a given AD/FOUR field.
The bipolar X inputs for each multiplier are permanently wired to specific summer-integrator outputs.
The bipolar Y inputs are each programmed to the outputs of the 12 bipolar summers in the AD/FOUR field.
The summing junctions of these amplifiers are in turn
28 SJ 8USSES
( 16
12 MULTIPLIER Y INPUTS)
L /'"
+1
-I
TOTAL OF
16
AMPLIFIERS
EACH DRIVING TWO Dcui
LI
AMPLIFIERS, EACH DRIVING
4DCui AND WITH INPUT
PROGRAMMABLE TO ANY
OF TH£
··· .
IIII AMPLIFIER
OuTPUTS.
Figure 3-Circuit schematic for DCU switch matrix
TO 64 OCu', {
379
:
+1
-I
}
16 SJ BUS
(16 ~ /,s)
'-f-l-'+-..
TO 64 OCU's
Figure 4-Circuit schematic showing multiplier switch matrix
switchable to the outputs of any of the 64 DOU's in
the field (see Figure 3). In addition, there is a DRU
permanently patched to the input of each of the 12 Y
input buffer amplifiers, allowing a programmable bias
into each multiplier Y input.
Extensive study of typical analog programs has
shown that the X inputs to multipliers are seldom all
independent. For this reason the multiplier X inputs
are assigned to summer-integrator outputs using the
configuration shown in Figure 5. The first four multipliers are assigned, respectively, to the first four summer-integrators. The fifth multiplier (no. 221) has its
X input assigned to the fourth amplifier (no. 211) and
the sixth multiplier (no. 222) has its bipolar X input
patched to the common terminal of a 3-position, double
pole relay (nos. 220, 221). The position of this relay,
part of the standard AD/FOUR equipment complement, is controlled by registers set from the digital
computer. In this way the X input. to multiplier 222
can be programmed to amplifier 210, 211, or 222. Thus
the configuration of multiplier X inputs. assigned, .respectively, to summer integrators in half a field can
be programmed to be 1,1,1,2,1; 1,1,1,.3; or 1, 1,.2,2.
Later examples show the utility of this scheme.
380
Fall Joint Computer Conference, 1970
FUNCTION GENERATION
210
211
c B A c
RELAY
220
B
- - ---- L-_--1-~
221
222
Generation of precision functions of one or more
,variables on analog computers has always presented
major difficulties. In fact, one of the principal tasks of
the digital sUbsystem in many hybrid problems has
been the generation of multivariable functions for use
by the analog subsystem. However, this approach has
serious dynamic limitations. Since it is desirable to
have the automatically-patehed analog computer operate at relatively high speed in order to permit time
sharing, pure digital function generation is undesirable.
Instead, a hybrid method analogous to that first proposed by Rubin4 is utilized.
The graph in Figure 6 illustrates the functiongeneration method when applied to a function of one
variable. Between breakpoints Xi and· Xi+! the function
f(x) is represented as having intercept ai and slope b i ,
i.e., f(x) =ai+bix. The mechanization is achieved by
terminating two DCU's in amplifier 1, as shown in the
figure. Whenever X crosses over into a new zone, e.g.,
between Xi+l and Xi+2, the two DCU's are updated to
represent ai+l and bi+l, respectively, the intercept and
slope in the new zone. High speed detection of the
zone in which X is located is achieved by a special dual
comparator with digitally-programmed bias inputs Xi
and Xi+l. Whenever X passes outside the zone bounded
by Xi and Xi+l, the gate shown in Figure 6 throws the
analog system into Hold. By sensing the state of comparators A and B the digital computer determines
whether X now lies in the i-I or i+ 1 zone. It then looks
Figure 5-Schematic showing assignment of amplifier outputs to
multiplier X inputs in ofie-:.half of field 2
Four hard feedback-limiters are permanently programmed, respectively, around four of the 16 summer
integrators in each field in the automatic-patching
system. DRU (digital reference unit) outputs are
permanently programmed in pairs to each hard limiter
to allow digitally controlled setup of the + and limits. In the AD/FOUR computer each summerintegrator is normally in the summer configuration. By
grounding, respectively, either one of two patchboard
holes associated with each summer integrator, the
amplifier can be changed to an integrator or high-gain
configuration. In the automatic patching system these
amplifier configuration holes in each field are patched
to corresponding holes in field 1. These· field 1 holes,
under register control from the digital computer, provide program-controlled electronic grounds. Thus any
of the 16 summer-integrators in each field can be configured as summers, integrators, or high-gain amplifiers.
DUAL
COMPARATOR
filii: o.bll
fllI,yl :o+bx+cy+dllY
~
I +
-
I
flxl
+ b
x
ONE - VARIABLE
FUNCTION
xy
Figure 6-Circuit schematic for function generation
Electronic Patching for AD4 Hybrid Computer
up the values for intercept a and slope b in the new
zone and sets the corresponding DCU's terminated in
amplifier 1 to the new values. It also sets the bias inputs into comparators A and B to the corresponding
values for the new zone. After completing these operations the digital computer restores the analog system
to the Operate mode.
Because the analog computer is in the Hold mode
while the digital computer is accomplishing the necessary DCU and DRU updatings, any dynamic errors
which would otherwise result from the time required
by the digital computer to accomplish the updatings
are eliminated. The only significant sources of dynamic
error include the lag in dual comparator response (the
order of one microsecond), the delays in Hold mode
control switches (the order of one microsecond), and
differential timing errors in activation of both Hold
and Operate mode control (less than one microsecond).
Also, offsets caused by cycling the integrators back and
forth between Hold and Operate must be considered.
In the AD/FOUR each such mode cycle causes the
order of 0.5 millivolts of additional integrator output
offset for integrators programmed with a gain of 1000
(typical for high-speed problem solution). At foreseeable Hold-Operate cycle rates in implementing the
function generation as described here, the equivalent
steady offset represents only from 0.01 percent to
0.1 percent of full scale. Even with these offsets there
will be no significant effect except where open-ended
integrations are involved. Study has shown that integrator drift during Hold is completely negligible over
the time required for updating DCU's and DRU's.
Generation of functions of two variables is implemented using the formula f(x, y) =a+bx+cy+dxy.
The circuit is shown in Figure 6 using 4 DCU's terminated in amplifier 2. The DCU settings correspond to
the function f (x, y) for Xi::; X ::; Xi+l, Yi::; y ::; Yi+l. When
either X or y moves into a new zone, as detected by the
respective dual comparator, the 4 DCU's are updated
while the analog computer is in Hold. The resulting
f(x, y) analog function is equivalent to linear interpolation in X and y. A function of three variables can
be generated using the formulaf(x, y, z) =a+bx+cy+
dz+exy+fxz+gyz+hxyz. As before, the 8 DCU settings
needed to generate the three-variable function correspond to the appropriate x, y, and z zones.
Since each summer-integrator in the automaticpatching system can terminate any number of DCU's
and has a permanently assigned DRU (digital reference
unit), each summer integrator can be used to generate
any multivariable function or any sum of multivariable
functions. Reference to Figure 4 shows that each Yinput bipolar buffer amplifier for multipliers terminates
any number of DCU's as well as an assigned DRU.
381
Thus it can be used to generate the sum of multivariable functions, which in turn are multiplied by the
other multiplier input, X. In the AD/FOUR automatic
patching system 8 dual comparators, each with an
assigned DRU pair, as shown in Figure 6, are available
in each analog field. Inputs for these 8 dual comparators
can be assigned to any of the 16 summer integrators in
the field using switches driven by digitally-set registers.
Fixed function generators, e.g., sinx, cos x, and logx
function generators, can be terminated in multiplier
locations in the AD/FOUR. In this case the general
I/O format shown in Figure 4 for multipliers is pre~
served. For example, the Y-input bipolar buffer
amplifier is used to terminate the sin x and cosx fixed
dfg (still with summing-junction output and hence
output switches).
INTERFIELD PATCHING
Up to now we have only described the circuit configuration needed to patch automatically the connections within an AD/FOUR field. It is, of course, also
necessary to implement interconnections between each
of the fields (three-fields maximum; see Figure 2). This
is accomplished in the following two ways:
I. The first of the two DCU's permanently assigned to the output of each summer integrator
(e.g., DCU 200, 202, etc., in Figure 3) has its
output programmable to the summing-junction
input of any summer integrator in the other two
fields as well as summing junctions in its own
field.
II. The input to each quad DCU buffer amplifier
can be switched to any summer integrator amplifier output in the other two fields as well as
in its own field (see Figure 3).
The effectiveness of the above automatic
patching capability is best appreciated by
example problems. Extension of II above to
outputs trunked in from adjacent consoles
effective interconsole trunking capability.
interfield
studying
amplifier
provides
DIAGNOSTICS
Diagnostics, both to determine proper component
functioning and to debug analog programs, is appreciably simpler with the automatic-patching system
than with a conventional analog patchboard program.
First of all, the patchboard on which the automatic
patching program is wired also serves as the diagnostic
patch board, i.e., no special diagnostic patchboard is
382
Fall Joint Computer Conference, 1970
required. Secondly, because of the fixed configuration,
the complete computer control of all component modes
and interconnections, the presence of programmable
initial conditions and bias inputs for every bipolar
amplifier,etc., it is extremely straightforward to write
the software for checking every analog amplifier, DCU,
DRU, and nonlinear element as well as every matrix
switch. For example, proper functioning of every DCD
and DCU output switch can be implemented by setting
a one machine-unit initial condition on the integrator
driving each DCU, with all other summer-integrators
programmed as summers. Each bit of the DCU can be
dhecked individually by programming the DCU back
to the driving-amplifier input and monitoring that amplifier input. Next the DCU can be set at, say, unity
gain and its output switched successively to every
amplifier summing junction (both summer-integrators
and multiplier Y-input buffers). Proper matrix-switch
functioning is assured by checking the respective
amplifier outputs. Equally straightforward checks can
be implemented for other components, including a rate
test for all integrators using the programmable bias
(DRU) input. The thousands of individual checks
making up an overall three-field diagnostic will take
only seconds, with easily-identified printout of any
malfunctions.
A similar scheme is proposed for program verification,
where, successively, a given initial condition (usually
one machine unit) is applied to every integrator with
the output (or summing-junction input) to all amplifiers measured and stored. This allows checking of the
setting and input assignment of every DCU, as well as
its output assignment. By programming unit X and Y
inputs to each multiplier, successively, and monitoring
all summer outputs and integrator inputs, multiplier
output assignments can be checked. Function generator
set-up can be checked by observing amplifier outputs
for successively programmed values of the input
variable. It is believed that this type of program
verification is even more powerful and easily debugged
than the more conventional static check.
turn-around time, in turn, suggests that it should be
quite feasible and extremely cost effective to time-share
a single AD/FOUR hybrid system among a number of
users stationed at remote terminals.
A relatively simple terminal system suitable for timesharing is shown in Figure 7. This is the AD Dynamics
Terminal, originally developed primarily for the educational market in order to allow individual terminal
operators to time share a single problem programmed
on the AD/FOUR or AD/FIVE hybrid computer.
Across the top of the front panel of the terminal are
eight 3-digit-plus-sign parameter entry thumbwheel
switch sets which are assigned, respectively, to 8 problem parameters. To the right are 8 pushbuttons which
control singly or in combination logic signals on the
hybrid system which in turn control problem configuration. On the lower panel are channel selector,
gain, and bias controls for the x and y axes of the
memory scope used for solution readout. Also on the
lower panel of the terminal are the computer modecontrol switches.
A number of terminals (up to 16 or more) can be
connected to a single AD/FOUR hybrid computer.
The computer interrogates each terminal in sequence
to see whether the operator has requested a solution
since the last interrogation of his terminal. If he has,
the computer sets his parameter values and proceeds
to generate a solution, which is stored on the memory
scope and takes, perhaps, 50 milliseconds. If the operator has not requested a solution, the computer wastes
no time and skips to the next terminal for interrogation.
Under these conditions each terminal operator usually
receives a response to his solution request in a fraction
of a second, and can obtain and display multiple solutions for different parameter settings about as fast as
TIME SHARED OPERATION WITH
TERMINALS
I t is estimated that complete setup time for all component configurations, switch-matrix registers, and
DCU and DRU settings will be approximately 10 milliseconds for the AD /FOUR automatic-programming
system. With integrators programmed at nominal
gain settings of 1000, this implies solution times of
perhaps 10 to 100 milliseconds for typical systems on
nonlinear differential equations. Such rapid program
Figure 7-Dynamics terminal
Electronic Patching for AD4 Hybrid Computer
he can reset the parameter-entry wheels and push the
solution button.
When operating with the AD/FOUR automaticprogramming system, the Dynamics Terminal will be
used to call up various programs using the 8 logic
pushbutton switches (256 combinations). Several of
the pushbuttons can be used to assign the 8 parameter
inputs to different groups of problem parameters. If a
given terminal operator calls for a solution, his problem
is programmed on the AD/FOUR computer upon interrogation of his terminal. If the problem has been stored
in core (roughly 500 words required for a typical large
problem), then the program setup takes only about 10
milliseconds. The net result is an access time essentially
comparable to that now enjoyed with the Dynamics
Terminal System, except that each user receives his
own problem when he ob_tains control of the computer.
When the relatively simple Dynamics Terminals as
described above are used for time sharing, initial setup
and debugging of each problem must be done using
the conventional hybrid I -0 and not through the
terminal. Obviously, it would be advantageous to have
a more sophisticated terminal which also allows problem setup and debugging, in addition to problem
running. This more sophisticated terminal will probably require a keyboard, alphanumeric display, and
perhaps even a mini-digital computer. In any case, if
problem setup and debugging is to be achieved through
terminals while time sharing the hybrid computer with
other terminals, a very extensive and powerful software
system for time sharing will have to be available for
the digital subsystem.
A SIMPLE EXAMPLE
As a simple example for the programming of a nonlinear differential equation, consider the Vander Pol
equation:
(1)
A circuit for solving this equation using the AD/FOUR
automatic-patching setup is shown in Figure 8. Since
the solution is known to approach a limit cycle of
amplitude 2, we have indicated that x/2 is computed.
Th us x = 2 corresponds to x/2 = 1 (one machine unit)
at the output of integrator 201. Since DCU's can be set
to gains between -1.6384 and + 1.6383, the value of
the parameter fJ., as set on DCU 212, can range up to
1.6383/4"-'0.4096. Although the gain (time scale) of
the two integrators is under digital program control,
integrator gain constants of 1000 would normally be
used for a high speed solution. Under these conditions
the resulting oscillation would have a period of ap-
••
X
2
= JL( I-X I
383
•
X-X
,..--_ _ _(51
--( 210 . -_ _ _ _ _- - - J
-1.0000
(61
212l-----------....J
4JL
Figure 8-Automatic patching circuit for Vanderpol's equation
proximately 6 milliseconds, which means that for five
cycles to be displayed the solution would take about 30
milliseconds. The problem can be rescaled to allow
higher values of fJ. by simply reducing each integrator
gain by the same factor. For example, if the gain of
each integrator is reduced by a factor of 4, DCU's 200,
203, and 212 would be reset to 0.25, -0.25, and fJ.,
respectively. Now fJ. can range. up to 1.6383, and the
computer solution is one-fourth as fast as before. Thus
about 120 milliseconds are required for some five cycles
of the solution. Or by programming the basic integrator
time scales to X 10,000 instead of X 1000, about 12
milliseconds is required for five cycles of the solution.
It should be noted that the address and data format
currently used for setting DCU's in the AD/FOUR
is used for setting the switch registers needed to program the connections shown in Figure 8. The address
indicates the device to which the switch common is
connected (i.e., the signal source). The data word indicates the component to which the device is connected
(i.e., the signal destination). A simple table stored in
the digital computer transforms each such statement
pair to a pseudo DCU address and data word, and the
switch register setting is implemented with standard
HCR's (hybrid communication routines) as if it were
384
Fall Joint Computer Conference, 1970
setting a DCU. Thus the following list would be required to implement the switch settings in Figure 8:
Setting No.
(1)
(2)
(3)
(4)
(5)
DCU
DCU
DCU
DCU
DCU
(6) DCU
(7) MULT
(8) MULT
Source
200
201
202
203
210
212
200
201
Destination
AMP
AMP
MULT
AMP
MULT
AMP
AMP
AMP
.
!:t;x-Iyyp Q + Ixz p. + Nb
b b
b R b=
Izz
I zz
I zz
201
211
201
200
200
200
211
210
For clarity the switch setting numbers (1) thru (8)
are shown in Figure 8 to allow correlation between the
above table and the settings. Actually, in implementing
the switch settings the digital computer merely thinks
it is addressing and setting DCU's, so that existing
HCR's (hybrid communication routines) can be used.
Although the example in this section is very simple, it
illustrates the implementation of the AD/FOUR automatic patching scheme for solving a nonlinear differential equation. The actual switching configuration
described in this paper evolved from considering the
program for much larger problems, e.g., 'nonlinear
partial differential equations, six-degree-of-freedom
flight equations, complex control systems, etc.
AN EXAMPLE SOLUTION FOR NONLINEAR
FLIGHT EQUATIONS
As a second example, consider the solution of the sixdegree-of-freedom flight equations. The automatic
patching program for these equations requires approximately three fields of an AD/Four, the exact number
of components depending on the complexity of the aerodynamic functions. One field of the program is illustrated in Figure 9, where the program for the translational and rotational equations is illustrated. The
following equations result from the summation of forces
along the flight-path axes and moments about the
bodyaxes: 5
.
Xw
g
Vp = - ' - -
mg V max
(6)
Here Vp is dimensionless total velocity; a and {3 are
angles of attack and sideslip, respectively; P b, Qb, and
Rb are body-axis angular-rate components along the
respective, x, y, and z body axes; PbS and Rb8 are roll
and yaw rates along stability axes; X w , Y w , andZw are
external forces along the respective flight-path axes;
L b, M b, and Nb are external moments along the respective body axes.
In writing Eq. (3) we have assumed {3«1, and in
writing Eqs. (5), (6), and (7) we have omitted nonlinear terms which are negligible in effect. 5
The external force components X w, Y w, and Zw along
the flight-path axes are derived from force components
X s, Y s, and Zs along the stability axes by resolution
through the sideslip angle (j. Thus
mgvp V max
Y w = - X sin{3 + Y s cos{3
(9)
(10)
The force components along the stability axes are
obtained from body-axis force components X b, Y b, Zb,
respectively, by resolution through the angle of attack
a. Thus
(11)
X8=Xb cosa+Zb sina
Y =Yb
(12)
Z8= -Xb sina+Zb cosa
(13)
8
Finally, the body-axis force components include
gravity, propulsive, and aerodynamic terms, as shown
in the following equations:
Xb
-
mg
Yb
-
(3)
mg
(5)
(8)
Zw=Zs
(2)
(4)
Xw=Xs cos{j+ Y s sin{j
8
mg
Zb
.
Yw
g
{j= - - - - -Rb8
(7)
-
.
Xp
qS
- - CD (1I!, a)
= - smO+ -
mg
•
mg
qS
= cosO smcp+ -
mg
qS
= cosOcoscp- -
mg
(14)
Cy(M, (3)
(15)
CL(M, a)
(16)
where 0 and cp are conventional pitch and bank angles
respectively, q is the dynamic pressure, and S is the wing
area. Also contained ih Eqs. (14), (15), and (16) are
three aerodynamic functions of two variables each involving Mach number M along with a and {j.
The moments L b, M b, and Nb in Eqs. (5), (6), and
Electronic Patching for AD4 Hybrid Computer
(7) are obtained from the following equations:
Lb=qSbC l
(17)
Mb=qSCCm
(18)
Nb=qSbC n
(19)
where b is the semispan, c is the characteristic wing
chord, and Cl, Cm, and Cn are, respectively, the aerodynamic coefficients for roll, pitch, and yaw moments
about the body axes.
The circuit for implementing the solution of Eqs.
(2)-(19) using automatic patching is shown in Figure
9. Components are numbered on the basis that the
program is implemented in field 2 of the AD/Four.
Fields 0 and 3 are used to solve the remainder of the
six-degree-of-freedom flight equations. Shown in Figure
9 is the circuit for automatic patching of two resolvers
in a field (resolver 670 and 671 in the figure).
The resolver input angles, respectively, are driven by
amplifiers 230 and 231. X and Y inputs to resolver 670
are buffered with bipolar summing amplifiers 202 and
203, respectively. The Y inputs of multipliers 200 and
201, normally driven by these amplifiers, are instead
both driven by quad DCU amplifier 120. Similarly, the
X and Y inputs to resolver 671 are buffered with bipolar
summing amplifiers 242 and 243, respectively, while the
Y inputs to multipliers 240 and 241 are driven by quad
DOU amplifier 121. The outputs X' and Y' of resolver
670 are terminated in DCU pairs numbered 246, 247,
and 256, 257, respectively. Similarly the outputs of
resolver 671 are terminated in DCU pairs 266, 267, and
276, 277, respectively. Each of these DCU pairs lowers
the numbers of DCU's driven by the corresponding
quad DCU amplifiers from 4 to 2 DCU's.
Note in Figure 9 that there are 3 signals from adjacent fields terminated in quad DCU amplifiers (numbers 122, 123, and 130). Note also that there are 6
signals from an adjacent field originating in DCU's in
that field (numbers 100, 102, 110, 112, 120, and 122) .
These are terminated in field 2 as currents into summing junctions. This illustrates the typical interfield
trunking capability of the AD/Four automatic patching system.
The circuit in Figure 9 includes three 2-variable
function generators and illustrates the power and
flexibility of the automatic patching· system. For example, amplifier 200 along with multiplier 251 implements Eq. (14) in its entirety, i.e., generates a function
of two variables, multiplies the function by a third
variable, and sums the result with two additional
terms.
Altogether the circuit in Figure 9 utilizes 15 out of
the 16 summer integrators in field 2, all 12 multipliers,
both resolvers, and 5 out of the 8 quad DCU amplifiers.
385
Following the format given in the previous example,
we have the following list required to implement the
autopatch settings in Figure 9:
Setting
No.
(1)
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9)
Destination
Source
DCU
AMP
DCU
AMP
DCU
MULT
DCU
DCU
DCU
204
300
224
301
234
251
102
201
256
MULT
AMP
MULT
AMP
MULT
AMP
AMP
REX
AMP
251
122
251
123
251
200
200
670
240
etc.
DCU settings, including those of reference DCU's such
as number 600, are implemented in the usual manner,
using the DCU address and 15 bit data word.
SUMMARY
There is a trade-off between hardware and software in
any automatic patching system. By choosing a system
of only three large modules of sixteen integrators each
we have enormously simplified the setup procedure,
allowing a direct programming technique without the
need for any fancy interpreter, i.e., standard HCR's
are utilized to control the interconnections. Indeed
the setup procedure is so direct that it is felt that there
is no additional training burden in implementing this
system.
The number of switches in the system is modest,
according to the following list:
Switches per Field:
64 DCU's to 28 S.J.'s
12 MULT S.J.'s to 16 S.J.'s
8 QUAD DCU AMPL to 16 Outputs
8 DUAL COMP to 9 AMPL
1792
192
12.8
72
2184
Interconnection between Two Fields:
512
(16 DCU'sX16) X2
(8QUADDCUAMPLto160utputs)X2 256
Total Switches
768
386
Fall Joint Computer Conference, 1970
One Field System
(16· Integrators)
2184
t-
Two Field System
(32 Integrators)
[II]
13001
2184
2184
768
[Oil]
nOll
5136
Three Field System
(48 Integrators)
2184
2184
2184
768
768
768
8856
NOTE' terms - . in bnICkeIs (
]
indicate iftpuIs !"""other !;.Ids.
[*c~
11301
I
T
These numbers compare very favorably with those
of other systems previously cited. Reference (3) points
out the advantage of a current-patched computer in an
automatic patching system. However, the profound
advantage of implementing such patching in a computer equipped with only digital coefficient devices and
controlling the interconnections ("patching") with
the same software which sets the coefficient devices has
been .overlooked.
I t can be seen from the switch quantities that the
system will add about 20 percent to the cost of the
hybrid system, a figure which can be substantially recovered in the saving in patching hardware alone.
The system is flexible. Since it is implemented on a
patchboard, the patchboard can be modified easily.
Moreover, this patchboard can be removed and the
computer can be used in the traditional way. Also large
numbers of consoles can be easily and economically
retro-fitted with this system.
Finally, the system uses modern switches, e.g., electronic. This will allow true hybrid time sharing providing the rather large software investment is made.
Even without such an investment the system will provide time sharing of the analog console with complete
re-patching between runs.
Figure 9-Field 2 automatic patching circuit for translational
and rotational flight equations
REFERENCES
1 D A STARR J J JOHNSON
The design of an automatic patching system
Simulation June 1968
2 G HANNAUER
A utomatic patching for analog and hybrid computers
Simulation May 1969
3 T J GRACON J C STRAUSS
A decision procedure for selecting among proposed automatic
analog computer patching systems
Simulation September 1969
4 A I RUBIN
Hybrid techniques for generation of arbitrary functions
Simulation December 1966
5 L E FOGARTY R M HOWE
Computer mechanization of six-degree-of-freedom flight
equations
Simulation October 1968
Digital v~ice processing with a wave
function representation of speech*
by JOHN D. MARKEL and BERNARD CAREY
University of California
Santa Barbara, California
INTRODUCTION
Development of a wave function approach
Digital voice processing has advanced to a relatively
high level of sophistication due to the development of
the fast Fourier transform (FFT) algorithm.1,2 Completevocoder systems have been developed around the
FFT& and with the advent of high-speed integrated
circuits and read-only memories to implement sine and
cosine tables for the FFT, actual real-time hardware
processing has been accomplished. 4
Anyone familiar with analog vocoder systems is
aware of the somewhat unnatural sounding synthetic
speech output. There are two major reasons for this:
first, pitch must be extracted and reinserted quite accurately, and secondly, the consonant sounds must be
accurately represented because of their relatively short
duration but yet important perceptual quality. The
problem of accurate pitch extraction performed by a
fundamental frequency tracking filter in the analog
systems is effectively eliminated in the digital vododers
by the application of ceptral techniques in conjunction
with the FFT.5 However, the difficulty with generating
natural sounding consonants is still present which is an
inherent difficulty due to the frequency domain method
of generating the transient sounds.
In this paper we will· describe a basically new ap;.,
proach to digital voice processing which will be called
a "Wave Function Analysis and Synthesis System,"
due to the appearance of the basis elements (or functions) which are used in the repre~entation of the
speech. It is basically a time domain system as opposed
to the standard vocoder which performs the representation mainly in the frequency domain. With this
system we will demonstrate the capability of quite
accurate and natural sounding generation of synthetic
speech.
Several years ago Dr. Glen J. Culler of UC-Santa
Barbara observed that many sounds of speech, when
properly filtered, could be represented by derivatives
of the Gaussian function exp( -t2/2).6 It was discovered
that the nth derivative could be described explicitly
by a Gaussian function multiplied by the Hermite
polynomial of degree n. These functions are known to
satisfy the differential equation7
u(t) +at u(t) +b u(t) =0
u(O) =Cl u(O) =C2
(1)
with the particular form
where n is a nonnegative integer and gn (t) is the nth
derivative of the normalized Gaussian function. From
this point the equation was generalized to allow for
noninteger coefficients, expansion or contraction of the
solutions, time shifts and phase shifts. The general
form is6
u(t) + (2-11/ S)2(t-C)U(t)
+ (27r/ S)2(N2- ~)u(t) =0
(3)
with initial conditions given by
u( C) =A cos
u(C) =A(27rN/S) sine/>
The basic hypothesis behind the use of this differential
equation for analysis of speech is that properly filtered
speech can be represented by. members of the wave
function family described from its solution. The parameters of this equation have been chosen so that physically meaningful relationships are being used. Figure 1
illustrates a representative solution to equation 3. The
rationale behind the use of these parameters is that A
corresponds to the peak of the envelope which encloses the wave function, S is a spread factor within
* This work was supported by Advanced Research Projects
Agency, Contract AF 19(628)-6004.
387
388
Fall Joint Computer Conference, 1970
.......- - - - s --------....
desired wave functions based upon a four-point analysis
around each major sweep (to be defined shortly). First,
a brief discussion of the basis set chosen for the analysis
and synthesis will be presented and then the algorithms
pertaining to the automatic voice processing system
will· be considered.
A
The Gaussian cosine modulation (GCM) wave/unction
formulation
The basis elements we will use in the algorithm are
generated as asymptotic solutions to equation 3.
Through the use of an asymptotic form of the confluent
hypergeometric function (which is required for expressing the exact time domain solution to equation
3), the surprisingly simple resultS
t=c
Figure I-Representative wave function showing parameters
(N is approximately the number of half cycles under the envelope)
whose value nearly all of the energy of the solution lies,
C is the center of the envelope of the wave function, cf>
is the effective phase of the solution with respect to C,
and N is roughly the number of half cycles that would
be measured under the envelope function. V sing equation 3 as a reference, the major part of the analysis is
based upon development of algorithms for automati...
cally extracting the five parameters· mnemonically
referred to as the ASCON parameters from the. speech
wave.
Our motivation for simulating an automatic voice
processing system based upon the wave function approach is based upon two main factors: (1) V sing the
VCSB speech on-line station developed by Culler it
has been demonstrated that high-quality synthetic
speech can be generated from the wave function parameters extracted from real speech, and (2) an asymptotic
solution to equation 3 has been obtained which is of
closed form and yet is valid with respect to it over
nearly the ·whole range· of analysis, thus considerably
simplifying the algorithmic difficulties in transforming
speech into wave· function parameters. .
One ;of the major problems in the wave function
analysis-synthesis method is that of performing the
mapping from the speech wave to the parameters' of
the diff~rential equation (or wave' function solution).
Since:the desired goal is to make a "best" fit to the
speech wave in some sense with a known basis set, the
criteria for "best" will determine the algorithm. In this
paper we will describe a procedure for extracting the
ua(t) =A exp[a(t-C) 2/4] cos[Wo(t-C) -cf>]
(4)
is obtained where ua(t) is the asymptotic solution,
The solution is thus a Gaussian probability function
with a mean of C (sec.) and standard deviation of
(2/a)1/2 (sec.) modulated by a cosine wave of peak
amplitude A with center frequency Wo (rad/sec.).
This is a rather concise result to be derived from such
forbidding sounding names as confluent hypergeometric functions. However, if the requirement for
validity of the asymptotic solution (2N2_Y2 is "large")
is unrealistic with respect to physical speech, then the
fo;mulation is of limited value. It has been experimentally demonstrated that these asymptotic solutions
match the solutions generated recursively from equation 3 over nearly the whole range of speech. The two
representations have the most error for small N. It
has been observed that the smallest N values (around
2-2.5) occur in the (100-400) Hz segment of the speech
range of interest. Figure 2 shows the asymptotic solutions ahd the recursive solutions forN = 2 and N = 3.6.
For N greater than 4 the two solutions are indistinguishable. Therefore it is proposed that a more meaningful,differential equation to use as the mathematical
foundation from which the wave 'function family
w (t) = U a (t) is derived is the one which has the solutions
in equation 4 as· exact and not asymptotic solutions.
By differentiation of equation 4 and substitution into
equation 5, one can verify that the GCM differential
equation is
wet) +a(t-C)w(t)
+ {wo 2 +a/2+[a2 (t-C)2/4]}w(t) =0
(5)
Digital Voice Processing
i------t-
5
c~~:i.,..
t
o
I
\/CUller FonrulAtion
~+---------~~--~---r--_\~~---------A
= 1.0
S = 7 msec.
C = 9 msec.
¢ = 170 degrees
'GCM Formulation
N = 2
1?,
b
1b
1
TIME
~ +
I
1---
~~ r+'__________-6~~~~~~~------------
c:'
~
<
A = 1
\
S = 6 msec.
C = 9 msec.
¢ = 90 degrees
N =
~rror
between Culler
and GCM Formulations
3.6
r)~--±b--~~~~~~--1?~t---lb+---1+
TIME
Figure 2-Comparison of recursive solutions to Culler
formulation and exact solution to GCM formulation
with initial conditions specified by
w(C) =A coscp
w(C) =A
Wo
389
5. Residue Calculation-After the envelope and
cosine wave parameters have been extracted,
the corresponding wave function is synthesized
and subtracted from the filtered speech.
Figure 3 shows the proposed block diagram of the
analysis system. The preprocessor performs the digital
filtering of the signal into sub-strings covering the
(100,3000) Hz range. The major sweep detector performs the task of isolating a region around which a
wave function will be fit. Calculation of A, S, and C
corresponds to fitting an envelope around the major
sweep which satisfies some predefined error criteria.
Calculation of Phase cp and Frequency F corresponds
to fitting a cosine wave to the speech which matches
closely in the region of the major sweep.
Once the parameters have been generated, the corresponding wave function is generated over the region
I t- C I < 8/2. By subtracting this function from the
incoming channel signal, the error or residue is generated which can then be represented by the next wave
function. Conceptually, the representation process is
carried on independently for each substring (as denoted by the bold arrows) implying a multiple inputoutput configuration. The process of fitting a single
wave function to local segments of the substrings is
repeated over and over until the total time interval of
interest has been analyzed. Each of these processes
will now be c T B - TA in all cases. As a first attempt at finding
an upper bound to S it has been decided to measure
the distances of straight line intersections from T A
with the time axis. A problem arises when two of the
extrema happen to take on nearly equal values. In that
case an upper bound is defined which depends on the
effective frequency of speech sample and a pre-determined maximum N value. The bound is set at
terms frequency (as applied to the cosine wave) and
effective frequency (as applied to four points) would
be identical. Assume that tn, n=O, 1, 2,3 are the times
for which extrema are measured in the vicinity of the
major sweep. The frequency estimator will be defined
as
3
F = Y6 ~ (tn -tn_I)-I.
n=l
The phase will be defined so that a close fit is made at
t= T2 (T2= TB in the previous section), i.e.,
cos[21rF(T2-C) -cf>]= ±1
depending on the major sweep slope. Therefore
To obtain rapid convergence in the algorithm it is
necessary to operate upon 1/ S instead of S since S
takes on a relatively large range of values. If S> 1
(msec.) for all conditions, then O
and F. In terms of equation 3,
A logical criterion to apply in the determination of F
is that near the center of the wave function the effective
frequency equal F. The word effective is used because
we are defining frequency from only four points in time,
nearest C. If the speech were a cosine wave then the
Residue calculation
To make an accurate wave function representation
from filtered speech the wave function corresponding
to the extracted parameters around a major sweep
must be subtracted from the original waveform before
proceeding in the analysis for the next wave function.
This is because the parameters extracted over a limited
interval of time describe a wave function that extends
over a larger interval, i.e., for a small portion of time
past the major sweep, the future values of the signal
are being predicted. Thus subtraction of the wave
function from the original signal generates the error or
residue which is then analyzed for the next wave function. An additional task of the residue calculation portion is to set the index at which the sweep detector will
start next. Its choice to a large extent determines the
efficiency (and also accuracy) in the representation.
The minimum value for the starting index of the next
wave function in this study was set at (C+TD)/F s
where Fs is the sampling frequency, T D is the last
extrema point (largest time value considered) and C is
the center of the wave function envelope. Figure 9
shows the representation and residue from filtered
vowell A/ as in "up" over (900,2000) Hz. Summarizing
the operation of the GCM analyzer, the algorithmic
procedure for extracting the string of ASCOF parameters is as follows: The peak values and corresponding
times of the sampled substring sn(k), k=l, ... ,4 are
obtained. Then a major sweep is isolated. Applying the
algorithms just described, the wave function parameters are calculated. Using these parameters, the corresponding wave function is calculated and then subtracted out from the original speech data. The residue
Digital Voice Processing
is then operated upon in the same fashion to obtain
the next set of parameters from the substring. Thus the
process is basically an on-line system that conceptually
with appropriate buffering could be a real time process
since the analyzer inputs sn(k) are also conceptually
real time operations. One can visualize the system then
as a 4 analyzers X5 parameters/wave function=20
channel system whose bit rate wiil vary depending
upon the incoming information rate. This is a rather
significant aspect of the system. Note that no voiced/
unvoiced decisions are required as in a channel vocoder.
All time references are contained in the C parameters.
395
tion of equation 4. Thus
Sn(k) =
L 4>[n(i, n), k]
i
where n (i, n) denotes the ith set of wave function
parameters corresponding to the nth substring, and k
denotes the discrete time index, i.e., t = kT, k = 0,
1, ... , where T is the sampling period. The symbol 4>
denotes the wave function as a function of these variables. In computational form,
4>[n(i, n), kJ=A(i, n)
X exp{[kT-C(i, n)]201l"2/S(i, n)2}
o
cos {21l"F(i, n) o[kT-C(i, n) ]-4>(i, n)}
where
Wave function synthesis system
n (i, n) = {A (i, n), S (i, n) , C (i, n) , 4> (i, n), F (i, n) }.
As opposed to the various types of voice processors
now in use, by far the major share of computation is
required in the analysis system. Assuming that the
twenty channel signals have been correctly sorted into
the four different time varying parameter sets, the
synthesis is nearly a trivial matter. The synthesized
substrings Sn(t) , n= 1, ... , 4 are .obtained by applica-
Since each wave function amplitude decreases as an
exponential squared, only the wave functions located
nearest to the corresponding present time t need to be
evaluated at the index k.
The total synthesis of the estimated string is denoted by s(k) and is calculated in discrete form by
summing the substrings. Thus
4
s(k)
=
L sn(k)
n=l
~(t)
EXAMPLES FROM SYSTEM SIMULATION
Residue
=
set) - get)
TIME
Figure 9-SJomparison of filtered region of IAI as in up,
R = (900,2000) Hz and the wave function representation along
with the residue. Representation composed of eight wave
functions.
As a demonstration of the wave function approach
to speech analysis and synthesis, two multiphoneme
words were chosen. The first is the word "large" which
consists of the semi-vowel /1/, the vowel /a/, the semivowel /r/, and the plosive consonant /g/. The second
word is "men" which consists of the closed mouth
nasal consonant /m/, the vowel /1/, and the open
mouth nasal consonant /n/. These words contain
enough of a variety of the . basic phonetic sounds to
illustrate the accuracy of the wave function speech
analysis and synthesis system.
Each word was uttered by a male speaker. Figure 10
shows a block diagram of the computer system that is
used to simulate and observe the wave function speech
analysis and synthesis system which has been described.
The speech passed through an A/D converter which
sampled the acoustic waveform at a 17.5 kHz rate with
an 11 bit quantization precision. 7,440 16 bit words,
which represent 420 milliseconds of the sampled speech,
are stored in the IBM 2311 magnetic disk storage system. The sampled speech word is filtered four separate
times into the four substrings Sn(t) , n= 1, ... , 4.
These represent the .(100,3000) Hz frequency region.
396
Fall Joint Computer Conference, 1970
FREQ
2
(KHZ)
1
o
G E
L
time
A R
L
t
-+- "
'q'";YNAL
SYfIlTHF"
Figure 12-Comparison of spectrograms for
Figure 10-Block diagram of system used to implement the wave
function analysis synthesis system
Each substring is then analyzed into its set of wave
function parameters which are also stored in the 2311
system. Each parameter set is operated upon by the
wave function synthesis program to generate its corresponding synthetic substring which is stored in the
G E
1 ;nt'
word
"large"
2311 system. The four synthetic substrings are summed
together to form the synthetic string set) which is also
stored in sampled form. At this point the original
speech string, the four synthetic substrings, and the
synthetic speech are all available for comparison and
examination. They can be examined by visual observation on the Tektronix 611 storage display or listened
to after the digital word is passed through a D / A
converter-amplifier-speaker system.
"Large"
Original
s
(t)
"Men"
Original
s(t)
"Large"
Synthetic
§ (t)
"Men"
Synthetic
§(t)
o
time (msec)
420
Figure ll-Comparison of original versus synthetic for
word "large"
o
420
time (msec)
Figure 13-Comparison of original vs synthetic for word "men"
in range (100,3000) Hz
Digital Voice Processing
397
2 W T COCHRAN et al
What is the fast fourier transform?
IEEE Transactions on Audio and Electro-acoustics Vol
AU-15 No 2 June 1967
FREQ
2
(KHZ)
3 A V OPPENHEIM
Speech analysis system based on homomorphic filtering
JASA Vol 45 No 21969
1
o
M E
ORIGINAL
M
N
time
E
N
time
~
~
SYNTHETIC
Figure 14-Comparison of spectrograms for word "men"
Figure 11 shows the original word "large" and the
synthetic word "large" for comparison. As can be seen,
there are detectable differences between the two time
waveforms but a consistent agreement in their general
structure exists. Figure 12 shows spectrograms of the
original "large" and the synthetic "large" that were
taken on a Kay Electric Company 6061B Sona-graph.
It is apparent that excellent agreement exists between
the frequency structure of the origi:p.al versus synthetic
words.
Figure 13 shows the time waveforms of the original
"men" and the synthetic "men." Excellent agreement
exists between the two time waveforms and only close
examination can show the differences. Figure 14 shows
the spectrograms of the original versus synthetic
"men." The frequency structure of the synthetic word
is in close agreement with that of the original word.
REFERENCES
1 J W COOLEY J W TUKEY
An algorithm for the machine calculation of complex fourier
series
Mathematics of Computation Vol 19 No 90 April 1965
4 Applied Research Laboratory, Sylvania Electronic Systems
Real time digital vocoder demonstrated at 78th meeting of
Acoustical Society of America San Diego Calif November
1969
5 A M NOLL
Short-time spectrum and cepstrum techniques for vocal-pitch
detection
J ASA Vol 36 No 2 pp 296-302 1964
6 G J CULLER
An attack on the problems of speech analysis and synthesis
with the power of an on-line system
Presented to the International Joint Conference on
Artificial Intelligence May 8 1969 Washington DC
7 J A HOWARD R C WOOD
Hybrid simulation of speech waveforms utilizing a gaussian
wave function representation
Simulation Vol 11 No 3 pps 117-124 September 1968
8 J MARKEL
A gaussian cosine modulation (GCM) formulation for speech
analysis and synthesis
Computer Research Laboratory University of California
at Santa Barbara August 1969
9 B CAREY
Separation of the acoustic waveform into substrings
Computer Research Laboratory University of California at
Santa Barbara March 1970
10 J MARKEL
Considerations in the development of a wave function analyzer
Computer Research Laboratory University of California at
Santa Barbara January 1970
SIMeON-An advancement in the
simulation of physical systems
by B. E. TOSSMAN, C. E. WILLIAMS, and N. K. BROWN
Johns H opkins University
Silver Spring, Maryland
INTRODUCTION
SIlVICON SYSTEM DESCRIPTION
The simulation of physical systems, once exclusively
the domain of analog computers, is also being performed
today by a variety of large-scale digital systems. Many
specialized programs have been developed to. permit
the study of electronic circuits, biological organisms,
and chemical processes, etc., by mathematical and
empirical modeling techniques. So often these programs
are written in procedural computer languages and may
require months of developmental investment (and
debugging) to yield a handful of computer-produced
results. In addition, if simulation parameters are not
well known, it may take hundreds of test runs to produce a simulation model that realistically portrays the
actual processes involved. When the digital computer
utilized to perform the simulation is operated in a
batch-processing environment, such determination of
model fidelity may take weeks because of the time lag
from submission of test data to receipt of program
results. Smaller computer systems may permit almost
instantaneous turnaround and even on-line interaction, but too often do not have sufficie.nt memory size,
precision, or speed to be of much use in complicated
qigitalsimulations. The SIMCON simulation system
is an integrated hardware/software system developed
for the purpose of overcoming the difficulties of applying large-scale digital computers to the simulation
of physical systems. The SIMCON system, which is
used in conjunction with the IBM 360/91 computer,
consists of the DSL/91 programming language, the
SIMCON control console, a hybrid data interface,
and a number of analog graphical peripherals. The
SIMCON simulation system shown in Figure 1 includes the SIMeON console, incremental recorder
and duel-channel X -Y plotter. The discussion of the
SI1VICON system presented herein includes .. the results from several hybrid satellite study programs,
as examples of its application.
DSL/91 language
Quite often the simulation engineer or programmer
will find that a number of the blocks of his mathematical model involve representation of simple electrical or mechanical devices like flip-flops, relays, or
moderately complex transfer functions. Such application-oriented subprograms are rarely included in
PLl1 or FORTRAN libraries distributed by computer
manufacturers. In most cases, the routines will have
to be generated for the simulation program, and will
increase the amount of development time.
Figure 1-SIMeON. simulation center
399
400
Fall Joint Computer Conference, 1970
Figure 2-Simulation console
The SIMCON system offers a significant contribution by including a programming language for the
express purpose of digital simulation of continuous
system dynamics.
DSLj91 (Digital Simulation Languagej91) is
non-procedural, problem-oriented computer language!
designed to operate either in the batch-processing mode
or in conjunction with the SIMCON console2 in the
time-shared mode of the lVlodel 91's operation. Simulation models may be expressed either at the block
diagram level or as systems of ordinary differential
and algebraic equations. Since the language is basically
non-procedural, equations and data may be entered
in any order, with the task of proper statement sequencing being performed automatically by the language processor. DSL includes the FORTRAN IV
procedural language as a subset, thereby extending its
power to handle non-linear and time-variant problems
of considerable complexity. Furthermore, many frequently occurring simulation blocks such as relays,
switches, transfer functions, and function generators
are provided in a simulation-oriented subprogram
library.
Significant features of DSL/91 include a centralized
built-in numerical integration system providing a
choice of seven analytical techniques. These range
from ,a simple rectangular method to the very stable,
variable step-size, 5th order Milne Predictor-Corrector
method. Input and output of simulation data and results are accomplished by· pre-formatted I/O routines
with emphasis on ease of use, not versatility.
:z
Simulation control console(SIJIIICON)
In general, a simulation rarely performs in a manner
realistic to the physical system the first time, even if
correctly programmed. It is often necessary to run a
simulation many times before the values of the parameters that cause behavior equivalent to the real system are found.· In many cases the express purpose of
performing a simulation is to determine if an improvement in the real system's performance can be attained
by mere parameter optimization, rather than complete
redesign. However, both of these processes require
the results to be scrutinized by a trained and knowledgeable analyst, who can, in cases of multi-parameter
optimization, play an important role in the problem
solution. Thus, the ability of an engineer to observe
and control the simulation's execution enhances the
applicability of the digital computer to simulation,
especially if he can iteratively rerun the problem and
conveniently change data between, or even during,
the runs.
The SIMCON console, shown in Figure 2, is designed to operate in conjunction with DSL/91 simulation programs, providing man-machine interaction
during simulation execution. This would not be economically feasible on such a large system as the l\1odel
91 were it not for the OS/MVT monitor system. The
time-sharing environment permits other programs
to run concurrently with the SIMCON system, and
thus. no computer .time is wasted while the engineer
studies his results or adjusts parameters at leisurely
speeds. Furthermore, to increase the speed of manmachine interaction, the console is organized around
a function keyboard concept, rather than a typewriter. Thus, standard commands are initiated by
depressing buttons, rather than typing keyword
phrases. Display of problem parameters is accomplished
by alphanumeric NIXIE tube registers, rather than
typewriter printed output. Hard-copy results, if desired, are available on the high speed system line
printer.
The console is organized around an IBM 1892
Process Operator's Console (Model 11) with customerspecified button labeling, housed in a specially designed
cabinet. One section of the console buttons is provided
for control of program execution. Using these buttons,
it is possible to start, stop, single-cycle, and restart the
solution of the problem. Another button group controls the display of problem data in the NIXIE registers. The operator can select dynamically any three
of 50 preassigned program variables, and simultaneously
display these in floating:..point format. Furthermore,
certain special function buttons allow the display of
any program variable whose relative address within
the program is known, and the on-line assignment of
this variable to any unused address button of the 50
available. Other buttons of this group initiate program
dumps in scientific data formats, enable on-line selec-
SIMCON
tion of integration methods, and cause job termination. Finally, simulation data may be entered while
the simulation is halted via a 14 button numerical
keyboard, or dynamically modified by an incremental
potentiometer.
401
DATA CONTROL UNIT
(IBM 1827)
,-------,
I DIGITAL INPUT/OUTPUT 1 - + - - 1
L _____ --l
IBM
360/91
COMPUTER
A nalog graphical peripherals
In close proximity to the console are a number of
analog plotting systems capable of producing hardcopy graphics. A strip-chart recorder permits 8 problem
variables to be plotted parallel to each other on a
single continuous roll of reproducible paper. The
variables are graphed vs. the simulation time base,
with the paper chart being advanced by an incremental
drive. This technique prevents distortion due to multiprogramming during the simulation's execution. An
analog memory scope allows simultaneous plotting of
two variables against a third, with the resultant plot
being retainable for the purposes of photography.
Finally, a 30-inch vertical X -Y plotter can be used
to produce two simultaneous indpendent cross plots
which may overlap without damage to the plotting
mechanism.
Hybrid data interface
The hybrid data interface, an IBM 1827 Data
Control Unit, contains eight 13-bit Digital-to-Analog
converters and a sixteen channel 14-bit Analog-toDigital converter. Additional equipment, within the
1827, interfaces the 1892 Process Operator's Console
(SIMCON) to the System 360/91 computer as shown
in Figure 3. The D/A converters may be used to drive
external analog equipment other than plotters. Thus,
simulations may be interfaced to real analog hardware
to test the performance of prototype and final designs
functioning in an otherwise all digitally simulated
environment. This mode of simulation is currently
being used in the study of magnetically damped satellites, wherein actual flight hardware is coupled to the
SIlVICON system. Specific examples are covered in the
applications section of this paper.
SIMCON SYSTEl\1 OPERATION
Application programs for SIMCON are written in
DSL/91 and are translated in FORTRAN IV by the
DSL language translator, a self-contained .program.
The regular OS/360 FORTRAN compiler and linkage
editor are then used to produce an interactive load
module. The load module is a completely contained
f,;ULT-;-;(EXEil
I CHANNEL
L(~~~J
r------l
I
D/A CONVERTERS
L ______ J
Figure 3-Block diagram of SIMeON simulation system
executable program containing DSL system routines,
the SIMCON executive program, and a subroutine
representing the simulation mathematical model equations.
The load module's execution is controlled from the
SIlVICON console by depressing preassigned function
keys. Each of the 104 keys presents a unique 16-bit
code to a digital input register in the 1827. The SIMCON executive program interprets the button codes
and performs the desired action, providing feedback
to the operator at all times by means of backlighted
push buttons and NIXIE tube displays.
The software also contains terse diagnostic messages which are displayed using the alphanumeric
NIXIE tubes and are accompanied by an audible
alarm. These features serve to guide the user toward
correct operation of the console.
Several manuals have been written to explain the
operation of the system to non-computer oriented
persons. 1 ,2 With these manuals and occasional assistance from their authors, the system is used at APL
in an "open-shop" environment by engineers.
SIMCON SYSTElVI DEVELOPMENT
The development of the SIMCON system was a
joint undertaking by IBM, Harry Belock Associates,
and the Applied Physics Laboratory. The console
system was originally configured around IBM and
EAI components similar to the DES-P configuration
by D. Stemmer. HBA used the SIMCON system in
conjunction with a system 360/Model 44 computer.
APL became interested in the system when it was
first used by HBA to perform weapons system simulations under APL subcontract. In August, 1968, HBA
returned their leased Model!44 computer to IBM and
transferred the console system to APL.
402
Fall Joint Computer Conference, 1970
DIGIT AL 360/91
ANALOG HARDWARI
system, including simulation language (DSL/91),
console executive routine (SIMCON), 1827 and
1892 Input/Output Access Routines, runs under OS/
MVT (or lVIFT) in "program state," using the OS
input/output supervisor for I/O services. The development, testing, and debugging of the redesigned system
at APL required about 18 man-months effort over a
six month period.
SIlVICON SYSTEM APPLICATIONS
COMPUTE GRAVITY.GRADIENT
AND SOLAR RADIATION
PRESSURE TORQUES
Figure 4-Simplified flow chart of TRIAD· hybrid simulation
The original software for the SIMCON system included a simulation language and a set of programs
which interfaced the DSL language to the SIMCON
hardware. The DSL/44 simulation language4 was
written by D. G. Wyman and W. M. Syn of IBM.
The interface programs were called Process Operator's
Console Support 1, written by R. Bloom of IBM.5
At HBA, these programs operated under 44PS, an
executive system for the 360/44, and occasionally
operated in supervisory state.
DSL/91 is an outgrowth of that simulation language, with language extensions developed at APL
and an improved interface to the console program.
A totally new set of console programs was developed
by HBA under subcontract .to APL, to replace
the original P.O.C.S. 1 programs. The integrated
Since most physical systems are described mathematically by means of differential equations, DSL/91
is of great utility in their representation and solution
by digital computer. Aerospace, bio-medical, and
transportation system engineers are primarily interested
in the design and optimization of control systems.
Here, DSL's transfer function blocks permit easy
representation of complex transfer function networks.
Today, however, we find increasing use of discrete
control systems often based on the application of a
digital computer as a part of the system itself. The
ability to model complicated logical procedures by
intermixing DSL and FORTRAN statements permit
thB complete digital simulation of such discrete hybrid control systems. At APL, the SIl\1CON system
has been utilized in simulations of a fire-control radar
system, guided missile target engagements, projectile
rotational dynamics, and closed-loop satellite attitude
control systems. Of these simulation programs, the
most challenging and comprehensive have been the
satellite attitude control programs. These programs
have been designed around the hybrid interface to include actual hardware in the simulation and make
maximum use of the SIl\1CON's parameter change,
run control, and concurrent data display capabilities.
Satellite attitude control system simulations
This section presents the application of the SIl\1CON
system to hybrid simulation of spacecraft with magnetic damping systems. The hybrid simulation consists
of a digital solution of rigid body attitude dynamics,
coupled, via SIl\1CON and its D/A and A/D interfaces, to an analog spacecraft attitude control system.
This type of simulation was used in a study of the
NASA GSFC Radio Astonomy Explorer-B,6 APL's
OSCAR and TRIAD7 spacecraft and earlier by Gluck
and Wong (without SIMCON).8
A simplified flow chart of the APL hybrid simulation
is shown in Figure 4. The bulk of the simulation is
performed digitally, while the analog portion consists
of analog-type attitude control systems. In general,
SIMCON
the control system in its space environment receives
as inputs the earth's magnetic field, as a vector in body
coordinates. The control system includes elements
which exhibit magnetic hysteresis and which cannot
be satisfactorily modeled digitally. The outputs of
the control system are signals proportional to magnetic dipole moments which, interacting with earth's
magnetic field, produce desired torques. The digital
portion of the simulation includes:
1. Computation of earth's magnetic field vector
at any point in the satellite orbit via a 48 term
Legendre expansion;
2. computation of attitude disturbance torques
deriving from aerodynamic, gravity-gradient
and solar radiation pressure; and
3. integration of the equations of· motion using
elements of the attitude transformation' matrix
as integration variables.
CENTER OF MASS
10 FOOT EXTENDIBLE BOOMS (2)
MAIN ELECTRONICS UNIT
Figure 5-TRIAD orbit configuration
403
LOCAL MAGNETIC FIELD
NORteiAL TO PLATFORM)
"EARTH
(
(D/A INPUT SIGNAL)
SOLENOIDS WITH
(D/A INPUT SIGNAL)
Figure 6-Hysteresis rod setup for computer
OSCAR and TRIAD simulations
OSCAR and TRIAD are gravity-gradient stabilized
magnetically damped spacecraft. Both utilize an extended structure such that a large difference' in the
body moments of inertia give rise to gravity-gradient
torques tending to orient the extended axis earthward.
TRIAD includes, in addition, a high speed momentum
wheel which orients a second axis along the orbit normal. The TRIAD configuration is shown in Figure
5. Both satellite systems are in relatively near earth
orbit ranging from 890 to 1100 km altitude.
Spacecraft librations (motion' of the extended axis
about the local vertical) are damped by the interaction
between long rods of a material which exhibits magnetic
hysteresis and earth's magnetic field. These rods are
installed within the solar panels. In the past, prediction of the attitude behavior of these satellites was
based on highly complex digital models of the hysteresis function. The digital models were extremely expensive to run, often conflicted with each other and provided only general attitude patterns.
In the SIMCON hybrid simulation, an actual set of
magnetic hysteresis rods, operating in their true analog
environment, are linked to a digital simulation. The
two rods are attached to an "L" shaped platform in the
same relative position as on the extended solar panels
(see Figure 6). The entire platform is positioned normal to the earth's local magnetic field .. Solenoids, surrounding each rod, are driven by the computer (via
D I A converters) and produce a magnetic field equal
to that .which would be observed by each rod .if it
were in flight. Magnetometer sensorsadj acent to each
rod sense the rod magnetization and provide a signal
to the computer, via an AID converter, proportional
to the dipole moment of each rod. It is noted that the
404
Fall Joint Computer Conference, 1970
ANGLE IETWEIN SATELLiTe Z."XI$ AND LOCAL VERTICAL
Figure 7-TRIAD steady-state dynamics computer results
magnetometer sensors are positioned such that there
is no crosstalk between a magnetometer and an orthogonal rod.
Operating in the SIlVICON environment, we are
able to check the alignment and calibration of the
hysteresis rod setup as an initialization phase of digital
simulation. In addition, during execution, the simulation can be put into a "hold" mode while simulation
study can be performed in one sitting.
Figure 7 is a representative example of the graphical output generated during a TRIAD simulation. In
this case, the satellite's steady-state dynamics as a
function of two different hysteresis rod volumes were
examined. Using SIlVICON, the effective rod volume
was increased, from 2 cm3 to 8 cm3 , after simulated
hours. The difference in the TRIAD steady-state
attitude angles, resulting from the rod modification
(a capability also built into the real system), is displayed in Figure 6.
The execution cost of TRIAD and OSCAR hybrid
simulations have averaged $1.50 per simulated orbit
or $20 per simulated day. There are twelve variables
of integration with magnetic field computation and
D / A and A/D conversions performed every 10 seconds.
Radio astronomy explorer satellite simulation
The RAE hybrid simulation was similar in execution to the OSCAR and TRIAD with the exception
that the analog portion consisted of a complete flight
attitude control system electronic package. The RAE
attitude' control system, as described in· Reference 9,
consisted of a set of magnetometers, electromagnets
and a signal processing package which included a
hysteresis function generator. Hysteresis rods could
not be used· because of the exceedingly weak magnetic
field at the RAE altitude (6000 km). The hysteresis
function generator along with the electromagnets
provided a damping system equivalent to an extremely
large set of hysteresis rods. The flight hardware also
included a command link for changing operating modes
of the system and the gain of the hysteresis function
generator.
This RAE simulation demonstrated the following
capabilities of hybrid simulation via SIMCON:
1. the magnetic control system hardware was
exercised in the same fashion as it would be
operated in orbit;
2. all the digital facilities of the IBM 360/91 in a
time-sharing multi-variable task environment
were fa vailable;
3. execution of program control via man-in-theloop interaction was provided by the SIMCON
terminal; and
4. concurrent analog display of control system
performance was provided by analog peripherals, including the eight channel incremental
recorder.
SUMMARY
SIMCON has been presented as a significant advancement in the simulation of physical systems. It includes
a digital simulation language for describing the dynamics of continuous systems and an interactive terminal for continuous program monitoring and hybrid
capability.
DSL/91, the digit.al simulation language adapted
to the IBM 360/91, utilizes the building block approach of digital-analog simulators but retains the
power of logical and algebraic equation notation. DSL
and FORTRAN statements may be intermixed allowing
existing FORTRAN subroutines to become DSL
function blocks.
The SIMCON control console allows on-line monitoring of problem execution, modification of data,
early termination of a run or execution· of sequential
runs. The console, in conjunction with DSL/91, can
thus test real physical system components in a closedloop interactive environment as illustrated by the
RAE and TRIAD simulations.
REFERENCES
1 N K BROWN
DSLj91 programmer's guide
JHUjAPL Report BCE-T-0142 April 1 1970
2 R L McCUTCHEON
Simulation console operator's guide
JHUjAPL Report BCP-461 (BCE-T-0143) November 1969
SIMeON
3 L LEVINE
A new digital computer for solving differential equations
Simulation April 1965 (DES-1)
4 S M SYN D G WYMAN
An IBM 360 Model 44 program for the simulation of process
dynamics
(DSLj44) Contributed program No 360D 43.1.002
5 R BLOOM
Process operator's console support 1
(POCS1) Contributed Program No. 360D 16.8.001
6 BE TOSSMAN
RAE-B hybrid simulation and improved magnetic stabilization
system
APL Internal Memorandum S2P-2-238 April 7 1969
405
7 C E WILLIAMS B E TOSSMAN N K BROWN
Interactive hybrid computer simulations of magnetically
damped spacecraft
To be presented at AIAA Guidance Control and Flight
Mechanics Conference Santa Barbara California August
17-191970
8 A WONG R GLUCK
Inline hybrid computer for simulation of passively stabilized
satellites
Journal of Spacecraft and Rockets Vol 6 No 7 July 1969
9 B E TOSSMAN
Magnetic attitude control system for the radio astronomy
explorer-A satellite
Journal of Spacecraft and Rockets Volume 6 No 3 March
1969
COMSL-A communication system simulation language
by R. L. GRANGER and G. S. ROBINSON
Communications Satellite Corporation
Washington, D.C.
INTRODUCTION
model can be written in a few hours whereas a similar
model written in a general purpose language, e.g.,
Fortran, might take a capable programmer several
weeks or even months.
A preliminary version of a translator which converts
valid COMSL statements into Fortran code has been
written. Care has been taken to ensure that the Fortran
code generated by the translator is as efficient as possible. For example, few subroutine or function calls
are generated by the translator except to compute
certain initial system parameters. Since the simulation
of most voice communication systems- requires a sampling rate of at least 8 KHz, a significant execution
time savings is achieved by avoiding numerous repetitive subroutine calls. The translator is embedded in
the operating system in such a way that its presence is
unnoticed by the COMSL programmer. A few simple
control statements together with the COMSL system
description is all that is required to obtain a voice tape
"produced" by the simulated system. For video communication systems a digital tape is produced from
which one or more "frames" can be obtained using a
flying-spot scanner.
In recent years, computer simulation has come to play
an important role in the design of communication
systems.1,2,3 Such systems frequently cannot be classified as either purely continuous or as purely discrete
but are, instead, a combination of both continuous
and discrete subsystems. The simulation of such hybrid
systems cannot readily be carried out either in a discrete simulation language such as GPSS or in a continuous simulation language such as CSMP. As a consequence, most simulation models of communication
systems are written in some general purpose higher
level language, e.g., FORTRAN, ALGOL or PL-l. A
notable exception to this general rule is BLODI and
BLODIB described in Reference 4. The simulation of
even moderately complicated communication systems
in a general purpose language poses several major
problems. First of all, the simulation model tends to be
time consuming to write and debug, difficult to modify
once written, an.d, unless considerable care is tak en,
requires an inordinate amount of time to execute. However, the most important weakness of a communication
system simulation model written in a higher level
language is that the model usually is written by someone with a limited knowledge of the actual system being
simulated. As a consequence, there frequently exists
the possibility that the simulation model differs in
some significant, but unnoticed, respect from the actual
system. Primarily to avoid this problem, a new simulation language, COMSL, is described which facilitates
the simulation of a wide variety of communication
systems.
COMSL, a Communication System Simulation Language, is designed for use by the typical communication systems engineer who frequently has a modest
knowledge of some higher level language but very little
experience in the use of that language. COMSL is a
block diagram oriented language which is relatively
easy to learn and to use. Given a block diagram description of a communication system, a valid COMSL
FUNCTIONAL CHARACTERISTICS OF COMSL
A simulation program written in COMSL consists of
the following four types of statements:
1. Block definition statements which define the
attributes of the various system blocks.
2. System definition statements which describe the
interconnection of the various blocks.
3. Signal analysis statements which permit the
computation of certain common statistics for
any arbitrary signal, e.g., first and second moments, signal-to-noise ratio and power spectrum
estimates.
4. Control statements which specify options re407
408
Fall Joint Computer Conference, 1970
lating to the translation, execution, and output
phases of a program.
5. User defined blocks written as standard Fortran
subprograms.
somewhat more lengthy, description of a given communication system.
As an example of a typical "system definition statement" consider the following:
X2=FILTR3 (XO).
Block definition statements
In order to simulate a given communication system,
the user examines the block diagram description of the
system and writes a single block definition statement
for each block that appears on the block diagram. The
block definition statements, which may be listed in any
order, are written in the following format:
BLKTYPE(BLKNUM, ATTRIBUTES).
FILTR(3, 1, 16, 250., 750., .5,).
(2)
By comparing the attributes listed above with those
listed under block type FILTR in Table 1, we see that
statement (2) defines a 16th order band-pass Chebyshev filter with cutoff frequencies of 250 and 750 Hz
and a pass-band ripple of .5 db. The filter has been
assigned an arbitrary BLKNUM of 3.
System definition statements
Having described the attributes of all blocks in the
block diagram using block definition statements described above, the user next describes the interconnection of the various blocks using so-called "system
definition statements." These are written in the following format:
Y = BLKTYPE'BLKNUM' (X) .
The above statement simply states that the input
to filter 3 is XO and its output is X2. The attributes of
filter 3 have, of course, been defined in a previous block
definition statement.
In order to avoid defining an unnecessarily large
number of trivial blocks to perform simple arithmetic
functions, the following basic operators are used:
(1)
BLKTYPE refers to one of the block types shown in
Table 1. BLKNUM is an arbitrary, but unique, number assigned to a particular block of this type. For
example, if there are six filter blocks in a particular
system, BLKNUM would take on values 1, 2, ... 6.
ATTRIBUTES refers to a list of attributes which define a particular block of type BLKTYPE. The following is an example of a typical block definition statement:
Symbol
Function
+
addition
subtraction
multiplication
division
exponentiation
*
/
**
Signal analysis statements
In the simulation of any system it is frequently
desirable to ascertain characteristics of a given signal
at an arbitrary point in the system. For example, one
may wish to know the signal-to-noise ratio at a particular point in the system. Alternatively, one may wish
to know the spectrum of an arbitrary signal. This is
accomplished in COMSL through the use of so-called
"signal analysis statements" which take the following
form:
COMPUTE CTYPE(S1, S2).
(5)
CTYPE is the pseudonym for the characteristic to
be computed, S1 is the signal to be analyzed and 82 is a
reference signal which mayor may not be needed. As
an example, assume that one wishes to compute the
signal-to-noise ratio at the output of a subsystem where
the input signal is XIN and the output signal is XOUT.
The following statement accomplishes this:
COMPUTE 8NR(XIN, XOUT, 1).
(3)
Y is an arbitrary name, subject to certain restrictions
mentioned later, assigned to the output of a particular
block. X is the input to the block and BLKNUM is the
arbitrary block number given to the block in the corresponding block definition statement. It is important
to note the one-to-one correspondence between block
definition statements and system definition statements.
While the two statement types could have been combined into a single statement type, it is felt that this
separation of assignment of block attributes and the
definition of system structure yields a more natural, if
(4)
(6)
At the termination of the simulation, the above statement causes the following to be printed once each
second for the duration of the simulation run.
SIGNAL-TO-NOISE RATIO= _ _db FOR XIN,
XOUT at time _ __
where
SNR=10 log..
[[E (XOUT,-XIN,)'/XIN,']/ N]
(7)
Communication System Simulation Language
409
TABLE I - Available Function Blocks
BLOCK TYPE
FILTR
FUNCTION
analog filter
GENERAL FORMl
FILTR (I, J, K, A, B, C, D)
BLOCK ATTRIBUTES
J = filter type
o-Butterworth
1-Chebyshev
2-Elliptical
K = the order of the filter
A = lower cut-off frequency
B = upper cut-off frequency
C = pass-band ripple (J = 1, or 2)
D = pass band/stop band ratio (J =2)
CXFRM
user specified
continuous transfer
function
CXFRM (I, J, K, A, B)
Y = CXFRM'I' (X)
J = # of zeros of R(s)
K =# of poles of R(s)
A = array containing complex poles
B = array containing complex zeros
DXFRM
user specified
discrete transfer
function
DXFRM (I, J, K, A, B)
Y =DXFRM'I'(X)
J = length of array A
K = length of array B
:} coefficients describing H(z)
CMPRS
JL-Iaw compressor
CMPRS (I, A, B)
Y =CMPRS'I'(X)
A=JL
B = range of input to block
EXPND
JL-Iaw expander
EXPND (I, A, B)
Y =EXPND'I'(X)
A=JL
B = range of input to block
QUANT
quantizer
QUANT (I, J, A)
Y = QUANT'I'(X)
J =# of bits, i.e., # of distinct quantization levels =2i-l.
A = range of input to block
DELAY
arbitrary length
delay
DELAY (I)
Y =DELAY'I'(J)
J = duration of delay
ZOR
zero-order hold
ZOR (I, A)
Y =ZOH'I'(X)
A = incremental hold, i.e.,
Yi =Xi if I Xi -Xi _l I ~A
Yi=Xi _l if! Xi-Xi_l! -l
13 TURN TYPF.:= 0 r)IRErTIo"l= 0 TIr.1F.= 162.c;OOOO
4 ISI=
TIMF,: II'! SYSlF."'= :34.001)(10 STOP TJME DELAY=
TTIWIF DELAY FnH VEHICLFS UNOFR
2.00000
10.OOOOOMPH=
9.00000
VEHYCl.f LEFT SYS TFM
rOI::.NT=
TJMF IN SYS1E"'= 36.00000 STOP
R.OOOOO
c; lC;h
16 TURN TYPE= 0 nJHErTlo",. 2 TIME=. 179.000(1)
OELAY:
1.00(100 TH"f DELAY FOk \/E'HIClFC; \lNOFQ
10.00000I"lPI"I=
Tl~r:
VEHIrtE LEFT SY5Tf:-.o
HlFNT=
~ lSI:
H
TIME IN SYSTF~= ..i4.00000 STOP TIME OElAY.
VEHlr, t:: tEFT SV!"TF>'
TOF~T=
TJMf TN SYSTE"':
J4.00QOt) STOP
~
T~
VF.HTC,
SV~TF,"
TI)FNT:
SYSTE~=
j4.0no~o STOP
lCOI=
11 Tlhof'" TY..,F= 1 nIRf.rTt'1~1= 0 TIHF.= 210.00000
l.OO(ltlu
TT~f DfLAY Fc)f. \/F"'YCLFC; U~.iOF~
10.00000l"PI"I=
",1.00000
1~
9.00000
VE'HIr.l.f LFFT <;V!o;Tr~
TIlf-",r=
q tcol.
13 TlJ~'Ij TV/Jr= 0 1t~F:r'In""c J TJI-4F= ??1.C:;OOO!l
TI~F Hi SYSTE"'=
..i •• ollono STt}F 1J"~ !lfLAY.
}.on,II)1J TTMfo f1Fl!\'Y Fnk VFHTCLr." Ur\ll')FR li).OOOOO~·PI1=
9.(10000
VF.:HIe.~·
10 JC;I.
l~ Tlllofl\l "''''~a 0 ""~Ft"'lItI~,. 2 n""F: I'~H.C,OOO(l
II"F n~LAY.
'.lIonrJ"
TT"'~ IIfll\'Y ~n~ VFl1tCLFC; l'I\IOj;'~
10.00000"P .... =
9.00000
VFHlr:1 F LFfT S'YSTF"
,oF,...r.
11 1,,1.
]<; Til .....' f'YI'Fs ~ 1)1kft"'lIn,.;. l
TltolF': ('''4./'10001)
TJ~~ rN SYSTf"'s
j~.OOf)f'tl STOP TI"'F nFLaYa
1.IIOM)"
fT"''; IlHII'Y Fnl< \'FIoITCLFC "~mFR
10.00000~·p~i=
~.OOOOl)
Tp.4F
LFFT
SVSH·'~
"IC;h
TIME n~LAY.
9.00000
TI'k"'4 TVPF= 0 "" ... FrTlolIJ: (1 TIfI'IF= l?Il.l;oOOO
?onnno
TT~f nEL~Y FOk VFHICLFC; ,llIJnFR
10.00000~PM=
TI~F
LFFT
1
rI--E O€lt\Y.
lYPF= 3 OJRECTI'l"'· 1 TIME"= lQI,.IO,OOOO
2.00noo
TT"'J: OE.L I\Y F O~ VFHICLFC; UNDFR lO.OOOOOMPI1=
TlIH'"
Tr, !;YSlf.f'I=
Tt.JFNT.
J,.OOOOO STOP
vnnr,
F. LEFT SYSH~'
t,'FNTs
It' I~l.
t" ,,, ..... f'Y~F= 0 nT"'H'l Tn ••• ? TJMF= ?12.c;tlOOIl
r"- SYSTF"'=
JC,.OU,l"f'I ~TO~ It\lF OFlA'fs
~."/\"""
TT"'~ Ilfl IIY Fflk \iF""CI.~·~ I''''OFP
JO.OO/\OOHPM=
q.(lOOOO
VE ... y("" f LFfo1 SY~fF·~
yOFNTa
1-- 14;1.
17 T,''''~' IVt;F: ~ il{Hrr-llq",c 3 n,..F: 7/013.1'0000
TIM/:, ,r., SY5TF~=
j-.Ul»)OU STIW 11"'F Of:L_VlI
1.1I0tl""
TT .... ~. i)lL"V ff'l" VF~IClF~ I/!\jf)FR
]o.noI'lOo"'Prl=
8.00000
\IF.HII':I.F LFfo' SYC;H'·,
!IlF~l.
1" J~t.
'''' fl'~·' I'(Pf~ 1 nTFF-r-ll,"'. , TJIooIF= 7Q~.c;.(loon
Ttt.1F T~,' SYC;'FIlI.
JI:I.OI •. )rn STn~ 'I'·IF 11~lA'Y.
l •• ln''''I'
TT"'~ nFI "Y .. nt'l IW'iTr.LF-" 'II'>II'FQ
lO.O(,OCOj,P,",=
11.00000
TI~~
I,
VENICl", LFFT t;Y~'F'"
TflF"fT.
Ie, tC;l.
L~ TII~"'IV~'J"= 1 nT ... F'·lT'I~j=
TT"'F= 31~.C;OOO!l
TI""F It-, C;YSfE"' • .O.(lIj(l!ln C\TOP 11-...· n.LAV.
I.",lil!)"
TT~" II", flY Fnl< \lF~TClFC; "II.'OFQ
lO.OOOOO~'PI-l=
TABLE II-Results of Computer Run, 100 Vehicles
8.00000
Model for Traffic Simulation
VFtlln F Lr:I-T
'''''.NY.
~VC:lJ.'
~".n{Jrlfln
TIMf T'I.! SYC:'E"'z
~'OJ:
q, I~'.
14 T'"~''' TVPF'= n n''''frTTn'''l: ] rIMF=l"~Q.OOOO{l
'I"'F nFL_V.
1.unlll)n T''''r OHIIV fOk VF"'ICL~C\ "M)FP 1r..IJOnOOP-lp ....
I~t.
VfHtr,1- tFFl CO:VC;H"
flWIII'.
114
TH'~ " .. ~yqF"' . . .H.OoI}I)O ~l()P 1,,,,..
TIJ~'I
429
H.OOOO/)
TVPF: 0 I)JRFrTI(U'= l fIMF=121'i.OOono
TT"f. Ilf::"LAV "nil VF"HTCL~C: UNOFR
lO.OoOOOt-lPH=
13.00000
l~ TIIH"" rVI-'F= 0 nI~FrTIIlt.J1: ? TT~F=l?7Q.c.OOI)()
VF.Hlr, F LEFT 5YS'F-"
fll"Nla
.,~ I~I.
1.(101)1)0
TTMF IlfL IIV Ftlk VF't'lTCl r'C\ ",,!I')F~
1 o.onolloMpH=
TIr"''' T'" SYSTr:"'.
.13.01111(10 S1(l~ 'I"F Of LAVa
9.011001}
VEHlr., to Ln, SV5H",',
11
n~LAV.
q-, Ish
nELU.
TIJf..H'.
., • r, ,1 II n " STOF q ... f
JI,.OOtlOv
..,
Tllw",
0 nh.. fr:TJot.J:
fVPF=
fin
(I
T1"""-=12Ql.C;I)OOO
tf'!
SY~H-'.
fn~
VFHICL~~
VFHTr, f
T IM~
,
LFf , C;VC;" ~
1M T\J~'" TVIJF:= 1 DIRErT 11)"'1:
'I If. .... T.
"11 Iillih
SYSff. .... ..11 .ll (Ill"" ~lnF 1 I aoIf. n~l.Y.
1.00no(l T''''I: UEl/IY F'nf.
VFtiICL~~
VEHIC' f
Tl"F
LFfT
In.()OOOo~P~=
9.00000
TIMF.'l96.C:;OOOO
t'Nf)FR
lo.onooo"'PH=
A.OOOOi)
T"W", TVI-'F. .~ f)Tj:.>FrTlo"J= 3 fl",F=1313.nooon
)O.OOOOO .... P~=
1.000 11 0 TTloif DELAY fn~ VF'HJCLF'C\ UNf)F'~
11.00000
yq I4ih
T, If lilT.
11 T'.'~'" TV~F'. 1 f) I REt" T 1 0"'. 3 TIMF=13?4.floonn
vf.t1tru· lHl ..:v~tr··
~.
C;YSlf."'= .:14.0.)111)., STOS= " " ' f nfL.'u
l.OOI'OO TU4E OfLH FO~ "FH[ClF'~ 'II'-JI)~Q ) o.onO(lOf~PH=
9.000'00
TIM':
~.
,,,
n""F-
.~
~YC H"~
SY51..-",.
s,r~
14ih
1~
11 ,..f nf!lt.V.
T 'M~
AY
(I
IINOFR
,
'3VC;lF .,
,f..., L£f'
SY!oi'F ....
"EHIrl
TlMr
9~
"'f:~l.
"". ClOIl"tl
~.nOI)(lO
1,. •
Gt-.:Arlf' rnTlIl
C;YSTF:'"
"~E
~l'~"'f.... ..,
)(lO 14;1=
14 TIIW"" TVPE: 3 nIHF.,rTTOf.'· 3 Tl""F'=lB6.Cioonn
STOF 1 JOo4F nF.LAY.
'."nooo TTMF nElI'Y FO~ VF:"'ICLF~ I. I NOFR lO.OOnOoMPH:
'PFIII'.
I} I) fllltl
y",VO..,M·.TT('I'
'l~F-.=12'''.\)OflOn
F'O~
9.00000
Tl"'f =1403.0(\000
f\lOF..' . . . . _----, ' . . . _- - - - - ,
,
\
I
I
!!.e!!!.-----+-----..
I
(
I
I
I
I
I(
1
:
I
I
IX
I
1
1
1
r--~-..+,;--......&.:..:...x....,~
:
.--...I-_---:..~-___,
I
~
e,p'
€>- )l~
'----~-----I~
'-- -
--
../
.---+---. I
~',
" I
1\
l
:
I
I(
"j
I:
I
4.
I
36
II
~~_~--~
"',I /:
. v1>I
111>-,.--+'-_---'-""--_--.
1
I:
11\
5.
1
I
I
I
/
I
"'- - -----6.
Figure 3-GRAPH 3
Third level data communication system. Transition from errorrecovery states 37 and 38 to initial system state 1 not shown
smr, cause transitions between Cs and Rs. The system
in Cs finally terminates selection mode by sending a t
word to the remote devices causing a transition from
Cs to Ci. Like in polling we may speak of well defined
languages Ls, Lisr, Lsm, Lsmr, Lrr and Lt.
rejection (acceptance). After is a, a A will bring
us to either state 22 or 23 depending on whether
or not the central device wishes to select more
than one device. The (2) nondeterministic A
transitions from state 21 are thus resolved by
conditions in c which are combined with A.
States Rpm (Csm). Polling (selection) messages
may be blocked or nonblocked. A series of
blocked submessages, pmb (smb ), will cycle
us around the 4 state loop 5-6-8-9-5 ... (23-2426-27-23 ... ). The last blocked submessage or
a nonblocked message is here referred to as
pmt (smt) , t denoting text.
pmb's and pmt's (smb's and smt's) are either (1)
accepted pma (sma), (2) rejected pmr (smr) ,
or either (3) the message transmitting (remote
or central) device cannot interpret the reply (i)
or (4) the message receiving device has not been
able to detect the end of the message block thus
causing a timeout (i).
In case of an i-type reply the message transmitting device may choose either to communicate a request reply rr or enter some error recovery
procedure erp. This latter choice may also result
from repeated message reject replies. After suitable error recovery procedures the system goes
to state 1.
After the last message block has been acknowledged-or if in polling the polled device has no
message to send-a termination sequence t
brings the system to state 1.
Fourth level
We now first expand the message generating/
recognizing super state Csm and Rpm, which like
Cpmr and Rsmr or Csrr and Rprr can be treated by
Third level (See graph 3 on Figu;e 3)
We now proceed to explode substates Ci, Cs, Cp, Rs
and Rp into submachines. In Graph 3 we have clearly
marked these and their relation to Graph 2.
First we cover some omissions from Graph 2 and
subsequently we subdivide further the Second Level
Languages.
GRAPH 4
--~
1. When e.g., s in Graph 2 causes a transition from
Ci to Rs, then we actually mean to show: an s
sequence of transitions in Ci followed by a lineturnaround transition A from Ci to Rs. We shall
later explore this latter type of transition in depth.
2. States Rsir (substate of Rs). isr (is a) denote an
initial selection reply sequence indicating a
479
Csm
Rpm
Figure 4-GRAPH 4
Fourth level message transfer subsystem
480
Fall Joint Computer Conference, 1970
GRAPH
43
45.9
-
-i> 42.1
44.4-45.8
46.7
Figure 5-GRAPH 41
Fourth level message transfer subsystem
showing one graph. One then substitutes these graphs
into the less detailed third level graph. The latter and
remaining superstates are subsequently treated in
depth.
In Graph 4 (Figure 4) the fourth level state 1 (4.1)
equals either 3.23 or 3.5, 3.24=4.7=3.6 and 3.25=
4.9=3.7.
Graph 4 is identical to the regular expression:
(soh a+(etbUstx a+(etbUetx)) Ustx a+(etbUetx) )bcc.
Graph 4 shows that our messages may be of either
of five constructions.
(pmb/smb)
soh a+ etb bcc
or
(pmb/smb)
soh a+ stx a+ etb bcc
-soh a+ stx a+ etx bcc
or
(pmt/smt)
(pmb/smb)
(pmt/smt)
stxa+ etb bcc
-stxa+ etx bcc.
-~44.1
44.3--
or
or
.~
1
~
I,
GRAPH 42
1
42.1
state 4.1 -42.1
4.2-42.2
4.3 -142.3. 42.4. 42.sf
4.4!E42.6
4.S -142.7. 42.S. 42.9f
4.6 i!I 42.15
4.7-42.17
Figure 6-GRAPH 42
Fourth level message transfer subsystem. Detailed version distinguishes between transparent and non-transparent texts
~------------
--~
____________
-J _~
Figure 8-GRAPH 44
Fourth level establishment reply subsystem
43.1
Finite State Automation
481
GRAPH A
42.111-4U
42.18-48.11
Figure ll-GRAPH A
Fourth level line turnaround subsystem idealized
(punch) or keyboard (printer) within a 1050 system
(enq = enquiry) .
LINE TURNAROUND
Figure 9-GRAPH45
Fourth level delivery termination and terminate subsystem
text mode a dIe itb signals a return to nontransparent
text mode (dIe == data link escape).
For the sake of completeness we next show the detailed content of each of the remaining superstates:
Ci, Rsir, Cpmr or Rsmr and Csrr or Rprr.
al ap, as denote the set ~a excluding both ap and
as, as (ap) is the character in an a+ enq sequence
which designates it as a selection (polling) establishment sequence (request). A speQific installation will
use individual a symbols in the string a+ ap a* enq
(a+ as a* enq) to select one (one or all) remote device(s)-and to further select which subdevice is being
addressed-such as either card or paper tape reader
GRAPH 46
45.11---
•
••
denote 2!!l
system state - - - a I
>.
~
We have so far shown the line turnaround function
just by the transition A, see Graph A, Figure 11.
If we address ourselves to a specific system implementation we may then show A far more explicitly, e.g.,
by either of two half-duplex extremes shown in Graphs
Al and A2 (Figure 12).
In the first scheme (Graph AI) the transmitting
device terminates each communication by 2 or more
syn patterns subsequently followed by· a mark condition; after. at least two received syn patterns the receiving device now becomes the transmitting device
and first sends at least 2 syn patterns. While this device
was in receive mode it constantly held its send line in
mark condition.
-
-
-
-
-
-1>45.1
-
_ _---' GRAPH A 1
GRAPH A 2
>.
-------
---i>43.1
•
••
45.10-_
Csrr
~
Figure lO-GRAPH 46
Fourth level invalid reply subsystem
Figure l2-Fourth level line turnaround subsystem
Graph AI: Conventional half duplex
Graph A2: Synchronous transmit/receive
482
Fall Joint Computer Conference, 1970
Bit versus byte oriented definition
GRAPHS 60
character tr."sition:
8.
~
(4thlevell
corresponding USASCII bit transition:
(5th IeveII
GRAPHS 151
character trntion:
~
We may break the level four graphs down even
further; our next more detailed level may take a bit as
the smallest indivisible token (see Graphs 50 and 51,
Figure 13).
We choose however not to go to the fifth level for
several reasons. One is that we tend to think of line
control procedures as character oriented. Another is
that in our implementation we decompose the fifth level
bit-to-character assembly out of the general graph and
implement it as a simple shift register (serializerdeserializer) from which characters are read/decoded
in parallel over all bits.
q
p
V
Y
(4th Ievell
r
Alternating replies
In certain line control schemes text messages are
acknowledged on an alternating basis, i.e., either ackO
for even-numbered blocks and ack1 for odd-numbered
or ackn where n ranges over 0-9. We have not shown
this in our graphs but will now do so using Graphs 42
and 45 (Cpmr) (See Graph 6, Figure 14).
becomes:
GRAPH 6
Figure 13-GRAPHS 50 and 51
Fifth level character subsystem
In the latter scheme (Graph A2) a device in receive
mode always transmits syn patterns and a shift to
transmit mode can thus be effected immediately after
receipt of the last character before syn.
CHARACTERIZATIONS
We now pause to characterize the type of transition
graph that we have so far produced.
•
••
••
..
•••
••
•
G42 n
Scope of definition
The graph(s) on level four define all valid (correct)
sequences which we may encounter on a data communication link under control of a TWO WAY ALTERNATE NONSWITCHED MULTIPOINT system
WITH CENTRALIZED OPERATION. The definition uses a line character as its 'smallest' indivisible
token.
Figure 14-GRAPH 6
Simplified fourth level alternating acknowledgment subsystem
Finite State Automation
Instead of showing repeated instances of the same
graph G42°- n , G45o- n ) one can decompose Graph 6 into
one single instance of Graphs 42 and 45 combined with
a single counter (O-n). Again this is the way we would
implement such a system. But even on Graph 6 or on
the suggested decomposed graph we have not quite
shown the fact that a nak response often requires the
error-free retransmission of the same block, characterby-character as was erroneously communicated. Here
perhaps an English worded definition is superior to a
graph description. One could suggest that the latter
would make use of a queue or buffer into which we put
characters as we generate them. The buffer or queue
content would be reused if a nak response was received.
Otherwise it would be overwritten during the next
transmission.
'" bcc ___I - - - - - -_ _--.
I~
State:
i
1
soh
stx
2 a
6b
2
a
dIe
!l!l
etb
eu
3 d
2
·6 f
3 e
4
15 k
4
6f
3 e
5
15 k
5
6f
3 e
5
15 k
10 g
7
7 j
8
15 L
17m
8
7 j
9
15 L
17 m
9
15 L
17m
13 p
13 p
13 P
13 p
13" q
13 q
9
11
13
7 j
10 nl
13 p
13 p
13 P
12
13 P
13 p
11
13q
13 q
13 q
14
14
13 q
13 q
13 q
13 q
13
15 s
17t
15
The graph definition
implementation
~s
the
It is well known that the transition graphs we have
shown so far can be interpreted in a mechanical way
as either hardware implementable sequential circuits
or soft-ware implementable tables.
First, however, some words on syntax, semantics and
pragmatics. The graphs represent the syntax or the
grammar defining all valid character sequences. In the
implementation one is also interested in:
• What to do with invalid character sequences?
• How to react to any sequence, valid or invalid?
So far our graphs show only generative capability
but we can easily augment the graph or its corresponding tabular representation to show the answers to both
of the above questions.
Take for example Graph 42 shown on Table 1 (Figure
15).
To give informally stated examples of what we mean
and imply by actions/semantics we list a few examples:
a; Start-of-header; set up suitable (hardware)
buffer, initialize (hardware) variables.
6 r
16
16
45.1
17
18
18
45.4
19
Definition, implementation, syntax, semantics
and pragmatics
bee
11 n2
12
F
itb
7 h
10
F
fJ
10 c
3
6
Half duplex
The graph definition truly depicts the half duplex
nature of our line usage. We shall return later with
thoughts on how a transition graph definition might be
used to define full duplex line control procedures.
483
15
17
The letters denote appropriate actions, i.e. semantics.
Unspecified (blank) entries all have next state transition to the error state 19 with
some appropriate action, suitably depending on the present state.
Figure 15-TABLE I
Tabular representation of state transition graph 42. The letters denote appropriate actions, i.e., semantics. Unspecified
(blank) entries all have next state transition to the error state 19
with some appropriate action, suitably depending on the present
state
b. Start-oj-text; no header, set up out device/text
buffer, initialize text variable.
c. Start-oJ-transparent-text; no header, no nontransparent text, set up out device/transparent
text buffer, initialize transparent text variable.
d. First header character, hardware count: = 1.
e. Subsequent header character, hardware count:
= hardware count 1; buffer full? or output in
character to out device.
f. End-oj-header, store hardware count, interpret
header; start-oj-text, set up text buffer and
initialize text variable.
g. End-oj-header, ... , start-oJ-transparent-text, so
far no nontransparent text, set up out device/
text buffer and initialize variable, disable
parity check.
h. First text character; text character: = 1; output
in character to out device/buffer.
j. Subsequent text character; text character: = text
character
1; ....
.+
+
484
Fall Joint Computer Conference, 1970
k. End-of-transmission-block, no text, interpret
header, wait for block check .character, disable
parity check.
q. Transparent text data, use as such.
r. End-of-transparent-text-data, start-of- (nontransparent) -text reinitialize variables.
We have and shall not define the pragmatics of line
control procedures rigorously (formally).
Some of the pragmatics here are concerned with the
length of prefixes, headers, and text data and with the
principles of retransmission and error recovery
procedures.
Through this augmentation we have converted our
graph from a generator into a transducer: a machine accepting and transducing (controlling the translation
of) the generated sequences. This machine can be implemented either strictly in wired logic, as a micro program in a general purpose transmission control unit
or as a software table switching/look-up mechanism.
We shall comment further on this.
Completeness
We wish to demonstrate the COMPLETENESS of
our definition. That is, we can prove that we have considered all possible character sequences and rigorously
defined syntactically and semantically which are correct
and what to do with valid as well as invalid sequences.
Our definition and our implementation is therefore
unambiguous, each taken separately or both taken
together. The argument goes somewhat like this: (1)
There is a finite number of states (nodes) in our graph.
(2) In each state only a finite number of valid input
(transducer/recognizer) or output (generator) characters is possible. Thus we only have to make a finite
number of decisions in building our graph. The graph
is the proof.
The design style and structure that the graph approach imposes on us is appealing.
Specification changes
munication transactions we can mention the possibility
of letting both phases be software or hardware controlled through the same graph in both the master (c)
and remote (r) systems. That is, the total collection of
state transition Graphs 42-46 coimected as shown by
Graph 3 is present in either type of device. Subgraphs
Ci, Csm, Csrr, Cst and Cpmr will be used by system c
as generators whereas any device in system r will use
them as transducers and vice versa-subgraphs Rsir,
Rsmr, Rpt, Rpm and Rprr will be used by system c as
transducers whereas anyone device in system r will
use them as generators.
To use a graph as a generator may not seem to have
a practical meaning in any particular instance of a
transaction. The generator generates all correct transactions, not a particular one. But somehow, someone
(be it a human being at a terminal or the automatic
program in a CPU at the central system) generates a
particular instance based on a few parameters (v) such
as (1) poll or select, (2) device address, (3) header/no
header, text/no text just header, (4) possible embedded
transparent text segments, (5) blocked/nonblocked
messages, (6) length of prefixes, headers and text
segments and (7) pointers to prefix (p), header (h),
and text (t) segment buffers. What we mean by the
generator generating a particular instance should now
be more clear.
Let us visualize a system (Figure 16) where c selects
r and sends messages to r.
Gc is the generator {Ci, Csm, Csrr, Cst}, Tc is the
transducer {Rsir, Rsmr}; Tr is the transducer {Ci,
Csm, Csrr, Cst} and Gr is the generator {Rsir, Rsmr}.
Gc uses parameters v and subsequently also link
parameters from Tr while stepping through the appropriate transition graphs (sequential machines,
micro programs or software tables).
Gr uses link parameters from Tr in its stepping
through appropriate graphs.
By link parameters we mean the information shown
in Graphs 42-46 relating the outcome (final state) of
some graph (say 42.16) to one or more initial states in
connected graphs (here 45.1).
Changes in the definition of line control procedures
can be readily effected. The graph approach immediately reflects all nodes which may be affected by a
change. This is true for generators as well as for recognizers/transducers.
Generator and recognizer duality
N ow that we have seen that the graphs represent
both the generation and the transduction of data com-
Figure 16-Two way alternate non-switched multipoint system
with centralized operation of subsystems r from subsystem c
Finite State Automation
GRAPH 70
GeneratOr IG)
Input:
G--. }; ~{d,s,p,e J
State:
d
s
p
e
i:
1
2+
2...
3-
5-
2
2+
7+
3-
5-
3
4+
7+
7+
7+
4
4+
7+
7+
5-
5
6+
6-
7+
7+
6
6+
7+~
7+
7+
7
7+
7+
7+
7+
Figure 17-GRAPH 70
ALGOL 60 number generate graph. Fourth level
'f.he stepping process thus uses the parameters in
order to resolve next generator output in cases where
more than one next output character is correct. For
example, in Graph 4, state 1, if the v parameter indicates 'header,' then soh is output and the generator
graph action directs the control to fetch pointer to and
length of header buffer from v and to start outputting
header information. The header characters are matched
against the a's, i.e., a state transition from 4.2 to 4.3
and then recursively to 4.3 occurs unless the header
buffer contains invalid information, i.e., characters
different from, say, a. When the header buffer is exhausted the control again looks at v to see whether
any text transmission is required, etcetera.
Note here that we use the generator graphs in two
ways. In between prefix, header and text segments as a
generator, otherwise as a check (recognizer) on the
correctness of these segments. If, e.g., a header segment
contained 'stx' then a transition to state 4.4 would
occur. Depending on implementation we could either
GRAPH 71
485
E:
I--.
next
state
present state
output
S={1,2,3,4,5,6,7}
Figure 19-TABLE II
Fourth level tabular representation of Graph 71, Figure 18
use this transition to signal error, or the graph, when
the header buffer subsequently became exhausted,
would signal error because of the repeated attempt to
output stx (from state 4.5).
Rec09l'lizer I R)
1: = { d,s,p,e } denote input,
e-
THREE BASIC IMPLEMENTATION SCHEMES
A = {+,-,+ } denote output,
+
denotes error output.
As pointed out in above, the generator definition
equals the transducer implementation. In this section
we show three such. The first is based on Graphs 70,
(Figure 17) and 71 (Figure 18).
The equivalent tabular representation is shown in
Table 2, Figure 19 (Table 2 defines ALGOL-60
{numbers )'s).
The three schemes are:
1. Hardware sequential machine or automaton
Figure 18-GRAPH 71
ALGOL 60 number recognize graph. Fourth level
using logic gates and flip-flops.
2. Micro program in read-only/writable control
store.
3. Software program in main core.
Fall Joint Computer Conference, 1970
486
Input:
X
Input el:
1
Combinational
~t.1 DL09iCC. t:' Out,,""A.
~1
.
00.
01
000
0
0
001
0
011
11
10
0
1
1
0
1
1
1
010
0
1
1
1
110
0
1
1
1
111
1
1
1
1
101
0
0
1
1
100
0
1
1
1
State:
~
C
.
...-.--.
.
Yn
Yn
present state eS
next state eS
State Register R
Figure 20-First Niveau sequential machine model
Scheme 1: A Finite State Machine (FSM)
The model of a hardware implemented fsm is given
in Figure 20.
C maps ~XS into AXS. The mapping is given in
Table 2. The number of flip-flops needed in R is n ~ Log2
(the number of states in S) , n suitably being the smallest integer larger than or equal to Log2 ( I S I ) • We
choose n = 3; and let + == -, i.e., we do not distinguish between these two symbols. In Table 3, Figure
Figure 22-TABLE IV
Binary tabular representation of variable Ya in Table III,
Figure 21
34
Input:
d=OO
5=01
p=l1
000
State:
001
0101
1:)100
0110
1010
011
1001
1110
1110
1110
3
010
0101
1110
0110
1010
2
no
1101
1110
1110
1110
6
111
1110
1110
1110
1110
7
101
1101
1100
1110
1110
5
1001
1110
1110
1010
4
Figure 21-TABLE III
Fifth level binary tabular representation of Table II, Figure 19
21, we have coded 8E S as the binary number shown in
Table 2.
(This happens to be a 'not so good' internal state
coding.) Output '+' is coded as logical '1,' '-' and
'+' both as '0.' Input d='OO,' 8='01,' p='ll' and
e='10.'
Note that in Table 3, row 000, state 0 is undefined.
We can fill entries in row 000 with whatever Y1 Y2
Figure 23-Third Niveau logic primitive implementation of
variable Ya in Table IV, Figure 22
Finite State Automation
Xl
I---I-----~
Z
487
output ('controls to DF') (e.g. {+, -, + }), s' goes
back to Sreg and the WC S is ready to serve another line.
If the WCS is to manipulate the input (i.e., possibly
store u in a TCU line buffer (lbf) , changing code structure, incrementing lbf address, decrementing character
count) then (s, u) initiates a several microword subroutine via the (su) loop. Branches in this routine are
determined by conditions in the DF. The last micro
instruction contains s' and directs s' to Sreg whereafter
the WCS is again ready to serve any line.
All this is very trivial. What we should note however
is that the basic flow of the microprogram, i.e., the
proper sequencing of subroutines, is completely derived
from (e.g.) Graphs 42-46. In other words if we change
the definition of line control procedures then we can
mechanically relate such changes to the microprogramming of the TC U.
Scheme 3,' Software controlled recognition and
transduction
clock
Figure 24-Second Niveau logic block implementation of
sequential machine model of Figure 20
Y3 Z values we might find useful. From Table 3 we
then compute Yi (i= 1,2, 3) and Z as a Boolean function: f(x1, x2, y1, y2, y3). Take for example Y3 or
Y3 shown in Table 4, Figure 22.
The logic for Y3 (C Y3 ) is indicated in Figure 23,
and a typical implementation from Figure 20 is shown
in Figure 24.
Let Table 2 or 3 be stored as a three dimensional
array T (1: I S I , 1: j ~ I , 1: 2) where I X I denotes the
number of elements in the set X. The next state part
of the table is stored in T(*, *, 1) whereas the output
or action label part is stored in T(*, *,2). Let INDEX
(CHARACTERSET, SYMBOL) map classes of 8 bit
MICRO·PROGRAM
~T~'~~,~D
t()}
Ii
I
Scheme 2,' A microprogrammed transmission control
unit (p,TCU)
I~
,~"
LJ=
-~-~
controls to OF
conditions to OF
DATA FLOW (OF)
The p,TCU is to serve many independent lines
sharing the same microprogram for their identical line
control procedures.
In Figure 25 we show only the principles of the line
input data flow: An input character is de-Serialized
in SdS, transferred in parallel to BF and when serviceable by the writable control store (WCS), the input
(u E ~) and the present state (s E S) which is kept in
Sreg are transferred to the WCS address decoder.
If the WCS is to act only as a recognizer then just
Table 2 (or some other appropriate table, e.g., Table 1)
is stored in WCS. The WCS word addressed by (s, u)
has value (s', 0) where s' is the next state and 0 is the
1===
I ---
I/O +- 1 - - interface
bus in
~
r
1
I
I I
I I
~IH~
I
I
If
+
I
I
I
I
I
I
•••
Sreg
rBl
I
ne.t state:s'
LINE ADAPTER
~
Figure25-Micro-programmed data eommunication control unit.
Only the input (read) data flow is shown
488
Fall Joint Computer Conference, 1970
Program 1:
PROGRAM:
PROCEDURE OPTIONS (MAIN);
DECLARE
~~~~~T~~~C~~:R1~fER
(60),
'''INITIALIZE PROPERLY'"
INPUT_CLASS (0:60) FIXED BINARY (7), '''INITIALIZE PROPERLY'"
T (l:S, 1:1:, 1:2) FIXED BINARY (15), '''INITIALIZE PROPERLY'"
(INPUT. PRESENTSTATE) FIXED BINARY (15);
r
PRESENTSTATE ,. 1;
GET EDIT (SYMBOL) (A(l»;
INPUT = INPUT-CLASS (INDEX (CHARACTERSET .SYMBOL»;
CALL ACTION (T (PRESENTSTATE. INPUT. 2»;
PRESENTSTATE = T (PRESENTSTATE. INPUT. 1);
L -_ _ _ _ GO TO READ;
ACTION:
EAD
:
PROCEDURE (L);
DECLARE SWITCH (N) LABEL INITIAL
(ACTl. ACT2 ••••• ACTN) ;
GO TO SWITCH (L);
··
·
.
··
·
··00
·· ·
·
ACTl :
RETURN;
ACT2:
RETURN;
actions associated with
val id input sequences
ACTM~
RETURN;
schemes hitherto proposed could more appropriately
either be called (termed) doubly interleaved half duplex
or even just ordinary double simplex. This situation is
truly reflected in the scheme next discussed.
First we assume that the transmission is point-topoint or that if we have a multipoint (N) 2 station-)
system. Then we assume that 2 out of N stations have
been selected for point-to-point communication, and
that the remaining N - 2 stations 'listen' to both of the
two-way simultaneous communication. We shall not
here elaborate on the selection problem.
N ext we postulate that a definite full duplex data
communication line control procedure exists. We finally
assume that the text message, text-reply and replyrequest scheme shown in Graphs 3, 42-46 is the one
used but that we interleave these in a threaded manner
when going full duplex .
The constraints put on (or rules defined by) the
postulated procedures are therefore:
ACTM1:
GO TO EXIT;
ACTM2:
TO EXIT;
actions associated with
invalid input sequences
ACTN:
GO TO EXIT;
END ACTION; EXIT:
END PROGRAM;
Figure 26-Pseudo PL/l program
symbols into the set {I, 2, ... , I ~ I }. The pseudo
PL/1 program on Figure 26 shows the generalized software program control statements into and around
which any finite state algorithm can be arranged. 6
Conclusion
It may be argued that we have shown nothing spectacularly new. in the three schemes-the main reason
we include this section is to demonstrate the clear-cut
relation between definition and implementation-a relation which can be carried out mechanically, i.e., automatically. One is therefore greatly aided when having to
decide whether a given scheme is to be implemented
using method 1, 2 or 3.
FULL DUPLEX
Before describing how we would go about defining
(and implementing) a full duplex scheme, the following
brief remark or observation may be appropriate: It
appears (at least to this author) that all full duplex
Rule 1: When one station (A) sends a 'packet' of type:
'text-block,"reply' or 'reply-request,' then the
other station (B) either sends "nothing"
("null"), synchronization (syn) symbols or
sends a "packet" of the same type. A termination sequence, eot, has type: text-block.
'Text-block' and 'reply-request' are packets of
the same type. This corresponds to the logic of
Graph 2, Figure 2.
Rule 2: The exact mutual character-by-character sequence need not necessarily match. That is,
any time combination of A orB beginning or
ending their "packet" transmission is allowed.
Rules 1 and 2 guarantee that the two way line will never
carry packets of different types at anyone time.
The example shown in Figure 27 is a particular
instance of a set of line transactions. Note specifically
the situation after text-blocks m2 where B first sends
ack1 reply to m2(A~B), then reply-request !! in
response to an erroneously received ack1 = i from A;
not before B has received a correct reply (either ackn
or nak) can B proceed to text-block ma. Concurrently:
A has received an affirmative answer to m2(A~B), so
A proceeds to ma (A ~B) before it has cleared the
m2(B~A) reply.
In order, therefore, to synchronize these two processes
properly we employ the following two indivisible operations7 which we define using a pseudo PL/l notation:
S: SET:
PROCEDURE (semaphore);
semaphore: = 1;
END SET;
Finite State Automation
489
EXAMPLE, Full Duplex File Transmission
A-B
•••
B-A
A-B
B-A
transmission
from X toY
initialization
of XfromY
X sends a
sequence, but
Y receives
/3 sequence
initialization
of Y from X
received, this release is accomplished through
S ('YB), or releases TGb through S (aB) .
4. If RRGb was initialized then a transition to
state B6 will enable RRb to state B9. A completion of the request-reply recognition again
releases {3A thus enabling RGa and the two corresponding components RRb and RGa are thus
brought to synchronize. We point this out here,
but could as well do it for the cases where TGb
in state B2 enables RRb to state B9 simultaneously with TRa in state A2 ("'B2) releasing {3A
thus enabling RGa in state A9 ("'B9).
5. In more general terms: The possibility that a
generator G of type x E {T, R, RR} in station
u E {A, B} enables a recognizer R of type
y E {R, RR or T, R} (taken in corresponding
order) before the type x recognizer (xRu) has
reached home condition (i.e., final- or end-state)
should not bother us. yRu will not receive input
before xGv has reached its home condition, v¢u.
We thus see that the system· of three semaphores
{a, {3, 'Y} in each of two communicating stations com-
GRAPH 10
Figure 27-Example. Full duplex file transmission
H: HOLD: PROCEDURE (semaphore)
RECURSIVE;
IF semaphore = 1 THEN semaphore: = 0;
ELSE HOLD (semaphore);
END HOLD;
2!A~B~i-BiI
On Graph 8, Figure 28, we have shown the totality
of generator (- G) and recognizer (- R) graphs in
both stations and we have explicitly shown details
concerning half of the otherwise symmetric channel
traffic, in this case: text blocks mB~A.
1. While text block generator TGb in B transmits
mB~A the text block recognizer TRa in A is receiving that same message.
2. When TRa has received all ef mB~A then it releases the reply generator RGa. The release is
accomplished through S({3A) and may precede,
coincide with or succeed the time at which TGa
ends transmission, i.e., goes to state A8.
3. When the reply recognizer RRb has received the
reply then it: either releases the request-reply
generator RRGb because an erroneous reply was
______
. ____
. ___ _
STATION A Istatej-Aj)
Figure 28-GRAPH 8
Third level full duplex file transmission. Generator and
recognizer system
490
Fall Joint Computer Conference, 1970
pletely interlocks proper sequences. The semaphore
values are initially {I, 0, O}, with respective TR's
enabled.
6. One further note: observe that if xGu at time
't' goes to state j (uj) then xRv will at time
't+~' go to either the error state or vj. This is
true for all state transitions. We might say that
the recognizer is always one time step (~) behind its associated generator, ~ being the time
it takes to serialize, transmit and deserialize a
character.
In this specific example we do not require the indivisibility of the Hand S semaphore operators. Thus
we have not demonstrated the particular virtues of H
and S. For the synchronization of more than two lines,
however, one is greatly aided by such primitive
operators.
Our example demonstrated the notion of (two) cooperating sequential processes. As such it conceptually
belongs to the field of parallel computations. This is
presently being studied intensely. In fact, it is proper
here to refer to the pioneering work by Petri8 and Holt. 9
Their work essentially embodies the research suggested
by Lynch. 10
In fact, Graph 8 is a somewhat transformed version
of a Petri net as defined by Holt. Our graph not only
shows the algorithmic parallelity but in addition indicates an implementation.
Input:
State:
char
~
eoa
sot
eob
2 (1)
3
3
3
3
2
3
4 (2)
3
3
3
f: e: 3
3
3
3
3
3
4
5 (4)
3
7 (9)
6 (3)
3+
5
3
3
7 (8)
3
3
6
5 (4)
6 (5,7)
6 (5,6)
6 {3}
3+
7
5 (4)
3
8 (10)
6 (3)
3+
8
5 (4)
3
9 (11)
6 (3)
3+
9
5 (4)
3
3
6 (3)
3+
i: 1
Figure 29-TABLE V
Finite state transducer
The regular expression R (G) is:
~ sel (eUcharUchar charUchar char char)
(sot ( charUsel) *Ueoa (charUchar char
Uchar char char) )*eob
and the mechanically constructed finite state machine
top-down transducing L (G) = I R (G) I is shown in
Table 5, Figure 29.
PRODUCTION SYSTEM DEFINITION
As a final (although non-graphical) way of completely and compactly defining a set of line transactions
we now show how the language acceptable by an IBM
1070 process communication systeml l IBM 1071 terminal control unit in text mode can be specified through
a top-down LL (1) 12 grammar G:
(1)
(2)
w
B
~
eoaB
~selM
Teob
T~TT
(3)
(5)
(6)
(8)
(9)
(10)
(11)
T~
sot S
T~
(4)
S~CX
C
~
char
T~eoaA
S~
(7)
C
~sel
A~charD
M~charD
M~
D~charH
D~
H~
H~
2; =
char
{eoa, sel, char, sot, eob}
where char denotes a larger alphabet.
CONCLUSION
It is our hope that we will achieve the objective: that
of data communication line control procedures being
defined through some compact, complete and unambiguous methodology which lends itself to levels of
abstraction and to well structured implementations.
This results in better designed communication subsystems, be it software, hardware, firmware or all. The
implications are:
1. Better control of engineering changes if any are
needed.
2. A much more generalized service engineering
training.
3. Systems which are easier to diagnose-visualize
that we use all error state transition actions in
our diagnostics, and we know a priori that we
have dealt with all possibilities.
4. Much better chances of implementing new exotic
line control schemes fast and efficient.
Finite State Automation
5. Reliable techniques for evaluating and comparing
different implementations software, firmware
or hardware, and through the hierarchical structuring, any mix of these.
We have chosen the model of finite state graphs,
rather than that of a context-free grammar. We did so
because the communications control processes are of a
finite state nature. The context-free grammar model is
too powerful for our purposes and the finite state
graph model is claimed easier to grasp. One is in particular aided by the visuality rather than the formality.
The theory of (finite state) automata and formal
languages has come a long way. There are scores of
important results waiting to be used practically.
5
6
7
8
ACKNOWLEDGMENT
The author is indebted to Akira Saito of IBM Japan
for pointing out a subtle error in a first draft.
9
REFERENCES
1 IBM CORP
General information, binary synchronous communication
IBM Systems Reference Library (SRL) Form No A27-3004
2 J EISENBIES
Conventions for data communication
IBM Systems Journal Volume 6 Number 4 pp 267-302 1967
3 ANSI
USA proposed standard data communication control
procedures for USASCII
Communications of the A CM Volume 12 Number 3 pp
166-178 March 1969
4 B RANDELL F W ZURCHER
Iterative multilevel modeling, a methodology for computer
systems design
IFIP Congress 68 Edinburgh August 5-10 1968
and
B RANDELL
Towards a methodology of computer system design
10
11
12
491
NATO science committee report: Software engineering
pp 204-208 Garmisch Germany October 7-111968
E W DIJKSTRA
The structure of T.H.E. multiprogramming system
Communications of the ACM Volume 11 Number 5 pp
341-346 May 1968
and
E W DIJKSTRA
Complexity controlled by hierarchical ordering of function and
and variability
NATO science committee report: Software engineering
pp 181-185 Garmisch Germany October 7-111968
D BJ0RNER
Flowchart machines
IBM research report RJ685 San Jose California April 1970
E W DIJKSTRA
Cooperating sequential processes
Programming Languages Ed F Genuys Academic Press
Chapter 2 pp 43-112 New York 1968
C A PETRI
Kommunikation mit automaten
Schriften des Rheinisch-Westfalischen Institut fUr
Instrumentelle Mathematik Universitat Bonn Nummer 2
1962
A W HOLT
Information System theory project
Report Applied Data Research Inc Princeton New Jersey
September 1968
and
A W HOLT F COMMONER
Events and conditions, An approach to the description and
analysis of dynamic systems
Report Applied Data Research Inc Princeton New Jersey
1970
W C LYNCH
Commentary on the foregoing note
Communications of the ACM Volume 12 Number 5 pp 261
and 265 May 1969
IBM CORP
IBM 1070 process communication system
IBM System Reference Library (SRL) Form Number
A26-5780pp 14-181968
D BJ0RNER
The theory of finite state syntax directed transductions
PhD Thesis Laboratory for Pulse- & Digital Techniques
Technical University of Denmark Copenhagen January
1969
A strategy for detecting faults in sequential machines
not possessing distinguishing sequences*
by D. E. F AR1VIER
Clarkson College of Technology
Potsdam, N ew York
table of the fault-free machine, it provides no further
information concerning its state table.
The machine-identification problem was first treated
by Moore. 1 He proposes setting an upper bound, n, on
the number of states which the unknown machine may
possess. He then forms a composite state table fror.n
all distinct state tables of n or fewer states. For thIS
composite state table Moore finds a homing sequence,
an input sequence for which the output uniquely identifies the final state. Application of the homing sequence
to an unknown machine permits the determination of
the final state of the composite machine (containing
the unknown machine) and consequently of the machine containing that state. The difficulty with this
approach is that the number of distinct n-state tables
grows very rapidly for increasing n and consequently
the test procedures become impractically long.
Further work on distinguishing sequences and homing
sequences is contained in Gi1l2 and Hibbard. 3 It is
shown that every reduced· n-state machine possesses a
homing sequence and that the shortest such sequence
contains at most (Y2) (n) (n-I) symbols. It is also
shown that a machine need not possess a distinguishing
sequence.
The design of test procedures based on knowledge
of the state table of the fault-free machine was first
treated by Hennie. 4 Hennie's tests are true fault-detection tests rather than machine-identification tests.
Hennie treats both the case in which a machine possesses a distinguishing sequence and the case in which
it does not. He demonstrates the feasibility of test
procedures for both cases and presents the philosophic
basis for the tests. He does not claim to present the
optimum strategy for test design.
.
Kime 5 presents an alternate strategy for the dIStinguishing-sequence case, which retains Hennie's
philosophy, but is somewhat more systematic and
results in a lower upper bound on the length of tests.
INTRODUCTION
The problem treated here is that of detecting faults in
digital equipment by applying input sequences at the
input terminals and observing output sequences at the
output terminals. The checking of digital equipment
by input/output tests applied at the terminals is
motivated by current and future usage of large-scale
integration techniques which make internal test points
generally inacces~ible for testing purposes. The mod~l
ing of digital equipment by finite-state sequentIal
machines and then designing fault-detection tests
based on the state table is a general approach. The
difficulty is that it results in very long experiments for
large state tables, particularly for the case in which
the state table does not possess a distinguishing sequence, that is, an input sequence for which the response
uniquely identifies the initial state. This paper presents
a strategy for designing more efficient fault-detection
tests for machines not possessing distinguishing
sequences.
The fault-detection problem may be viewed as a
special case of the machine identification problem. The
general machine-identification problem consists of
determining a state table for an unknown finite-state
machine by applying inputs and observing outputs.
The fault-detection problem consists of determining
whether the possibly faulty machine is describable by
the state table of the known fault-free machine. The
fault-detection test either verifies that this is the case
or that it is not the case. If the test shows that the
possibly faulty machine is not describable by the state
* This paper is based on a dissertation submitted by the author
in partial fulfillment of the requirements for the degree of Doctor
of Philosophy in Electrical Engineering at the Polytechnic Institute of Brooklyn. This work was supported in part by the National
Science Foundation Grant No. GK-l0218.
493
494
Fall Joint Computer Conference, 1970
Kohavi and Lavallee 6 treat the problem of designing
machines so that they possess distinguishing sequences
and also present a special test organization for machines
which possess distinguishing sequences composed of
repetitions of a single input symbol. Kohavi and
Kohavi7 present a test organization for the special case
in which the machine possesses a variable-length distinguishing sequence. In this case some of the states
may be identified by a prefix of a longer distinguishing
sequence (required for other states).
The strategy presented in this paper includes the
Kime organization and the Kohavi and Kohavi variable-length distinguishing sequence organization as
special cases of a more general approach. Primary attention is focused on machines which do not possess
distinguishing sequences, but the distinguishing-sequence case is also included.
For machines not possessing distinguishing sequences,
an initial state must be identified by observing the set
of responses to a set of input sequences, each element
of the set being applied to the machine in the same
initial state. Such a set of input sequences is called a
characterizing set. It is possible to use different characterizing sets for the various states, some of lower
order than others. The application of this strategy
results in shorter test procedures. This is one of the
principal features of this work.
Another feature is a general treatment of locating
sequences. A locating sequence, as used here, is an input sequence for which the observation of a specified
response permits the determination of the state of the
machine at some specified point in the sequence. Hennie
treats a special kind of locating sequence, one which
not only locates a state, but also checks the response
to a characterizing set for the located state. In this
paper Hennie's locating sequence is called a characterization-verification sequence. The selective use of these
sequences is an important feature of the testing strategy
presented here.
DEFINITIONS AND NOTATION
The sequential machines considered in this paper are
finite-state, synchronous, deterministic, strongly connected, and completely specified. The machines are of
the Mealy model where X = {Xl, X2, ... , Xm} is a finite
set of input symbols, S = {Sl, S2, ... , Sn} isa finite
set of internal states, and Z = {Zl' Z2, ••• , zp} is a
finite set of output symbols. There is an output function, w(S", Xj), which specifies an output symbol for
every SiE S,xjE X. There is a next-state function,
O(Si, Xj), which specifies a next state for every SiE S,
xjEX,
Throughout this paper we shall be concerned with
two machines: the fault-free machine, M, and the
possibly faulty machine, M', A fault-detection test
must establish that machine M' is or is not indistinguishable from machine M, subject to certain assumed
restrictions on M'. It is necessary to fix an upper bound
for the number of states which M' may possess in
order that the fault-detection test be finite. In this
paper the upper bound is taken as n, the number of
states of the fault-free machine. This is usually justifiable by knowledge of the internal structure of the
machine being tested. It is also assumed that faults
are logical, that is, M' is describable by a finite-state
deterministic state table.
In order to distinguish between the states of the
machines M and M', we denote the ith state of M' by
S/. It is our goal to establish that the behavior of M'
for initial state S/ is indistinguishable from the behavior of M for initial state Si. For· convenience we
choose the same subscript for corresponding indistinguishable states of M and M'.
In order to make these concepts precise, we make the
following definitions.
Definition 1
A fault-detection test for machine M' is the application
at the input terminals of M' of a sequence of input
symbols such that the observation of the sequence of
output symbols (response) produced at the output
terminals is sufficient to determine whether or not M'
is indistinguishable from M, subject to the assumptions
that M' contains no more states than does M and that
M' is representable by a finite-state deterministic state
table.
Definition 2
A locating sequence for state Si of machine M is an
input sequence for which the observation of a specified
response is sufficient to determine that M is in Si at
some known point in the application of the locating
sequence.
The state Si is located by the locating sequence. In
accordance with whether Si is located prior to, during,
or after the application, the sequence is an initialstate, intermediate-state, or present-state locating sequence. An initial-state locating sequence and an intermediate-state locating sequence are also present-state
locating sequences, since knowledge of the input sequence and the state table for M provides knowledge
of a future state of M after some state is first located.
Strategy for Detecting Faults in Sequential Machines
Throughout this paper the terms present-state or
intermediate-state locating sequence are usually applied
to sequences which are not also initial-state locating
sequences. A reduced n-state sequential machine does
not necessarily possess an initial-state locating sequence
for any of its states.
Definition 3
A distinguishing sequence for machine M is an input
sequence which is an initial-state locating sequence for
all of the states of M.
A distinguishing sequence can also be defined as an
input sequence for which the response of the machine
is different for each initial state. This is equivalent to
the preceding definition.
Definition 4-
A homing sequence for machine M is an input sequence
which is a present-state locating sequence for all states
into which M can be transferred by the homing sequence. Any initial state is permitted.
For an input sequence to be a homing sequence, it
must be possible to apply it to the machine in any
initial state and have it locate the present state. The
response is a function of the initial state, but serves to
locate the present state. We are assured that a presentstate locating sequence for some state exists for every
reduced n-state machine because a homing sequence
exists.
Definition 5
A characterizing set for state Si of machine M is a set
of input sequences for which the corresponding set of
responses is unique to initi~l state Si, M being in Si
prior to the application of each element of the characterizing set.
The characterizing set for Si characterizes Si.
Definition 6
A characterizing set for machine M is a set of input
sequences which is a characterizing set for every state
of M.
The characterizing set for M characterizes M. It is
clear that a characterizing set for M can be obtained
from the union of characterizing sets for all the states
of M. A characterizing set for a state may thus be
viewed as a subset of a characterizing set for a machine.
495
An initial-state locating sequence for state Si is a
characterizing set for Si of order one. Likewise, a distinguishing sequence for M is a characterizing set for
M of order one.
Definitions 2 through 6 apply to machine M, the
fault-free machine. These concepts can also be applied
to machine M', the possibly faulty machine, provided
that we can devise a test procedure for verifying that
M' possesses n distinct states which are characterized
by the characterizing sets for the n states of M. The
following definition provides us with a required tool
for this purpose.
Definition 7
A characterization-verification sequence for state S/
of machine M' is an input sequence applied to M' for
which the observation of a specified response verifies
that M' contains a state S/ which is characterized by
the characterizing set for state Si of machine M.
I t is incidental to the preceding definition that the
way of forming characterization-verification sequences,
presented in a subsequent section of this paper, results
in their. being intermediate-state locating sequences
for S/.
Tables I, II, and III are the state tables for machines
TABLE I-State Table for Machine Ml
Present state
A
B
C
D
Next state, Output
input = 0
input = 1
A, 1
C, 0
A, 0
C, 0
B,O
D,O
A, 1
D,O
TABLE II-State Table for Machine M2
Present state
A
B
C
Next state, Output
input = 0
input = 1
B, 0
A, 1
A, 0
C,O
C,l
B, 0
TABLE III-State Table for Machine Ma
Present state
A
B
C
D
Next state, Output
input = 0
input -1
A, 0
B, 0
A, 0
C, 0
A,O
D,O
A,l
D,O
496
Fall Joint Computer Conference, 1970
M I , M 2 , and Ma. These machines provide examples of
the types of input sequences just defined. The examples
are given in Tables IV through IX.
TABLE VIII-Example of a Characterizing Set for a State
TABLE IV-Example of an Initial-State Locating Sequence
Note: The set to, 1O} is a characterizing set for state C, since the
response set to, Ol} is unique to initial state C.
Initial state
A
B
C
D
Response of M 1 to input sequence 00
11
01
00
11
Initial state
A
B
C
D
Response of M3 to input set
{O,OO}
{O,OO}
{0,01}
{1,01}
to,
1O} ,
TABLE IX-Example of a Characterizing Set for a Machine
Note: 00 is an initial-state locating sequence for states Band C
as demonstrated by the unique responses for Band C.
Initial state
A
B
C
D
TABLE V-Example of a Distinguishing Sequence
Initial state
A
B
C
Response of M2 to input sequence 01
11
01
00
Note: 01 is a distinguishing sequence for M2 as demonstrated
by the unique responses for each state.
TABLE VI-Example of a Present-State Locating Sequence
Initial state
A
B
Response of M 1 to
input sequence 0
1
C
o
o
D
1
State after application
of input sequence 0
A
A
B
A
Note: 0 is a present-state locating sequence for state A, since a
response of 1 verifies that the present state of M 1 is A.
TABLE VII-Example of a Homing Sequence
Initial state
A
B
C
D
Response of M 1 to State after application
input sequence 10 of input sequence 10
00
B
00
B
01
A
01
A
Note: 10 is a homing sequence for M l , since a response of 00
verifies present state B, while a response of 01 verifies
present state A. Also, 10 serves this function for all initial
states.
Response of M3 to input set
to, 00, OOO}
to, 00, 001}
to, 01, 001}
{I, 01, 001}
to, 10, nO}
Note: The set to, 10, 110} is a characterizing set for machine
M3 as demonstrated by the unique response sets for each
state.
SUBDIVISION OF FAULT-DETECTION TESTS
At the outset of the test procedure we must place
machine M' into some reference condition in order
that we may then apply the fault-detection test proper,
which is designed for this specific reference condition.
This consists of placing M' in some state, So', by
applying a homing sequence for machine M, followed
by a sequence designed to transfer M to So from its
state at the conclusion of the homing sequence. This
procedure is adaptive in nature since the transfer
sequence used depends on the observed response to
the homing sequence. Although this procedure treats
M' as if it were M, if M' is not in fact transferred to
So', this will be discovered in the fault-detection test
proper and it is then established that M' is faulty.
The fault-detection test is preset and is designed for
application to machine M' in state So'. The test may
be subdivided (at least conceptually) into two parts.
Part (1) establishes that M' possesses n distinct states,
SI', S2', ... , Sn', which are characterized by the characterizing sets for the n states of machine M. It also
establishes that a locating sequence ( either initialstate or present-state) exists for some state of M'.
Part (2) establishes that the next-state and output
functions for M' correspond to the next-state and output functions for M . We call part (1) the characterizing portion and part (2) the transition and output
checking portion. In applying the tests the two parts
may occur in any order and may in fact overlap one
Strategy for Detecting Faults in Sequential Machines
another. It is convenient for the purpose of this discussion to treat the transition and output checking
portion first, remembering that it depends for its
validity on the characterizing portion.
497
TOCP, constitutes a transition and output checking
portion of a fault-detection test.
n
TOCP=L:
ki
L: XoT(Qo, Si)XilT(Qil, So)
i=1 1=1
n
TRANSITION AND OUTPUT CHECKING TESTS
m
kii
+ L: L: L: XoT(Qo,
Si)XjXij1T(Qij1, So)
(1)
i=1 j=1 1=1
The following notation is introduced for the description of this portion· of the fault-detection test.
Let Si, 1 ~i~n, denote the ith state of M.
Xi, 1 ~j ~ m, denote the jth input symbol.
Sij=O(Si, Xj), denote the Xj successor state of Si.
k i denote the order of the characterizing set for
Si.
{Xii, X i2, . . . , X il, • . . , X ikJ, 1 ~ l ~ ki' denote
the characterizing set for Si.
kij denote the order of the characterizing set for
Sij.
{X ijl, X ij2, . . ., X ij1, . . . , X ijkii}, 1 ~ l ~ kii, denote the characterizing set for Sij.
Let Qil be the state in which M is left after application of X il, M being initially in Si.
Qijl be the state in which M is left after application of Xijl, M being initially in Sij.
T(Sa, Sb) denote an input sequence which
transfers M from state Sa to state Sb.
So denote the reference state for the test.
Xo denote a sequence which takes M from So to
a state Qo and which is also a present-state
locating sequence for Qo.
Xo may also be an initial~state locating sequence
for So and is selected as such if machine M
possesses an initial-state locating sequence for
So.
The following operation symbols are defined.
1. Sequence inclusion is denoted by
+.
+
Xl X 2
means any sequence which includes both Xl
and X 2 as subsequences. It is convenient to call
this "summation."
2. Multiple inclusion is denoted by L:.L:i=l Xi
means any sequence which includes all n X/s
as subsequences. These sequences are not necessarily disjoint, but may overlap.
3. XY denotes sequence X followed by sequence Y.
It is claimed that the following input sequence,
That the inclusion of these subsequences is a sufficient condition for the sequence, TCOP, to constitute
a transition and output checking portion of a faultdetection test is seen as follows. The first summation
verifies a transfer sequence from state Qo to every other
state. The second summation, together with this established transfer sequence, verifies the Xj successors
and Xj outputs for every state. In fact, the second summation includes the first. This is due to the assumed
strongly connected property of the machine. The fact
that every state is reached through some transition
means that a transition check for one state also verifies
a transfer from Qo to another state. Therefore, the
second summation alone constitutes the transition and
output checking portion.
THE TRANSITION AND OUTPUT
CHECKING TREE
The various subsequences of the second summation
of Equation (1) may overlap. The greatest overlap
results in the most efficient fault-detection test. We
now introduce the transition-checking tree as an aid to
achieving maximum overlap. This tree is a form of
state transition diagram with nodes representing
states and directed branches representing transitions
for specified input sequences. The tree consists of four
portions as follows.
1. The locating-sequence trunk consists of a single
branch originating at state So and directed to
state Qo. This branch is labeled with the input
sequence Xo.
2. The transition-covering portion consists of a
state transition diagram originating from state
Qo and developed tree-like through successive
levels until all of the transitions of M have
been covered; There are (m) (n) branches in
this part, each labeled with a single input symbol.
3. The characterization-completion portion carries
the tree through an additional level. From each
terminal node of the transition-covering portion
498
Fall Joint Computer Conference, 1970
is directed a branch or branches labeled with the
input sequence or sequences needed to ensure
that each node of the transition-covering portion
be succeeded by tree paths labeled with sequences covering every element of the characterizing set for the state associated with the
node.
4. The closing portion of the tree carries the tree
through an additional level so that each tree
path ends at state So. There is a branch from
each terminal node of the characterizationcompletion portion labeled with the necessary
transfer sequence to return the machine to So.
In the event that a terminal node of the characterization-completion portion corresponds to
state So, a closing branch labeled with A, the
zero-length sequence, is included.
Figure 1 is the transition and output checking tree
for machine M 4, the state table for which is given in
Table X. Table XI gives the responses of M4 to input
sequences 0, 10, 010 for each initial state.
Specializing the general notation previously gIven
for machine M 4, we obtain:
Sl=A
{Xu} = {010}
S2=B
{X2d= {010}
to, 10}
{X41, X 42 } = to, 10}
The transition and output checking portion of the
fault-detection test is constructed directly from this
tree. This is done by tracing all of the paths through
the tree from the origin (So) back to the common
destination (also So). The input sequences associated
with these paths are then concatenated in any order
to form the transition and output checking portion.
That this is sufficient is seen from the fact that these
paths correspond to the second summation of Equation
(1), covering every transition (input/state combination) , with each transition being followed by each
element of the characterizing set for the successor
state associated with the transition. The following is
such a test for machine M 4 , taken from the tree of
Figure 1,· in left to right path order:
(01000010)
(010001011)
(0100101011)
(01010101)
(010110011)
(010110101)
(01010011)
(010111010)
If the possibly faulty machine responds to the
above sequence as would the fault-free machine, then
one portion, in this case the longest portion, of the
fault-detection test has been passed.
In the following section we present a 23-symbol
characterizing portion for this machine. The above
{X31, X 32 } =
S3=C
S4=D
Locating
Sequence
}
We select So=A
Xo = 010, which is an initial state locating sequence
for state A, having response 000 associated
with it.
Qo=A
Trunk
Transition
Covering
Portion
TABLE X-State Table for Machine M4
Present state
Next state, Output
input = 0
input = 1
A
B,O
D,O
B
C
D
A, 0
D, 1
D, 1
B, 0
A, 0
C, 0
TABLE XI-Response of M4 to Inputs 0, 10, 010
Initial state
A
B
C
D
Response to input sequence
10
010
o
01
000
o
00
001
1
00
101
1
01
101
}
Characterization
Completion
Portion
Closing
Portion
o
Figure 1-Transition and output checking tree for M4
Strategy for Detecting Faults in Sequential Machines
transition and output checking portion contains 70
symbols, making a total of 93 symbols for the length
of a complete fault-detection test for M 4'. Rennie
designs a fault-detection test of length 152 symbols
for this same machine, although he explicitly states
that this is undoubtedly not optimal. The chief saving
over Hennie's test is due to the following:
1. A tree-organized overlapping procedure is utilized together with characterizing sets of order
one for states A and B. Rennie uses the characterizing set {O, 10} for all the states.
2. The sequence 010 is. used for the locating sequence trunk of the transition and output
checking portion. This contrasts with Hennie's
corresponding use of a characterization-verification sequence for state D containing six symbols.
The preceding example was for a machine which
possessed an initial-state locating sequence for some
state. Such a class of machines may be thought of as
intermediate between the class of machines possessing
distinguishing sequences and the most general class,
possessing no initial-state locating sequence. For the
most general case the transition and output checking
tree is still applicable, but a present-state locating
sequence must be used for the locating sequence trunk.
The characterizing portion of the fault-detection test
is much longer for such machines. In this case So is replaced by the set of initial states for which Xo takes
the machine to Qo. The closing portion of the tree may
return the machine to any member of this set.
499
is the same as a state in which it resided prior to at
least one of the applications of X.
Proof
A specialized form of transition graph for a machine
is obtained by letting directed branches between nodes
represent the transitions between states which occur
only for the input sequence, X. The application of Xn
to the machine corresponds to tracing an n-branch path
on this graph. Since M' is assumed to contain no more
than n states, this path necessarily contains a loop.
The lemma follows.
We now proceed to the organization of a characterization-verification sequence. The following notation
is required:
Let {Xl, X 2 , • • • , Xl, ... ,Xk } denote a characterizing set for machine M. (1 ~ l ~ k)
Qil, Qi2, ... , Qil, ... , Qik denote the set of
states to which M is transferred by the application of X il , 1 ~l~k, M being initially in Si.
T(Sa, Sb) denote an input sequence which
transfers M from Sa to Sb.
Then, {XiI, X i2, ••• , X il, . • . , X ik} is another characterizing set for M (and for Si). This is
called the modified characterizing set for Si,
each element being modified so as to return
M to Si when applied to M initially in Si.
Let {ZiI, Zi2, ... , Zil, •.• , Zid denote the set of
responses of M initially in Si to the elements
TRE CHARACTERIZING PORTION OF
THE FAULT-DETECTION TEST
The characterizing portion of a fault-detection test
is composed of characterization-verification sequences
for each state linked together by appropriate transfer
sequences. We now consider the organization of characterization-verification sequences. The strategy used
is based on the behavior of the finite-state machines
for repetitive input patterns. We require the following
lemma for proving the desired result.
Lemma 1
Let xn denote n consecutive repetitions of the input
sequence, X. If Xn is applied to the n-state sequential
machine, M', the state. in which the machine remains
Xil.
Let Y il =X il
Yi(k-l)
= Y i n(k_2) Y in(k_3)· •• Yi1n Xi (k-l)
Y ik = Y in(k_I)Yi n(k_2)··· Yi1nX ik
(2)
Let Wikdenote the response of M initially in Si to Y ik .
Theorem 1
Y ik , defined by Equation 2, is a characterizationverification sequence for state S/, that i~, its applica-
Fall Joint Computer Conference, 1970
500
tion to M' and observation of response W ik verifies
that M' has a state characterized by the characterizing
set for state Si of machine M.
The modified characterizing set for state B is
{01, 101, 110l} = {XBl, X B2 , XB3}.
The corresponding response set is {OO, 000, 0010} =
{ZBl, ZB2, ZB3}.
Proof
Therefore
Note that Yi(k-l) concludes with Xi(k-l). The sequence Xi (k-l) Y i n(k_2) Y i n(k_3)· •• Yiln is repeated n times
just prior to X ik in the sequence Y ik • By Lemma 1 the
state of M' just prior to the application of X ik must be
the same as some state just prior to an application of
Xi (k-l) Y i n(k_2) Y i n(k_3)· •• Yiln. If the correct output sequence, W ik, is observed, this state is one for which
M' responds to Xi(k-l) with Zi(k-l) and to X ik with Zik.
Similar reasoning based on repetitive patterns shows
that the state of M' just prior to the application of X ik
is a state for which M' responds to the input set,
{XiI, X i2 , ••• , X ik }, with the response set,
{Zil, Zi2, •.• , Zid.
A characterization-verification sequence for state
B' of the four-state machine, M3' (Table III), is now
constructed.
A characterizing set for M 3 , {Xl, X 2 , X 3 }, is the set
to, 10, 110} as seen from Table IX.
Input
State of M ':
Output:
01
A'
01
B'
00
D'
00
Y B2 = yn Bl X B2 = (01)4101
Y B3= YnB2YnB3XB3
D'
1
There exist more efficient ways of designing characterization-verification sequences, taking advantage
of the existence of a number of distinct responses to
some elements of the characterizing set in order to
reduce the number of repetitions. The detailed treatment is omitted here.
Frequently there are informal ways of designing the
characterizing portion of a fault-detection test. An
example is provided by the 23-symbol characterizing
portion for machine M4 which has previously been
mentioned. The following is a sufficient sequence for
characterizing the states of M4' and verifying that 010
is an initial-state locating sequence for state A'.
10
D'
14
The first five symbols show that there are at least
three states, because there are at least three distinct
responses to input sequence 010. State A' is located
by response 000 to input 010 and B' is located by
response 001 to input 010. The fifth symbol shows
that there is at least one state for which the response to
input 010 begins with 1. States C' and D' are then
characterized by means of the characterization-verification sequences, 0410 and (01)410, respectively, and it is
established that the response set to input set {O, 10} is
{I, DO} for C' and {I, 01} for D'.
VERIFICATION OF LOCATING SEQUENCES
An initial-state locating sequence is readily verified
by selecting it as one of the elements of the characterizing set. The characterization-verification sequences
designed as indicated here then verify that it is in fact
an initial-state locating sequence. A present-state
locating sequence can also be verified by employing
the characterization-verification sequences as inter-
= [(01)·4101J4(01)41101
W B3= [(00)4000J4(00) 40010
04
0
Y BI =XBl =01
01
(01)4
1
C'
D'
0
10
C'
(10)4
0
C'
00
A'
0
mediate-state locating sequences for the basis of a
partial transition and output checking tree, similar to
the tree described in this paper. The method is straightforward, but the explanation is lengthy and cannot be
detailed here.
CONCLUSIONS
The strategy presented in this paper results in faultdetection tests which are more efficient than those
described in previous work. The length is shortened by
judicious choice of characterizing sets, advantageous
use of overlapping sequences, and by use of the shortest
locating sequence for establishing a reference.
Experience has shown that the transition and output
checking portion of a fault-detection test is generally
the longest part. The saving in length achieved in this
part by using the shortest locating sequence at leats
equals the difference in length between the shortest
locating sequence and the shortest characterizationverification sequence, multiplied by the number of
Strategy for Detecting Faults in Sequential Machines
transitions. The saving achieved by overlapping and
judicious selection of characterizing sets is usually
even more significant, since this results in tracing fewer
paths through the tree and therefore reduces the total
number of sequences required for the test.
4
5
REFERENCES
1 E F MOORE
Gedanken-experiments on sequential machines
Automata Studies pp 129-153
Princeton University Press Princeton New Jersey 1956
2 A GILL
Introduction to the theory of finite-state machines
McGraw-Hill Book Company New York 1962
3 T N HIBBARD
Least upper bounds on minimal terminal state experiments for
6
7
501
two classes of sequential machines
J Assoc Comp Mach Vol 8 pp 601-612 October 1961
F C HENNIE
Fault detecting experiments for sequent.,ial circuits
Proc 5th Annual Symposium on Switching Circuit Theory
and Logical Design pp 95-110 Princeton New Jersey
November 1964
C R KIME
An organization for checking experiments on sequential circuits
IEEE Transactions on Electronic Computers (Short notes)
Vol EC-15 pp 113-115 February 1966
Z KOHAVI P LAVALLEE
Design of sequential machines with fault-detection capabilities
IEEE Transactions on Electronic Computers Vol EC-16
pp 473-484 August 1967
I KOHAVI Z KOHAVI
Variable-length distinguishing sequences and their application
to the design of fault-detection experiments
IEEE Transactions on Computers (Short notes) Vol C-17
pp 792-795 August 1968
Coding/decoding for data compression and error
control on data links using digital computers
by H. lV1. GATES
Braddock, Dunn and McDonald, Inc.
Albuquerque, New Mexico
and
R. B. BLIZARD
Martin Marietta Corporation
Denver, Colorado
INTRODUCTION
put from the decoding process stops and delivers no
further information until the channel improves. The
transmitted data delivered to the user is thus creditable.
The combined process does not require two separate
systems; one for compression and one for error control.
Data compression designers rely heavily on error free
channels and error control factions assume purely
random information into their system and data link.
Naturally, neither is completely true.
In simulating data channels, error control designers
expend a great amount of effort in generating a pure
random number sequence to test their system. Yet,
the data compression specialist expends his time trying
to identify patterns in what is sometimes the most
obscure material. There should be little doubt that the
two· processes are very closely related.
Data compression and error control have, over the
years, been treated as two separate disciplines. Data
compression can substantially reduce the loading of
communication channels and error control using coding
methodology, can reduce the amount of errors in the
messages being transmitted, or allow the· system to
operate with less power for a comparable uncoded information rate. This paper demonstrates that both
functions can be combined into one operation by applying sequential decoding developed for error control to
data compression. Because the same general method
can be used to solve both problems, data compression
and error control can be united in a single system and
held accountable for the required theorems in information theory.
The principal incentive for the use of sequential decoding for both compression and error control is that
it permits the use of the source redundancy with extremely simple encoding equipment. Higher speed computing systems and larger available memories make it
more feasible to use various redundancy schemes. In
photographs, for example, line-to-line redundancy can
successfully be used.
The proposed process of combining data compression
and error control in a sequential decoder is reversible
because the original data is recovered intact with no
compromising or loss of information and resolution.
This is attributed to the sequential decoding process
itself. Uncertainty about data modification and missing
data does not exist. If the capacity of the channel is
exceeded because of increased noise or information
activity beyond the design of the system, the data out-
Background
The means for decoding convolutional codes first became practical when R. M. Fano in 1963 introduced his
now famous sequential decoding algorithm. 1 ,2 1. M. Ja'cobs 3 recently discussed sequential decoding as it applies
to retrieving data from a space probe. He points out that
this is a particularly good application because fading is
relatively unimportant, channel noise is nearly Gaussian, and the information rate is limited by the available signal strength rather than by the bandwidth.
Significant developments in the im.plementation of
sequential decoders have occurred in the Pioneer IX
space program;4 at the MIT Lincoln Laboratory;5 and
by the Codex Corporation;6 and new algorithms for decoding convolutional codes are being disclosed
annually.7
503
504
Fall Joint Computer Conference, 1970
Convolutional Codes
Noise'
n = I
k = It
v 2 3
G=
(a)
Convolutional Encoder
1000 )
1111
( 1011
n+3
H=O,I,O,O
move is up
if m .. 0
n
move is down
if m .. I
n
(b)
Code. Tree
Figure l-Binary convolutional encoder and its code tree for first
4 moves
The possibility of applying error control coding to
data compression was first pointed out by Weiss 8 who
showed that block codes work fairly well for compressing data streams consisting of a few l's scattered
at random among many O's. However, this type of
source can be very efficiently and easily encoded with
a run-length encoder. More interesting sources are those
in which the redundancy is of a more complicated type
and is not easily utilized by a block decoder. Sequential
decoding is ideally suited to this type of problem.
With block codes such as the orthogonal and BCH
codes, the entire block is ordinarily decoded as a unit
by computing correlations or by solving certain alge~
braic equations. Sequential decoding starts at the beginning of a message block and works toward the end
by a trial-and-error process. A running account is
kept of the reasonableness of the decoded message on
the basis of received signal. If a wrong decision is made
because of noise, the subsequent decoded message soon
becomes unreasonable, and the decoder then searches
back over its earlier choices until the correct message
is found. It is relatively simple, in concept at least, to
use what is known about the message probabilities to
improve the likelihood criterion. This aUows more
data to be tr~nsmitted over a given link and accomplishes data compression.
Figure la shows a convolutional encoder with a
binary message source, M, assumed for the time being
to be random information, and an error source, N, representing channel noise. Messages from the source S
may be shifted in one or more bits at a time denoted as
n. After each shift, v mod-2 adders (in this case three
mod-2 adders) are sampled or commutated and the
resultant bits passed into the transmitter equipment of
the data channel. If four bits are shifted in before the
encoder output is commutated, a convolutional data
compression process occurs at rate %. The decoder
must then use the a posteriori probability of the source
S in defining the decoding parameters of the Fano
algorithm. Normally, rates of Y2, ~, and even 7.4: are
used in error control. That is, for each bit shift in, from
two to four mod-2 adders are sampled. The number of
mod-2 adders normally is fixed or hardwired for a particular mission or channel requirement. The connections from these mod-2 adders to the shift register, G,
represents the codes themselves and a great deal has
been written about this subject particularly if the shift
register length, called the constraint length, k, is below
12 to 15 bits. Random selection of these codes for large
constraint lengths produces adequate, if not complete1y
satisfactory, results. 9 Two rates of 2/1 and 6/4 are
demonstrated here. Constraint lengths of 60 bits are
used as well.
The basic channel
The channel is important in both error control and
compression since it represents the sole source of noise
and thus errors into the system, that is, receiver frontend noise, electronic noise in the lines, and so forth, are
combined into one noise error source. By definition
then, the channel referred to here contains the system
modulator, amplifiers, transmitters, antennas or cables,
repeaters, receivers, and demodulators. The noise of
this channel is assumed to be Gaussian or white noise.
The channel is assumed to be stationary in the sense
that its properties do not change with time. And the
channel· is assumed to be memoryless. The channel is
described as binary antipodal in which the transmitted
waveforms in the absence of noise are a sequence of 180
degree, phase-modulated waveforms, or binary data
represented by plus and minus voltages for ones and
zeros respectively.
The restrictions imposed on the channel are to this
point, fairly realistic, depending of course on the
method of transmission. In passing, if the received
Coding/Decoding for Data Compression and Error Control
binary sequence is quantized into say four or eight
levels for each bit received, the compression and error
control performance can be increased. This is a well
known fact in information theory. This quantization
does not change the basic operation of this system or
any of the convolutional decoders that this author is
aware of.
The decoder
Convolutional codes generated by the encoder shown
in Figure 1a can be decoded in one of several ways. The
oldest practical method is the use of the Fano Algorithm
which is well described in several references. 2 The Fano
Algorithm sequentially decodes the data stream as it is
received and thus the reference to sequential decoding.
Actually, there are several new algorithms for decoding
convolutional codes which are extremely clever and
add promise to the combination of error control and
data compression.
Without going into great detail, a sequential decoding
process will be described next. Any code produced by
the convolutional encoder may be represented by a
binary tree. The encoder input M =Ml, M 2 , ••• , corresponds to an infinite path through the tree, and labels
on the branches indicate the encoder output. Figure
1b demonstrates this point for a given convolutional
encoder. Since more bits are being generated than received in the. encoder, i.e., n
Figure 3-H and D for normal distribution
p(x) log2P(x) dx.
(4)
-00
lating the picture lines from the part of the image that
has already been decoded into the region that is being
decoded. The probability of "black" for an image
element will strongly depend on its position relative to
lines in the part of the image that has already been
decoded.
Similarly, for the lower bound on required channel
capacity with sequential decoding,
D[ {wd J!: 2log2 [L (Wi)1/2].
i
Again, to get a lower bound, the square root can be
performed under the integral, giving
D[{wdJ~2Iog2 foo
Normal distribution
[p(x)J/2dx.
(5)
-00
The prevalence of the normal (or Gaussian) distribution in nature is generally exaggerated, but it is mathematically tractable and is a reasonable approximation
in many practical cases.
Suppose that the message consists of successive
values of a variable v. At any point in the decoding,
the next value of v can be predicted on the basis of past
values and any other pertinent information. Assume
that the actual value· differs from the predicted by an
amount that is normally distributed with rms deviation
equal to u. For simplicity in the notation, let the quantizing interval be 1. At each sampling time, the expected
value of v is vo(t) based on a knowledge of all the previous values of v. The actual value of v is
Integrating Equation (4) provides
H~
(6)
and from Equation (5),
D~
log2 u(87r)1/2=2.33+ log2 u.
(7)
The above bounds are good approximations for large
Y2 are tabulated in Table
1 with the expected value in the center of a quantum
interval (A) and the expected value on the boundary
between two quantum intervals (b).
u. Exact results for u = 1 and
TABLE I-The Compression and Entropy Values for a Normal
Distribution with U' = 1 and Yz
v(t) = vo(t) +x(t),
where x is the difference between the true value and
the predicted value.
Let x have a normal distribution:
log2 [u(27re)1/2J=2.05+ log2 u;
9'= Yz
U'=1
----------
A
B
A
B
H
2.11
2.09
1.24
1.36
D
2.38
2.37
1.43
1.50
p (x)= [u(27r) 1/2J-1 exp ( - x2/2( 2).
With unity as the quantization interval, the probabili-
508
Fall Joint Computer
Conferen~e,
1970
Search and
110 - 2.32
60-bit word lengths
Source
Encoder
Decoder
Figure 4-Model of a simple system
The deviations from the bounds are small for u = 1 and
less than 0.31 bit for u = Y2.
Figure 3 shows the bounds, which are good approximations for u> 1, and also the behavior for small u
when the quantization boundary falls exactly on the
expected value of v.
D is the number of bits of channel capacity required
to transmit each message element. Equations (6) and
(7) are derived with the assumption that there is no
limit on the range of v. Thus an infinite number of
quantization levels are spaced at unit intervals. The
amount of compression available at the computational
limit depends on the actual number of quantization
levels used. For example, suppose a picture is quantized
to 64 gray levels (6 bits) and u=0.8. From Figure 3,
D = 2.0 and H = 1.8. The compression ratio for sequential decoding is 6/2 =3.0, and the maximum available
is 6/1.8 =3.3.
content (entropy) is less than 1 bit/symbol and some
compression of the data is possible. As was shown in
(3), the compression term may be found as
D = log2 [( wl)1/ 2 (w2)1/ 2J2 = 0.425.
+
The ratio of input to output symbols is 1/D = 2.36, and
for'this example a ratio of 2 was used.
Consider a second examp] e pertaining to channel
coding rather than source coding pointed out by G. D.
Forney. Let the encoder use a nonsystematic rate Y2
binary constraint length. code shown in Figure 5. The
channel is a binary symmetric channel with error probability p. Syndromes that contain all information about
the errors and are independent of data are formed at
the decoder so that all-zero data can be assumed. A
syndrome sequential decoder decodes the syndromes
and determines the error locations; the error locations
are used to make corrections on the data. It is clear
that the syndrome form of Figure 5 corresponds to the
encoder of Figure 4, and that the behavior of the Fano
algorithm sequential decoder is identical in the two
cases. In particular, since Rcomp
0
10
10
UJ
I-
511
UJ
4
5
3
6
7
8
SQUARE ROOT OF (u**2+V~b't2)
9
10
CORRELATION FUNCTION
PIX 4 UPPER RIGHT CORNER
~
~
~
>
>
2-
u
~
:z
en
0
0
~
I-
~
UJ
~
>
UJ
a::
a::
I-
u
~
~
0
~
~
2
en
~
20
en
~
o
:I:
I-
:z
8
6
4
2
~
u
o
:z
10
3
4
5
6
7
8
9
10
SQUARE ROOT OF (U**2+V**2)
CORRELAT10N FUNCTION
PIX 1 LOWER LEFT CORNER
18
4 8 12 16 20 242832 36 40 4448 52 5660 64
GRAY LEVELS
PROBABI LI TV DENSHY FUNCTION OF DATA SOURCE
PIX 4 UPPER RIGHT CORNER
Figure lO-Autocorrelation of picture data using the pattern of
Figure 8 (Probability density functions of the areas examined
are included)
16
14
12
10
8
6
4
2
4 81216 202428 3236 404448525660 64
GRAY LEVELS
PROBABILITY DENSITY FUNCTION OF DATA SOURCE
PIX , LOWER LEFT CORNER
Figure 9-Autocorrelation of picture data using the pattern of
Figure 8 (Probability density functions of the areas examined
are included)
previous work. This procedure was accomplished on a
CDC 6400 digital computer.
The correlation pattern was subdivided, into. foul'
regions, as indicated in Figure 8, to investigate directional variation. Samples of the results· of our correlation computations are shown in Figures 9 and 10 for
two pictures. Each of the four symbols represents one
of the four regions. The probability density functions
are also shown for regions in which correlation data
were established.
If the analyst wants to apply the correlation data to
an· efficient prediction program, he must evaluate the
results of Figure 8 using a mean square estimatiop.
technique to determine how effective the correlation
coefficients are in predicting results as a function of
various patterns. The correlation patterns must be
selected on the basis of which appears to be the most
512
Fall Joint Computer Conference, 1970
four or five picture elements there is little need for the
additional data supplied by more picture elements to
estimate the value of the base picture element.
Extending the model
rfh rR,
0.7
q.6
~
1\
5
~
6
rrr
I I I I
~
9
............
c:
ttJ
(l,)
~
0.5
E
0
'-
4-
c:
\
0.4
0
+J
ttJ
>
(l,)
0.3
~ --
0
~...............
V')
~
0:::
0.2
~
O. 1
o
('v
3 4 5 6
Number of Elements
2
9
Figure ll-RMS deviation from mean given a set of patterns
efficient. The pattern shown in Figure 8 was used to
gather data rather than trying to determine an efficient
pattern. These results are then applied to the sequential
decoder algorithm.
Eleven pixel patterns were tested. These patterns,
along with their performance, are shown in Figure II.
The base pixel to be predicted is noted with an X.
The vertical axis of this figure is the rms deviation
from the mean of the base pixel to the surrounding
values. High rms deviations represent large. errors in
estimating the base pixel values. The horizontal axis
represents the number of elements used to evaluate
the gray levels of the base pixels. The correlation coefficients were used for low, average, and highly correlated
pictures. Thus, the top curve represents the rms deviation from mean for low correlated pictures using the
different pattern structures shown. The middle curve
and the bottom curve represent the average and highly
correlated rms deviations from mean, respectively.
From this set of curves, it can be seen that after
The example of the preceding section may he extended to handle the picture data discussttd here.
Knowledge of the picture statistics aids in the deCoding
process just as it did for the binary case. The only
difference in the source is the complexity of the data .
For this simulation, use was made of the statistics associated with Picture 2 (Table II), which are highly
correlated. The standard deviation of the base pixels
of this picture with their adjacent elements was computed at the same time the correlation data were collected. These deviations are shown in their respective
locations associated. with the base pixel in Figure 12.
These values represent an average over all base pixels
in Picture 2 and are measured in terms of gray levels.
The base pixel was predicted to within u = 2 or so using
the results of Reference 8, which were programmed on
a digital computer. The term D from Reference 7 was
solved for a Gaussian distribution, which is a function
of S. This calculation yields D=2.33+ log2 u=3.4 if
u=2. The system is designed to run at rate ~~. The
simulation used a convolution encoder with a 6-bit
input shift, 4 mod-2 adder outputs, and a constraint
length of 60 bits.
The branch metric for the Fano algorithm is selected
according to the distance the decoded message was
from the guess as a function of u and the Gaussian
distribution with mean of the distribution at x. A
branch metric lookup table may be computed before
the decoding operation is started so
B M = log2 p= log2f(y)
where
f(x) = [u(27r)1/ 2J-l exp - {(x-x)2/2u 2}.
With a rate ~~ sequential decoder, four choices are
available (if noise is not present) to generate the four
branches of the code tree.
System simulation
The pictures were read from a 7-track magnetic tape.
The simulation included the encloder, branch metric
1. 70
1 .80
1 .60
1 .34
base
pixel
1 .54
Figure 12-Standard deviations of adjacent pixels to a base pixel
of picture 2
Coding/Decoding for Data Compression and Error Control
lookup table, Fano algorithm sequential decoder, comparator, and the appropriate control algorithms. The
block diagram is shown in Figure 13. The pattern used
for prediction 'is pattern 4 of Figure 11 with the appropriate coefficients. To avoid startup problems, the first
line and first column of each picture was read in and
assumed to have been correctly decoded. This, in fact,
identifies the single largest problem of systems like
this one. It can be overcome, however, as discussed
later.
Again the system was programmed on the CDC
6400, which provided sufficient core storage to store
the data fields required to make proper evaluation of
the base pixel. Searching time, however, is slow (100
searches per second) due in part to the evaluation of
the branch metrics. The results of the simulation are
shown in Figure 14 when the average number of searches
per line is shown as a function of first difference picture
entropy. Each picture contains 684 elements per line
and 683 coded elements are being simulated. The programs have been limited to 40,000 searching operations.
An attempt was made to decode Picture 6, first difference entropy = 4.00, with some interesting results. The
system started decoding properly, but after 50 or so
lines the maximum number of searches was exceeded
and an erasure occurred. The decoding of successive
lines deteriorated rapidly where erasures occurred
sooner on each line than the line before. Complete
erasures occurred 7 to 8 lines after the first erasure was
detected.
The system was forced to restart halfway down, and
the same phenomena occurred after several lines. The
decoder simulation of Picture 7 would exceed the 40,000
calculation limit with every line. Only a small portion
of Picture 7 was simulated because of the long run
times encountered.
k = 60
SHIFT = 6
v = "
Figure 13-Rate 3/2 simulation model for picture data
513
UJ
Z
....J
........
(/)
UJ
:J:
u
0::
74
c::{
UJ
(/)
IJ..
0
72
0::
UJ
co
~
:::::>
z
UJ
(!J
c::{
0::
4.0
UJ
:::c::{
FIRST DIFFERENCE ENTROPY, H
Figure 14-Performance of the 6/4 decoder-compressor
The results imply that once an entropy of a value in
the neighborhood of 3.65 is exceeded, then Rcomp is
exceeded. From Figure 3, it can be seen that for H =
3.65, 0"=3. For 0"=3, D=3.9, which is very near the
output value of the convolutional encoder of 4. Theoretically, at least, activity any higher than H =3.6 or
so should be difficult to decode. This was verified by
Pictures 6 and 7. The simulation uses a pattern of 5
elements but the entropy was computed on two pat~
terns (first differences between the preceding element
and the base pixel). Thus, some information should be
decoded above the first difference entropy of 3.65.
SPECIAL PROBLEMS
Certain anticipated problems and some. possible solutions are discussed next.
Variable activity
Any data compression scheme (such as this one)
that maintains a constant rate in terms of data points
per unit time must be designed to operate with the most
active data expected; consequently, it will achieve
substantially less compression than is possible in the
dull regions. If the regions of high activity are considered to be analogous to bursts of noise, the analyst
immediately thinks of interleaving as a way to even
out the data statistics. In interleaving, the encoder
would be equivalent to J separate convolutional encoders, each accepting one out of every J consecutive
data points.
If there is an interval of active data m data points
long, the decoder will only have to search through m/J
branch points to get over the active region. Furthermore, if the decoder fails on· one of the j channels but
succeeds on the preceding and followin,g ones, it can
interpolate between these adjacent data values to im-
514
Fall Joint Computer Conference, 1970
prove the probabilities for the channel on which it
failed, and thus may be able to decode it.
It is also possible to treat regions of high activity by
leaving off one or two of the least significant bits in
each data word. Other types of processing can also be
added to increase the compression. The decision to incorporate them will depend on an evaluation of their
cost in complexity, power, and weight, and on the gain
in performance they offer.
Startup
When a two-dimensional image is transmitted, the
decoder will utilize previously decoded lines to improve
the probability estimates for the elements of the line
being decoded. Because this information is obviously
not available for the first line, some special technique
must be used on the first line (and possibly a few more)
of each frame.
Perhaps the simplest method is to round off the data
in the first few lines by forcing one or more of the least
significant bits to be zero. In the course of a few lines,
the rounding off would be gradually reduced and finally
eliminated. For instance, suppose that 64 gray levels
are encoded into 6 bits. The first line might be rounded
off to 4 bits and the second to 5. In the third line, every
other picture element might be rounded to 5 bits with
the alternate elements intact, and the fourth line could
have complete data. This would result in a picture with
less detail on the upper edge than elsewhere. If this
degradation cannot be tolerated, the first line can be
transmitted at a lower rate with each picture element
being repeated. However, this latter method might
seriously complicate the data gathering system.
A similar problem arises at the start and finish of
each line because there are fewer neighboring picture
elements available to help the prediction. It may be
possible to solve this problem by making the ends of
the coding blocks coincide with the ends of the lines.
The decoder has an advantage at the start of a block
because it never has to search back beyond the first
node. Near the end of the block, it has a similar advantage because of the series of zeros that is injected
to clear the encoding register.
CONCLUSIONS
If computation can be done cheaply at the transmitter,
then conventional types of data compression are preferable. Large buffers at the transmitter can smooth out
variations in data activity, and uninteresting data can
be removed by editing before transmission.
The principal advantage of data compression using
sequential decoding is that it requires no additional
equipment at the transmitter. When transmitter costs
are much greater than receiver cost, as in a space-to-
earth or air-to-ground link or where there are many
transmitters and a single receiver, this method is likely
to be cost-effective and may be the only possible one.
For the space-to-earth link, the savings are in producing software for general-purpose computers on
the· ground rather than hardware in space. In addition
to .the obvious saving in reliability and in power and
weight on the spacecraft, cost and development time
can be saved by avoiding hardware design and qualification test. It is even possible to increase the information rate of vehicles already flying by modifying the
decoding program to exploit data redundancy.
REFERENCES
fRMFANO
A heuristic discussion of probabilistic decoding
IEEE Transactions on Information Theory Vol IT-9
pp 64-74 April 1963
2 J M WOZENCRAFT I M JACOBS
Principles of communication engineering
John Wiley and Sons Inc New York N Y pp 405-476 1965
3 I M JACOBS
Sequential decoding for effective communication for deep space
IEEE Transactions on Communication Technology
Vol COM-15 pp 492-501 August 1967
4 D LUMB
Test and preliminary flight results on the sequential decoding
of convolutional encoded data from pioneer I X
IEEE International Conference on Communications
Boulder Colorado p 39-1 June 1969
5 I L LEBOW R G McHUGH
A sequential decoding technique and its realizational in the
Lincoln experimental terminal
IEEE Transactions on Communications Technology
Vol COM-15 pp 477-491 August 1967
6 G D FORNEY
A high-speed sequential decoder for satellite communication
IEEE International Conference on Communications
Boulder Colorado p 39-9 June 1969
7 J A HELLER
Seq'uential decoding: Short constraint length convolutional
codes
JPL Space Programs Summary 37-54 Vol III pp 171-177
1969
8 E WEISS
Compression and coding
IRE Transactions on Information Theory pp 256-257
April 1962
9 R G GALLAGER
Information theory and reliable communication
Wiley and Sons Inc New York 1968
10 J MWOZENCRAFT I M JACOBS
Principles of communication engineering
John Wiley and Sons Inc New York 1965
11 R BLIZARD H GATES J McKINNEY
Convolutional coding for data compression
Martin, Marietta Research Report R-69-17 Denver
Colorado November 1969
12 R F RICE
The code tree wiggle: TV data compression
JPL Report 900-217 STM-324-27 Pasadena California
October 1968
Minimizing computer cost for the solution of
certain scientific problems
by GERALD N. PITTS and PAUL B. CRAWFORD
Texas A&M University
College Station, Texas
and
BARRY L. BATEIVIAN
University of Southwestern Louisiana
Lafayette, Louisiana
INTRODUCTION
ever, to get to the heart of the problem, this paper
investigates the costs of different methods of solving
the cited equations. After determining the most economical method, the method is then scrutinized for
internal cost reduction.
I t was found that as far as cost is concerned, the
three methods fell into the following descending order;
(1) Liebmann, (2) ADIP, (3) banded matrix inversion.
The cost per solution using ADIP was less than 1
percent over the cost of the banded matrix method.
The cost of Liebmann, however, was 200 percent larger
than the smaller of the other two. ADIP was chosen
for special study because of its versatility in solving
both large or small transient or steady-state problems.
The banded matrix method on the other hand is very
limited by its required computer core space and becomes impractical for a large number of equations,
that is, more than a few hundred.
Many scientific problems require solution of the Laplace, Poission or Fourier equation. These equations
occur in heat flow, fluid flow, diffusion and structural
problems. It is well known that these types of problems
lead to large sets of simultaneous equations that frequently require a number of iterations consuming a
lot of computer dollars before a solution is obtained.
Frequently one must solve.· a few hundred to a few
thousand simultaneous equations. Numerical methods
likely to be used for solution include: (1) Liebmann,!
an explicit method, (2) alternating direction implicit
procedurel ,5 and (3) banded matrix mverSIOn
technique. 4
The computer was first thought to be the salvation
of the engineer or scientist who had to solve these
types of problems because of the great speed of the
machines. In early work with computers large computer
appropriations were frequently made available to
scientific researchers in this area. The engineer or
research scientist could .afford the luxury of experimenting with the many solution techniques that required considerable computer time. However, times
have changed in terms of computer appropriations.
Many groups are now being brought into the computer
act, and the budget is divided and distributed. Net computer appropriations to some groups have been decreased or at most have been the same for the past
few years. However, the computer is expected to perform more and more tasks.
Budget problems have caused the engineer and
scientist to strive for the best solution at the least
possible cost. Cost reduction can be a broad area; how-
MATHEMATICAL DEVELOPMENT FOR ADIP
The partial differential equation that governs the
unsteady-state flow of fluid or heat in rectangular
coordinates of two dimensions is:
(1)
The ADIP procedure requires that one of the second
derivatives, i.e., iJ 2PjiJx2, be replaced with a second
difference evaluated in terms of the unknown values
of P, while the second derivative, i.e., iJ2PjiJy2, is replaced by a second difference evaluated in terms of
515
516
Fall Joint Computer Conference, 1970
known values of P. Thus, in the alternating direction
implicit method two difference equations are used.
P x- Ax ,y,2n+l- (2+p) ·Px,y,2n+l+Px+Ax ,y,2n+l
= -PX,y-Ay,2n+ (2-p)
·PX,y,2n-Px,y+Ay,2n
(2)
and
P x ,y-Ay,2n+2- (2+p) ·Px ,y,2n+2+Px ,y+Ay,2n+2
= -Px- Ax ,y,2n+l+ (2-p) ·Px ,y,2n+l-Px+Ax ,y,2n+l
(3)
where
AX=Ay,
The use of equations (2) and (3) alternately results
in a set of tridigonal simultaneous equations that can
be solved by a technique illustrated by Douglas2 and
Peaceman and Rachford. 3
Use of equation (2) or (3) at each time step leads
to N sets of N simultaneous equations of the form:
Ao+BoPo+CoPl=Do
ADIP method. Both problems represent fluid flow in a
reservoir, one in a homogeneous media, the other in a
heterogeneous media. The reservoirs are scaled to a
10 X 10 net or grid size with a permeability coefficient
located at each grid intersection. Note, a 10 X 10 is
hardly of practical size, but was all our budget would
allow for this study. The desired solution is a matrix
of potential or pressure values at a steady-state condition of the system. Each time step of the solution represents one iteration. Each iteration is a small portion
of the total computer expense, but becomes quite
important in the costs.
Referring to the above equations one may ascertain
that each iteration is a function of p = c· (AX2/ At), and
therefore the cost analysis will depend primarily upon
the effects of this parameter. Table I shows the effect
of varying this on the cost for the homogeneous case.
Table II shows the effect of this parameter upon the
costs for the heterogeneous case.
ArPr-l +BrPr+ CrP r+l = Dr
An-1Pn-2+ Bn-1P n-l +Cn = D n- 1
(4)
where
l~r~n-2
The solution of these equations can be accomplished
as follows:
Let
Wo=Bo,
where
l~r::;n-l
br=Cr/Wr
where
0~r~n-2
go = Do/Wo
(5)
gr=Dr-Argr-I/Wr
where
The solution is
P n- 1 = gn-l
where
0~r::;n-2
The w, b, and g are computed in order of increasing
rand P is computed in order of decreasing r.
PROCEDURE APPLICATION
Two specific problems are presented here to illustrate
the wide differences in computer execution cost of the
RESULTS FOR THE HOMOGENEOUS CASE
Table I shows the relative cost for different iteration
parameters.
Cost differences can be determined by comparing
the effects of different iteration parameters. The solution at the two points studied here are 48.35 and 51.33
respectively. The solutions shown in Table I were
determined to be convergent by point material balances.
A small iteration parameter implies a large time step,
therefore indicating the prospects of obtaining a solution upon fewer iterations. However, this is not always
the case because there is a limit to the size of the timestep. For example compare the number of iterations
of the third entry to the fourth entry in Table I. It
took 12 iterations for convergence for both solutions
even though the increment was ten times smaller
(meaning a larger time step) for the third entry than
the fourth. However, on the whole for the homogeneous
case the small iteration parameter (within some limits)
will yield a less expensive solution. It was also discovered that the sequence in which the parameters
are employed have a tremendous effect upon costs.
Again, looking at Table I, the first entry requires six
iterations while entry number four requires 12 iterations. They both use the same iteration parameters
but one sequence is the reverse of the other. The direction then in this case could mean a 50 percent cost
reduction to obtain a solution.
Comparing entry number six with entry number two
in Table I shows that a tenth smaller parameter could
yield a cost savings of over 50 percent. However when
the use of this small and constant parameter (entry
Minimizing Computer Cost
517
TABLE I-Relative Computing Costs When Using Various Iteration Parameters
(Homogeneous Media)
Program
No.
1
2
3
4
5
6
Iterations(l)*
6
8
12
12
16
17
p(2)
.1---71.1
.396
.1---71.1
1.1---7.1
0.01---71.1
3.96
Increment(3)
P(4.6)(4)
P(9.6)(4)
Time (5) (Sec.)
Cost(6) $
0.2
48.34
48.35
48.35
48.33
48.37
48.62
51.33
51.32
51.33
51.34
51.35
51.18
4.42
6.01
8.91
9.09
12.06
13.34
.44
.60
.89
.91
1.21
1.33
.02
.2
.02
*See notes below:
(1) Number of Iterations to Convergence
(2) Iteration Parameter Sequence p = Il.x2 / Il.t
(3) Iteration Increment Within the Sequence
(4) Pressures (psi) at Points (x, y)
(5) Computer execution times in seconds
(6) Approximate cost per equations (IBM 360/65 WATFOR)
number two) is compared with a parameter sequence
(entry number one in Table I) it is seen that a cost
saving of about 25 percent is achieved by using the
sequence.
The three cost saving observations that can be made
from Table I are: (1) use as small a parameter as possible that yields convergence, (2) employ some sequence of parameters instead of a single value, and (3)
utilize the direction of the sequence that gives the least
number of iterations.
RESULTS FOR HETEROGENEOUS CASE
Table II shows the relation between cost and iteration parameter for the heterogeneous case. The hetero-
geneous case is quite different program-wise than the
homogeneous case because it must utilize several computer library functions to generate and maintain the
heterogeneous coefficients. The execution times shown
in Table II are therefore much greater than those of
Table 1. This difference in cost magnitude is also considered a factor in determining the economic feasibility
of simulating a heterogeneous system over a homogeneous one. The heterogeneous case requires the generation of reservoir geologic information (requiring
considerably more subroutines and equations) therefore requiring more computer execution time.
The range of coefficients (k) for the heterogeneous
case was (0.1-100). These coefficients were distributed
randomly throughout the grid or net. Table II shows
TABLE II-Relative Computer Costs When Using Various Iteration Parameters
(Heterogeneous Media)
Program
No.
1
2
3
4
5
6
7
8
I terations(l)*
77
72
6
4
100
18
11
74
p(2)
3.96
.396
0.1---71.1
0.01---71.1
.1---71.1
1.1---7.1
1. 1---70 . 01
1.1---7.1
Increment(3)
0.2
0.2
0.02
0.2
0.02
0.02
*See notes below:
(1) Number of Iterations to Convergence
(2) Iteration Parameters Sequence p = Il.x 2/ Il.t
(3) Iteration Increment within the Sequence
(4) Pressures (psi) at points (x, y)
(5) Computer execution times in seconds
(6) Approximate cost per 100 equations (IBM 360/65 O.S.)
P(4,6)(4)
49.34
"45.61
49.37
49.11
44.06
49.06
49.21
46.47
P(9,6)(4)
Time(5) (Sec.)
Cost(6) $
49.59
45.86
49.62
49.54
44.30
49.36
49.41
46.72
59.58
57.05
32.30
30.94
69.00
36.31
34.29
59.62
5.96
5.71
3.23
3.09
6.90
3.63
3.43
5.96
518
Fall Joint Computer Conference, 1970
the results of several different iteration parameters
upon the cost of solution. The exact solution at the
designated points were 49.10 and 49.30, respectively.
The approximate same generalities can be made about
the heterogeneous case that were made about the
homogeneous case.
The one-tenth reduction in magnitude of the single
value iteration parameter (comparing entry number
one to entry number two) results in only a small fraction of the cost reduction shown for the homogeneous
case. However, when a sequence of parameters is
employed instead of a single value (comparing entry
number two with entry number three) a cost reduction
of about 90 percent is obtained compared to about 50
percent for the homogeneous case. Again, as in the
homogeneous case the direction of the sequence employed can result in considerable savings. For example
when comparing entry number three with entry number six, one finds a savings of about 66 percent. For the
heterogeneous case the cost was always greater than
that for the homogeneous case. A greater number of
iterations was required for convergence than for the
homogeneous case.
SUMMARY AND CONCLUSIONS
Several factors should be considered before a large
system of equations is solved. First, does the problem
warrant a large computer expense? It is definitely more
expensive to simulate. a heterogeneous system than a
homogeneous one. Can a homogeneous solution be
used, if so, the cost may be only a fraction of the cost
of the heterogeneous case. Can a few equations be used
rather than a few hundred or thousand?
It was found that ADIP was superior in terms of
breadth and cost, although it was slightly more expensive than the banded matrix method. Within the
ADIP method itself several dollar-saving techniques
may be used. It is better to use a sequence of iteration
parameters than a single repetitive value. The direction
in which this sequence is employed is very important.
For the homogeneous media it is better to use as
small a parameter as possible. This appears to hold
true for the heterogeneous media case with some
limitations.
If the factors presented in this paper are considered,
the savings in terms of dollars can be very substantial.
REFERENCES
1 G D SMITH
Numerical solution of partial differential equations
Oxford University Press pp 149-151 1965
2 J DOUGLAS JR
On the numerical integration of J.!.xx +J.!.yy = J.!.t by implicit
methods
J Soc Ind Appl Math Vol 3 pp 52-65 1955
3 D W PEACE MAN H H RACHFORD JR
The numerical solution of parabolic and elliptic differential
equations
J Soc Ind Appl Math Vol 3 pp 28-44 1953
4 B R KOEHLER
Private Communication Texas A&M University
College Station Texas March 10 1969
5 B CARNAHAN H A LUTHER J 0 WILKES
The implicit alternating-direction method
Applied Numerical Methods Vol 2 pp 543-553 1964
Analytical techlliques for the statistical evaluation
of program running time
by BORIS BElZER
Data Systems Analysts, Inc.
PenIlBauken, New Jersey
PROGRAM MODELS
INTRODUCTION
The design of large software systems or real-time systems imposes several constraints on the designer. Predominant among these are the running time of the
programs, the amount of memory used by these programs, and the input/output channel utilizati~n. A
well considered design not only runs, but has optImum
efficiency. Efficiency is often measured by the running
time of the program.
If the designer must wait till the program is running
to evaluate its running time, important design decisions
will have been made, and cannot realistically be
changed. Consequently, trades that could have improved the efficiency of the programs will not ha~e
been made. This will result in higher unit processing
cost, increased hardware, or a reduction of available
capacity. In real-time programs, the difference may
be that of working or not working at all. For these
reasons, the system analyst and programmer require
techniques that allow the evaluation of such trades
and the early estimation of running time.
Simulation is one method that has been used for
timing analysis. The major blocks of the program are
described in a simulation language that must be learned
like any other programming language. The program
simulator is run, statistics gathered, and the efficiency
of the program judged thereby.
Analytical techniques, on the other hand, have not
been extensively used for several reasons: the analysis
has been too tedious for the value of the results obtained; such analyses have required a greater knowledge
of mathematics than typical for a programmer; the
solutions can be overly complicated (e.g., including
transient behavior). In short, both analytical methods
and simulation have been effectively inaccessible to
. the one who needs it most-the programmer. Yet this
need not be, if we are willing to make a few analytical
assumptions.
Simulation or analysis both require a model. The
model that we shall use for a program is based on the
flow chart of the program. The model consists of junctions, decisions, and processes, as depicted in Figure 1.
Associated with each process is an execution time, obtained by counting the instructions (with appropriate
modification for indexing and indirect operations)
within that process. Associated with each decision is a
probability for each of the several exident branches.
The sum of such probabilities must equal 1. Furthermore , the probabilities are assumed to be fixed .and
not to depend upon how the program got to the partICUlar branch. This will be recognized as a Markov model
assumption. Though this assumption is not always
valid, * the number of cases in which it does not hold
are sufficiently rare to allow us to ignore them. Furthermore, if we do not assume a Markov model, the resulting analysis is overly complex.
.
There is one difficulty with this model; the processmg
that takes place at a decision. It can be readily shown,
that for analytical purposes, we can transform a decision
to a new decision followed or preceded by processes,
such that there is no work done at the decision itself.
This is depicted in Figure 2.
Having done this, we can simplify the model further,
by eliminating the distinction between junctions and
decisions. The new model consists of nodes and links.
That is, the model is a graph. Associated with the outways of each node, there is a probability t~at that ou~
way will be taken. Associated with each lmk, there IS
work required for the execution of the instructions
represented by that link. A link then, can represent a
* As an example, consider a program switch within a loop whose
position is determined by a count o.f the number of pas~ages
through the loop. While the mean IS unaffected, the vanance
will depend on the way the program got to that point.
519
520
Fall Joint Computer Conference, 1970
JUNCTIONS
OR,
--
PROCESSES
Figure 2-Equivalent decisions
It is clear that any reasonable flow chart and, hence,
any reasonable program operating within a single computer at one priority level, can be readily modeled in
this manner.
Our problem is then: given the graph corresponding
to the flow chart of a program, properly annotated
with the required link properties (p" A, p), determine
the mean value, standard deviation, and the probability associated with every combination of flow chart
entrance and exit; there is after all, no need to restrict
ourselves to programs that have only a single entrance
and exit-that would not be realistic.
DECISIONS
Figure l-Basic program elements
sequence of instructions, a subroutine, or a whole
program, depending upon what level we do our analysis.
Having gone this far, we can introduce a further
generalization into the model. Rather than assuming
that the execution time for a link is fixed, we can assume that it is really the mean value of a distribution
of running times for the link. We can characterize that
distribution by its mean value (p,) and standard deviation (u). In practice, we shall find it more convenient
to use the variance (A = ( 2) rather than the standard
deviation. The resulting model is shown in Figure 3.
Figure 3-Final model
Analytical Techniques
521
Before we do this, however, it pays to go into the
question of how we obtain these numbers.
ESTIMATION
The running times for individual links are obtained
by an estimated count of the instructions in that link.
This can be done precisely. without programming. The
real program must run, but its estimated version need
not. We need not take the meticulous care that is
mandatory for a real program. Furthermore, since
almost all instructions are equivalent, we can replace
the real instructions by estimators of these instructions.
For most problems, the repertoire can be cut down to
about 10 different generic instruction types. Similarly
in indexing and indirect operations, we need not be
concerned with which index register is used, and so
forth.
The standard deviation is either externally supplied
or it results from an intermediate step in the analysis.
In most computers, the variation in the running time
of individual instructions is small and can be ignored.
The difficult part of the analysis is the evaluation
of the probabilities associated with the links. Some of
these probabilities are externally supplied-that is,
they are inherent in the job mix for which the program
is written. How these are estimated depends upon the
application. Many other probabilities, while difficult
to estimate can be ignored. Consider the example
shown in Figure 4. We have shown a decision which is
followed by two radically different processes that take
almost the same amount of time. It is clear that the
probability in question is not important. Therefore, a
crude estimate will suffice. The third type of probabilities are those which are inherent in the structure of the
program. Thus, switches which are set on the first pass
through the program and reset on the next pass, the
number of times a program will go through a certain
loop, etc., fall into this category. These are also readily
obtained. Our pragmatic experience has been that
about half of the probabilities are data dependent and
IJ nk
\..L
kn
Figure 5-Series case
Figure 4-Non-critical probabilities
readily obtained, 20 percent are non-critical, 25 percent
are readily obtained from the structure of the program.
The remaining 5 percent are sweaty and can require
much analysis to obtain. However, since the analytical
technique is fast, we can by parametrically examining
values of these difficult probabilities, find out if they
are indeed critical.
522
Fall Joint Computer Conference, 1970
I
lJ ik
Figure 6. The equations are:
Pik=Pik' +Pik"
/Jik = (P ik' /Jik' +P ik" /Jik") / (P ik' +P ik")
Aik = (P ik'Aik' +P ik"Aik") / (P ik' +P ik") +
(/Jik'2P ik' +/Jik"2P ik") / (P ik' +P ik") - /Jik2
The transformations for the loop is shown in Figure
7. The. equations are:
Pik=P ik' / (l-P ii )
/Jik = /Jik' +PU/Jii/ (1- P ii )
Aik = Aik' + AiiP ii/ (l-P ii ) +/Jii2P ii/ (1- P ii )2
The algorithm proceeds as follows:
1. Select a node for removal-other than an entrance or an exit.
2. Apply the series equations to eliminate the
node. This creates new links.
3. Combine parallel links into a single equivalent
link by using the parallel equations.
U,ik'
Figure 6-Parallel case
ANALYSIS
The analytical technique is a step-by-step node
elimination based on what is sometimes called the
"star-mesh transformation." We shall eliminate a
node, and its associated incident and exident links and
replace every combination of incident and exident link
with equivalent links that bypass that node. There are
three cases of importance-links in series, links in
parallel, and loops. The situations for the series case is
shown in Figure 5. The transformation equations for
the series case are: 1
P ij = PikPkj
The transformation for the parallel case is shown in
Figure 7-Loop case
Analytical Techniques
523
4. Eliminate loops.
5. Repeat until only entrances and exits remain.
For manual calculations it is best to represent. the
flow chart by a matrix. The outmost column and row
of the matrix is removed, reducing its rank. We have
written a program that performs these calculations, a
sample of which is shown in Figure 8. We have here a
rather complicated model if we take into account all
the possible loops and such. The links are described
by the names of the nodes they span. The node names
can correspond to the labels in the original flow chart.
The special nodes "GILA" and "ZEND" are included
as programming conveniences. The output shown has
the expected probability of 1 and a mean value of 2263
Figure 9-Multi-inway, multi-outwayexample
INPUT
CODE
I
e
.
..
INWA
3
LINK
5
6
7
S
9
I.
..
...
II
12
13
I ..
15
16
17
..
OUTW
ENDL
ANODE
BNODE
GILA.
GILA.
GILA.
NI
01
Nl
N2
N3
01
N2
N3
02
N..
N3
03
N2
0 ..
NS
N..
ZEND.
ZEND.
.
N2
02
N3
03
D~
N4
N5
PROBABILITY
.9.
•• 5
8 •• 5......
I •••••••••
.e
•• 8 .......
MEAN
• •• e......
••••••••••
9 ••e......
..........
...,.•..... ..........
I .........
~'2
e••••••••
I ••• e.e •••
.6
..........
• I
37.
•• ' ••8 . . . .
173.
931.
86~
I ...
115.
9 ...
••••••• 8 ••
I .........
1.........
..6.
• ••••• e...
CONTROL
DIST.
01 ST •
D15T.
DIST.
DIST•
DIST.
DIST.
DIST •
DIST •
D15T.
D15T.
DIST.
DIST.
DIST.
DIST.
DIST.
OUTPUT
Figure 8-Single inway-single outway example
SEQ.
CODE
ANODE
BNODE
I
INWA
INWA
INWA
LINK
LINK
LINK
LINK
LINK
GILA
GILA
GILA
NI
NI
NI
2
3
.
5
INPUT
SEQ.
CODE
2
.35
INWA
LINK
"
ANODE
GILA.
NI
0"
.
03
6
7
8
N5
N3
9
I.
II
N"
12
01
13
I ..
15
..
02
OUTW
ENDL
.
Ne
BNODE
6
7
8
MEM
PR08ABILITY
1.........
1.........
.33
•• 67 ......
.6.
Ni
0"
03
N..
N5
N3
NI
N"
02
N2
01
N3
N5
ZEND.
....
1•••••••••
1. . . . . . . . .
I .........
.88
•• '2 ••••••
.5
•• 5.......
I.e.......
..........
...
..........
••••H ....
46.
I ....
18.
..........
..........
88.
•••e ......
I ...
.17
68.
CONTROL
DIST.
DIST.
01 ST.
DIST •
DIST.
DIST.
DIST •
DIST.
DIST.
DIST.
DIST.
DIST.
DIST.
DIST.
END OF LINK ENTRIES
CREATE THE FILE NANE WHERE THE
INPUT IS TO BE SAVED.
,- A39
OUTPUT
I
2
3
CODE
ANODE
BNODE
INWA
LINK
OUTW
GILA
NI
NI
N2
N2
~£ND
PROBABILITY
1.8"""8"
I •• """."
1."""888
MEAN
e."ee"
e."88"
8.2263£+"'"
CONTROL
DIST.
D15T.
DIST.
9
1.
II
t2
LINK
LINK
OUTW
OUTW
N2
He
N3
N3
N3
N..
N5
He
N3
He
N3
N3
N..
N2
N..
NS
iEND
lEND
PROBABILITY
MEAN
8.'8888"
8.85.888
8.85"888
8.28"888
8.8"88
".8"""
".37""E+82
8~88""8"
8.888888
..92e""8
'.688.88
..368888
......8 ••
I ••"."."
l.e•••88
".0"8"
jit·~78"[+82
8.2598[+83
8 .1184[+"4
8.1298[+83
8.1548£+83
..1888[+83
".8"8"
8.""8"
CONTROL
DIST.
DIST.
DIST •
DIST.
DIST.
DIST.
DIST.
DIST.
DIST.
DIST.
DI5T.
DIST.
microseconds. Another example, involving a subroutine
with three entrances and two exits yields a somewhat
more complicated result and is shown in Figure 9.
The transformation equations can be derived on the
basis of very weak assumptions. We assume a Markov
model. We assume further that the running time for a
link does not depend upon the running time of other
links. The only thing that has to be assumed about the
distributions representing a link is that they exist and
have a first and second moment.! Other than that, the
equations are valid for any distribution. There are
additional refinements to the process to distinguish
between deterministic and probabilistic loops that will
not be discussed here. Furthermore, the analytical
method is also applicable to the determination of
memory utilization and channel utilization.
To gauge the efficiency of the procedure; a 100 link
program requires less than two seconds of 360/50
524
Fall Joint Computer Conference, 1970
time. The running time of a 1000 link analysis is under
10 seconds.
REFERENCES
The algorithms described here were first developed by
the author in 1964. The assumptions, however, were
overly strong-i.e., required that all link distributions
be Gaussian. A more formal derivation based on weak
assumptions (i.e., the distribution exists and have first
and second moments) is to be found in References 1,2,
as well as a more detailed discussion of non-Markov
models in which the node probability depends on the
previous history of the program. It is shown there that
while the mean value is not affected by these assumptions, the standard deviation is. The algorithm as
programmed, is accordingly modified. We have only
presented the variance equations for the Markovian
case. These equations can be readily shown to yield an
upper bound for the variance.
1 P WARMS JR
Derivation and verification of system 6403 mathematical
formulas
Data Systems Analysts Inc 503-TR-3 December 15 1969
2 PW ARMS JR
Forthcoming MS thesis in computer and information science
University of Pennsylvania
3 W FELLER
An introduction to probability theory and its applications
John Wiley & Sons Inc Volume II Chapter XIV 1966
4 B BElZER
Application manual, system 6403
Data Systems Analysts Inc 503-TR-2 August 22 1969
5 P WARMS JR
Instruction manual, system 6403
Data Systems Analysts Inc 503-TR-1 August 22 1969
6 S E ELMAGHRABY
An algebra for the analysis of generalized activity networks
Management Science Volume lO Number 3 April 1964
This paper represents a parallel development in a more
general area. Elmaghraby treats the generalized network.
It will be seen that the network treated here is his EXCLUSIVE-OR case.
Instrumenting computer systems and their programs*
by B. BUSSELL
UCLA Computer Science Department
Los Angeles, California
and
R. A. KOSTER
North American Rockwell Information Systems Company
Anaheim, California
an operating program to about 2 microseconds accuracy
using only an 8 MHz clock.
INTRODUCTION
Considering the high cost and sophistication of data
processing equipment, it is almost incredible that
techniques for computer system measurement and
evaluation have lagged so far behind. While it is true
that computer technology has advanced at a rapid rate
during the past 20 years, it is surprising that instrumentation for displaying system efficiency has only recently
been given exposure in the literature; and even that
literature is sparse.
This paper will discuss some recent research in
measurement carried on in the UCLA computer
instrumentation project. The project proposed by
Estrin et al., at the 1967 Spring Joint Computer
Conference, was to develop measurement tools and
techniques for the purpose of evaluation of hardware
and software systems, instead of the historically
dominant purpose of measurement for fault location and
prediction. The two tools described here have been
developed for low level self-measurement, requiring no
special hardware.
One tool is an efficient self-simulator that closely
duplicates the operation of the machine it is running on.
It can be probed at the subinstruction level by a data
collection routine to determine detailed characteristics
of the programs running on it. A simulator and two data
collection routines for this simulator are described.
The other tool is the implementation of an algorithm
for making high precision measurements of the time
duration of events or activities in the computer. This
instrument measures the time interval of an activity in
BACKGROUND
One generally makes measurements on a computer
system in order to evaluate it. The evaluation may be
for the purpose of acquiring a new system, optimizing
an existing system configuration or, perhaps, for
specifying an improved system. The measurement may
be made on the system itself or on some simulation
model of the system. The input for the measurement
may be real data or a model of the data, e.g., statistical
data. It is to be expected that the most accurate
information is derived from measurements made on the
actual system, using real data.
Measurements may be made on resource utilization,
be it memory space, peripherals or busses. Measurement
may be made of computation time, event statistics or
program structure. The choice of the measurement must
be determined by the specific objective.
Each instrumentation for measurement is expected to
introduce artifact; either space, time, program structure
modification or event statistics. A measure of the
quality of an instrumentation is determined from both
the artifact that it introduces and how well the artifact
can be separated from the actual measurement in the
final evaluation.
Since most of the total running time involved
arithmetic operations, early evaluations were based on
the time to perform addition or "add time." If more
involved arithmetic operations were available as primitive instructions, e.g., multiply, divide-these times
were similarly considered in system comparisons. Input
* This research was sponsored by the Atomic Energy Commission [AT(1l-1) Gen 10 Project 14].
525
526
Fall Joint Computer Conference, 1970
and output times were ignored in computing the run
time of a problem and only the actual computing or
central processing unit (CPU) time was considered.
As more general· purpose applications evolved, costs
for commercial users became more important. The job
profile for a commercial use is generally one which has
large volumes of data to be fed to the system; movement
of the data within the system for sorting, merging or
extracting pertinent records of files; and finally, output
of these updated records or files. Since most of the
activity involved peripheral equipment, and since the
input and output time was so long compared to the
actual computing time, performance measures were
generally determined for I/O equipment only. Thus the
familiar criteria of "cards per minute," "lines per
minute" and "characters per second" became the
performance parameters in a commercial computational
environment.
These early evaluation procedures can be classified as
extremely crude data models applied to a crude. system
simulation.
Refinements in both the data and system models
were made by including additional instructions, and
broader classes of operations specific to particular users.
For example, instruction-mix statistics have been
gathered for scientific computations and for commercial
users. These statistics are generally grouped into instruction classes, and weights are assigned to the classes
dependent upon the frequency of occurrence as measured
in large groups of programs. Examples of mixes can be
found in Arbuckle! and Smith. 2 The mixes are used to
compare computational efficiency between machines.
For each operation, the manufacturer's listed operation
speed is multiplied by the particular weight factor.
A sum of all the products produces a "figure of merit"
for comparison purposes. It must be noted that mix
evaluations are only generally a measure of the speed of
the logic hardware, instruction set.
Other major factors affecting computational efficiency
are usually not considered by mix evaluation: special
instructions in a particular machine may not be included
in the mix; multiple registers with multiple uses,
hierarchical memory, and parallel arithmetic units are
among special features not usually considered by mixes;
mixes are usually developed for the "average" user in
some class; some users are not well represented by any
average mix.
A refinement over the mix-statistics measure has been
the kernel evaluation. In this exercise, small sample
routines are coded for each machine under comparison.
For scientific users problems such as solving two
simultaneous equations in two unknowns, or evaluating
a polynomial are typical. Commercial application
kernels might be formatting output lines or searching a
table for prescribed descriptors. In addition to comparison of computation times, this method may display
special features or instructions which are useful (or
hindering) in each machine under investigation. A great
shortcoming of this method is that it depends greatly
upon the experience and skill of the programmer with
the particular machine.
Probably the best procedure for comparing systems is
to program all of a user's jobs on all of the machines
being considered. However, this not being practical,
users have attempted to define small portions of typical
work loads in order to run them on different machines.
These problems are called "benchmark problems" and,
of all of the procedures discussed so far, provide the best
data and come closest to predicting a Hbest" system for
a particular need. This is true not only because of the
better data, but also because of our inability to generate
accurate models of today's complex computer systems.
The above described measurement and evaluation
procedures were all designed to compare existing systems
for possible acquisition. With the advent of parallel
processing capabilities, time sharing of resources,
multiprocessing, and the inclusion of an increasing
number of system functions, t\eearlier, cruder methods
of measurement yielded increasingly poorer evaluations.
Other measurement procedures were developed.
First to come upon the scene were channel analyzers.
These hardware monitors essentially made measurements on the use of data channels and peripheral
equipment from which it is possible to calculate the
amount of overlap between the central processing unit
and peripherals. Their prime use was in reconfiguring a
system to increase efficiency. A later application of a
similar device built by one of the large computer
manufacturers was to demonstrate to potential customers the increased efficiency of a new product when
running the customers' jobs. Recently complex hardware
monitors have been described by Schulman 3 and
Estrin. 4 Schulman's monitor can attach information in
up to 48 signals which describe a maximum of 48
measurable parameters. Through suitable choice of
connections significant measurements of system operation can be made during the running of a problem. A less
sophisticated version has also been built and at least one
manufacturer is marketing a small hardware monitor of
this type for general application. Estrin's proposed
monitor has, as one of its major variances with other
systems, the requirement that the measuring device
have the ability to control or interfere with ongoing
computations in the object computer system. The
purpose of this interference is twofold. First, to be able
to capture all essential data by slowing the object
computer if the data is being made available too quickly
for retention. Second, when simultaneous analysis of the
'Instrumenting Computer Systems and their Programs
data indicates more optimal program structure or
resource allocation, the measurement system should be
capable of making (or initiating) these alterations.
As a first step toward this ultimate goal, software
tools were developed to facilitate the collection of data
for post-processing. The particular instrumentation to
be described in this paper makes .measurements of both
instruction use and event timing in an ongoing computation in its normal environment in a computer.
INSTRUCTION UTILIZATION
The instrumentation program for measurement of
instruction utilization consists of two parts: a data
gathering routine, and a control and simulation routine
that can be used with many different data gathering
OPCODE
-SUBJECT
INSTRUCTION
EXECUTE (EXU)
ALL BRANCH TYPES
EXECUTE
BRANCH - TYPES
INTERPR ETIYEL Y
RESTORE
OBJECT REG.
• CONQCODE
EXECUTE
OBJECT
INSTRUCTION
(EXU INA)
SAYE
OBJECT REG
• CONQ.CODE
INSTRUMENTATION
CONTROL
'UNCTIONS
INANA
(!:!EW ~DDRESS)
INAINA +1
Figure t--8igma-7 self simulator flowchart
527
routines. The data gathering routine collects instruction
mix statistics. The control and simulation routine
simulates the object computer on itself, providing a
means for data to be collected for each instruction
cycle. It is important that nearly every program that
would run on the uninstrumented object computer be
able to run identically on the simulator. This means that
the instrumentation must occupy minimal space and be
able to retain control in spite of error, interrupt, or
other conditions which may arise from the object
program. It is also desirable, for economic reasons, that
the simulator operate as fast as possible.
The central element in the simulator is the Execute
instruction of both the Sigma-7 and IBM/360 instruction sets. 5 ,6 It causes the instruction residing at its
operand address to be executed. In the main simulation
loop the object program environment, its register and
condition code values, are saved after and restored
before the EXU instruction (Figure 1). The operand
address of the EXU is incremented and' the operation
code of the next object instruction is examined before
executing it. If the object instruction can change the
sequence of execution, e.g., a branch instruction, it
would cause the simulator to lose control if executed in
the main loop. Therefore it is executed interpretively
by other routines.
The data collection routine maintains a counter for
each operation code that can occur in the object
computer. Before executing each instruction, its counter
is incremented. Additional counters for the conditional
branch instructions record, for each condition tested,
whether or not the branch actually occurred.
The dominant elements contributing to the time
artifact are proportional to the number of instructions
executed under simulation, so relative artifact is usually
more interesting to the user. A statement about relative
artifact must assume an average execution time for
instructions in the object program (running normally,
without simulation), which is heavily dependent upon
its instruction mix. Register-to-register operations in
the 360/75, for example, typically take about 0.5 jJsec
less than their register-to-storage equivalents. In the
Sigma-7 the register-to-register operations typically
take 1.5 jJsec more than their register-to-storage
equivalents. Analysis of a small sample of programs
written in assembly language by one of the authors
indicates an average executio~ time of about 1.1 jJsec
for the 360/75 and about 2.2 jJsec for the Sigma-7.
Neither sample included any floating point or decimal
operations and the author is not necessarily a "typical"
coder, so no attempt will be made to defend these
numbers as applicable to the general case.
Using the listed "book" values of instruction times it
was determined that the ratio of simulator time to book
528
Fall Joint Computer Conference, 1970
A.
SIGMA-7 SIMULATOR ARTIFACT
Natural
Time
Mnemonic
jArtifact
main loop
18.6
2.2 (av.) 8.2
BCS/BCR(b)
41.8
1.0-2.1
BCSIBCR(nb
39.8
1. 9 -3.0
21-13 (no branch)
BIR/BDR(b)
41.8
1.5-2.3
Ratio
Instruction (comment)
all not named below
42-20 Branch on Condition Set/Reset
BIR/BDR(nb)
39.8
2.4-3.3
28-18 Branch on Increment/Decrement Reg.
17 -12 (n:> branch)
BAL
47.4
2.2 -2.8
22 -17 Branch and Link
EXU
31.0
1. 2-2. 4
26 -13 Execute (add subject instr.
time)
B.
Mnemonic
SYSTEM/360 - 75 SIMULATOR ARTIFACT
Artifact
Natural
Time
Ratio
Instruction (comment)
41
all not named below
Branch on Condition (RX type)
45.0
1.1 (av.)
BC(b)
36.1
1.0
36
BCR(b)
28.2
1.0
28
Branch on Condition (RR type)
BC/BCR(nb)
15.5
1.0
16
(no branch)
BCT /BCTR(b)
41.6/33.7
1.0
42/34
Branch on Count (RX/RR types)
BCT /BCTR(nb)
21.0
1.0
21
(no branch)
main loop
BXH/BXLE(b)
45.3/37.4
1.1
41/34
Branch on Index High/Low-Equal
BXH/BXLE(nb)
24.7
1.1
22
(no branch)
BAL/BALR
26.6/26.8
1.0
27
Branch And Link (RX/RR types)
LM/STM
24.0 + 1. 6r
1. 4 + .26r
17 + 6r
Load/store Multiple
(r = no. of registers)
EX
28.5
3.2
9
Execute (add subject lnstr. time)
Figure 2-Simulator artifact
time for the Sigma-7 instruction repertoire ranged from
about 8:1 for main loop instructions to 20:1 (on the
average) for branch type instructions (See Figure 2).
Since monitor functions, including I/O, are normally
not executed under simulation, it is to be expected that
the average artifact is lower.
The control routines allow insertion of calls in the
object program to command the instrumentation to
turn on or off or output its data through three Fortran
CALL routines or assembly language branch and link
instructions which turn on the instrumentation
(INSTON), turn off the instrumentation (INSTOFF),
or close the instrumentation and output the data
(INSTCLOS). A call to INSTON starts executing the
object program under simulation at the next instruction.
A call to INSTOFF returns direct control to the object
program but retains any data collected· so that a later
call to INSTON continues the accumulation of data.
A call in INSTCLOS outputs and clears the data tables
before doing the INSTOFF function. The INSTON,
INSTOFF pair can be used to instrument a subroutine
or a portion of a program. Since the object program runs
at natural speed when the instrumentation is closed or
off this kind of control permits significant reduction of
artifact.
The infrequency with which calls are made to the
control routines causes their relative contribution to
overall artifact to be small. INSTON costs about 50
instructions, depending upon arguments it must handle,
plus about 50 more if the monitor call is used. INSTOFF
costs about 20 instructions plus 50 if the monitor call is
used. INSTOUT is about as expensive as INSTOFF
plus the cost of the data output routines, which in most
cases will totally dominate it. The first call to INSTON
performs a number of once-only initializing functions
that cost about 500 instructions.
Artifact due to the simulation routines is shown in
Figure 2. The Natural Time column gives the manufacturer's published times for the instruction explicitly
named and the assumed average time for fixed-point
binary and logical instructions executed in the main loop
of the simulator. The Ratio columns are a measure of the
relative artifact, the artifact divided by the natural
time. The average Natural Time in the first lines will be
greater, and the Ratio less, in programs having a
significant number of floating point or decimal instructions or in programs compiled by a non-optimizing
compiler. The range of natural times in Figure 2A
assumes no indexing. Add 0.6 to the artifact for only the
branch instructions if they are indexed in the Sigma-7.
Figure 2B assumes single indexing; e.g., a nonzero base
register field, in the artifact column. Add 2.1 JLsec to the
artifact for RX type instructions if both the base and
index register fields are nonzero and subtract 2.1 JLsec
if they are both zero.
The most important general conclusion that can be
drawn from Figure 2 is that the Execute instruction is a
definite aid to simulation in the Sigma-7 but, at least as
implemented, it is not much help, from a time stand-point, in the 360. In most cases, in fact, the instructions
can be executed interpretively a little faster than they
can in the main loop. To gain this speed advantage,
however, it is necessary to treat practically each
instruction as a special case, making the space artifact
very large. A related observation is the fact that the
EXU instruction in the Sigma-7 adds less than one Add
time to its subject instruction whereas the EX instruction in the 360 adds more than three Add times to its
subject instruction.
For many experiments it is desirable for the simulator to regain control automatically after an interrupt
has given control to the operating system. In most cases
this· will happen automatically except when the return
to the user program is to a point other than that at
which the interrupt occurred (as in the implementation
of a PL/I "ON" condition). Explicit INSTON
commands can be put in all such entries, but that is an
error-prone operation for the experimenter. It is also
desirable to have an end of job condition, particularly
an unplanned one, cause an implicit INSTCLOS function so that the data gathered so far can be recovered.
Instrumenting Computer Systems and their Programs
529
These goals were accomplished in the Sigma-7 monitor
by adding only 25 words to it. It was estimated that a
change of similar magnitude would be required on
OS/360. They involve the use of a previously unassigned
CALL (SVC) instruction to set a flag in the monitor
that indicates that the instrumentation system is
present. The flag can be explicitly reset and is automatically reset by the end-of-job processor. The routine
that gets the address for a non-sequential return and the
end-of-job processor check the flag and return instead
to an address (in the flag word) that gives control back
to the simulator it the flag is nonzero. The address that
the monitor would have returned to or the fact that an
end-of-job condition has occurred is passed to the
simulator entry routine so it can take appropriate
action.
The object program
In order to test the above described instrumentation
software, an elementary problem was selected which
utilized the I/O, performed arithmetic and which had a
non-trivial looping structure. The results described
below were obtained from tests run on the XDS
Sigma-7 using the XDS Fortran compiler.
The object program was a short Fortran program
which calculated and printed the amortization table for
a loan (Figure 3). The output consisted of 140 lines of
data and 3 headlines printed on 3 pages. All variables
'FORTRAN
·--------~~n-q~-~N~271~lM~-~,.f~;~~-!~~-;~.I~~~-.-!·t~~yT-~iJUNi~,.iULi;-iAijci.-;-----1..'..5_£P'« • ocJt« • NOy.« • OEC • ,
9AL • __
100000
______ B!oJ.t._!'
6.A ________________________________________ _
PMT
•
0
.. _____
__ l _______________________________________________
_
I'!!L~
VR • 6.
_ _~~T.
"o:-'lQL--------------------
. _______.. f __'!_.P. ____________________________________________________________
~----------
fR • RATE I 10
·~--------~R·i t"~((;;5i-rR;--R4-fE--------------------------------------------------------
L-.£ORI1AT ~J_~~...!.lU_ _'_",..T P~lP--!lJ~.n1_!..ltU.L!LJ..l_'~.!.'_ J.1/_
l'U', TItS, 'PRINCIPAL', T62, 'BALANCE'/' I)
.§____tr__ J.!.. __·_f:.!h·__'.I.L_Gtt_JJt_A.____________________________________._______________ _
.________IPMT • __PHT I __100_______ . __________________________________________________ _
t.J!'!r._~
I~LL
IPR • PR I
[B~L L. +B~L
~9_O'
100
I
lQ.OIL.--:............_ _ _ _ _ _ __
.1IL ____ J~!UJ(J6,j.U_!1I1N.H.t~Old.R,.IJ?!1_t,.P.rll,.lI~T'
I"I.T,JP.~,PH,
!IIAL,flM.. __ . ___.
., A3, '.1,19,,12,
TlIt,
_Cl6, ..',',12,
6X)J
•11
_____ F'ORMA.T I' _______________
_____________
.. ___________
__ .________________________
.
.P-!:tt._~_6.0.0.0
~
INT. IBAL • RAt£ I
12 • 500) I
1000
--~~Z~L~·.~P~~~~~------------
•______J:lCL!'__tl.fl.D.V':1!l1..12J.._t__ l. ____________________________________________________ .. _____..
13
IF' 11':9 .NE. 11 G' Tit 15
.1!1____ :(!.t_!'__Y.!L±.~.l------- ..------------------------___________________________________ _
15
IF' (SAL .GT. 01 G9 TO 6
.l.L-£MT , PMT • SAL
• ·_'O'
PR _______________________________________________________
+ BAL
____PR __
.__________ .._______ _
Figure 4-Mix statistics for object program
were integer variables, so there were no floating point
operations attempted. Scaling and rounding were done
explicitly and the output was formatted with the
months spelled out.
The obJect program was instrumented as a whole and,
in order to test the facilities of the instrumentation
system, in parts. The latter was accomplished by turning the instrumentation on and off, in order to focus the
instrumentation on program sections of interest.
Additionally one measurement was made by turning the
system on, off, and closing it when the calculations
reached January of a specified year. This was done by
inserting statements of the form IF(YR. EQ. 67) CALL
INSTCLOS before statement 15.
Despite the simple nature of this test program,
experiments described below reveal a good deal about
the instrumentation process of its potential.
~lo_I,,
I __• J_L_·_L1.!_..2J.._Q.II
I • 1
_____tf
__ __ L _____________________________________________ .. _. _____.
t~
WRITEI6,20J
EXPERIMENTS WITH THE OBJECT PROGRAM
~IlRMAT "1'1
ST9P
--------~~~_Q_--------------------------------------------------------_ . _-----_ ... ------_.
Figure 3-0bject program for instrumentation
Instruction mix statistics
The object program described above was run fully
instrumented in order to provide a base for further
530
Fall Joint Computer Conference, 1970
experiments, by totalling the number of executed
instructions and by displaying the instruction mix
compiled for this Fortran program. Figure 4 displays
the mix statistics from printout. An examination of this
instruction mix indicates that byte instructions are used
in compiling the formatted output in preference to byte
string instructions. As a test on this hypothesis, a
program was rerun with all WRITE instructions
disabled. The mix statistics verified the hypothesis-no
byte instructions were used. Additionally the total
number of instructions used in the latter program was
10,900 (without WRITE instructions) compared to
922,041 for the full program-revealing that approximately 911,000 instructions were used for formatting
the printing 143 lines. The program was rerun with
different groups of the three WRITE statements
suppressed and measurements showed that the headline
statement required 5,285 instructions, data printout
required (on the average) 6,383 instructions while the
page skip control statement required 1,661 instructions.
As a test to see whether or not the method of
formatting determined that the compiler used byte
string instructions, the FORMAT statements were
rewritten using Hollerith format (xH ... ,) and run
with the data printout and page skip suppressed. Again
the mix statistics showed that these instructions were
not used. Further investigation revealed that the
compiler had been written to be usable by a smaller
system without byte-string manipulation capability.
Program debugging
A debugging aid that was temporarily put into the
original simulator has proven so useful that it provides
the basis for a separate data collection program. This
program records in a circular queue the instruction
address, operand address, instruction, and operand for
each instruction executed. A queue capacity of fifty
instructions appears adequate, but a larger capacity is
easily possible. The space required by this program is
about 700 words including its data. An instruction
being simulated runs about 25 times slower than it
would normally. When a program presents a difficult
debugging problem, this routine can be loaded with it
and turned on just prior to the suspected problem areas.
Intermediate and/or terminal (object program fatality)
data dumps can be produced. Turning the simulator off
during execution ot debugged portions of the object
program can reduce average artifact to reasonable levels
even for long programs.
EVENT AND INSTRUCTION TIlVIING
Program accesible clocks in present day computing
systems are included primarily for accounting purposes.
Instruction and event timing require clock resolution
which is several orders of magnitude finer·than that for
billing purposes. I t is possible, however, to develop
algorithms which can "see through" a low resolution
process to the more accurate standard behind it. In this
algorithm it is the timing precision of the individual
"ticks" of the clock, not the time between them (clock
resolution) that limits the accuracy of measurement.
Its principle of operation is analogous to that of a
vernier scale which proportionally divides the space
between marks on a scale to permit a much higher
measurement accuracy than would be indicated by the
resolution of that scale. It is this type of vernier timing
algorithm which has been implemented as a subroutine
in the set of instrumentation programs.
The TIME Subroutine measures the actual elapsed
time of events within a user program to an accuracy of
about two microseconds. It uses an 8 1\1Hz clock in the
XDS Sigma-7 computer. It is fully compatible with
Fortran and system protocol. The space and time
artifact introduced is about 270 memory cells and an
average of between 220 and 300 microseconds in most
applications.
The TIME Subroutine has two entries, $TIMON
and $TIME. A call to $TIME is normally used to start
the timer. A call to $TIl\1E is normally used to obtain
the time (in 74: microsecond units) since the most recent
return from TIl\1E. Optional arguments passed with
the calls can be used to control auxiliary functions of the
subroutine. These functions include calibration and
hardware clock control.
The vernier clock algorithm has four basic hardware
requirements: there must be (1) an accurate hardware
clock, (2) minimal jitter, and (3) a very short program
loop whose time is (4) accurately known and which can
detect when the clock is incremented. The discussion
of error analysis will show how each of these requirements enters into the determination of the accuracy of
the vernier clock. In some systems (e.g., the XDS
Sigma-7 computer) some of the critical times are
dependent upon maintenance adjustments, temperature, and other factors that make long term calibration
of the timing routine hard to maintain. An analysis of
calibration procedure will show that the presence of two
clocks makes self-calibration practical. Systems without
a second clock may require occasional manual calibration with the aid of special hardware. Simple practical
procedures involving attachment of an oscilloscope to a
convenient point in the machine while a calibration
routine is running and adjustments of a precision
oscillator can be developed for most machines.
In some software systems access to the hardware
clock by a user program involves high and frequently
variable overhead. These effects act like additional clock
Instrumenting Computer Systems and their Programs
jitter and program loop time and may have a fatal effect
on the utility of an algorithm to a user. Since the core
of the algorithm can be programmed in less than 50
cells, it may be reasonable to make it a resident part
of the system programs in some systems. It could then
have direct access to the hardware clock. The control,
calculation and calibration sections which would link to
the core would then be brought in when needed as user
or utility programs.
The XDS Sigma-7 computer has two interrupt cells
associated with each clock, the count interrupt and the
zero inter~upt. If an interrupt cell contains the Modify
And Test Word (MTW) instruction when that interrupt
is activated (advanced to the active state), that
instruction is executed and the interrupt is immediately
cleared without changing the rest of the machine's state.
Unless there are other interrupts waiting, control is
immediately returned to the interrupt program. The
MTW instruction increments the word at its target
address by a specified amount between - 8 and 7 and
tests the result for "less than," "greater than," or
"equal to" zero. If the MTW is in the clock count
interrupt cell and the result is zero, the clock zero
interrupt is triggered (advanced to the waiting state if
armed and enabled).
The fast clock triggers the count interrupt every 125
microseconds .. This action will be called the· tick of the
clock. Its timing is dependent upon a crystal oscillator
which is probably stable to at least .01 percent. The
interrupt will be activated when the currently executing
instruction is complete. A similar slow clock triggers its
count interrupt every 2 milliseconds at exactly the same
time as every sixteenth fast clock trigger. Since the
fast clock has higher priority, it will activate first. The
time required for instruction execution in the Sigma-7
has been observed to differ from nominal values by
10 percent and from one cell to another, for the same
instruction, by 1.2 percent. Short time (a few hours)
stability for a fixed instruction in a fixed cell is better
than 0.02 percent. No nominal value is given in the
manuals for time to execute the interrupt and the
MTW, but tests indicate a value of 6.0 p,sec with drift
and short-term stability similar to that for other
instructions.
We can observe the content of a cell that is incremented by the clock before and after an event and
calculate the number of whole 125 p,sec intervals that
elapsed during the event. IVlultiplying this by 199
(125 minus the 6 p,sec required for the interrupt) gives
the time of an event ± 199 p,sec. The error is due to the
fact that we do not know what part of the first and last
intervals were occupied by the event. What is needed is
a "vernier" timer that can divide the clock intervals
531
r-----GET TIMER COUNT
IN "TI_" (111)
------------------SET UP CLOCK CELLS
r-O, t - - I
2ND VERNIER
LOOP
+
PUT RESULTS IN
r--- ------------,
I
I
I
OBJECT EVENT BEING
TIMED. CLOCK TICKS
:
m TIMES.
I
I
ARGUMENT OF
SUBROUTINE CALL
I
:
IL _____________
I"TlME"-I"TIME")+ m ,) __
I'-
:
~
___ . . . ..JI
Figure 5-Time subroutine flowchart
into many small parts and estimate the number of those
parts occupied by the object event.
The algorithm that makes the vernier measurement
is shown in Figure 5. After performing the requested
control functions (not shown in the flow chart), the
object program's call to $TIMON results in the entry
at START TIMER. After setting up the clock cells, the
program enters a loop that cycles until the clock ticks.
The loop is a single instruction that would infinitely
branch to itself except that it is the object of the MTW
in the clock interrupt. cell. The clock tick causes the
branch to go to the following instruction within one
branch instruction time. When a tick is detected, control
is returned to the object program event that is to be
timed. The part of the first interval that is occupied by
the object event is now known to a tolerance of the time
it takes for one vernier loop. If the number of times
through the vernier loop, (n) is one, the timing may be
invalid so the timer starts again.
The object event is executed and the object program
calls $TIME. After setting up the clock cells and
recording the count of the number of times the clock
ticked during the event (m), a second vernier loop is
532
Fall Joint Computer Conference, 1970
entered. This loop counts the number of times it cycles
until the next tick (n) (the BDR, Branch and Decrement Register, instruction is used for the loop to count
cycles). The part of the last interval that is not occupied
by the object event can now be calculated to a tolerance
of the time of one of the second vernier cycles. With this
information, the time spent in the object event can be
calculated.
Knowing m, the number of clock ticks, and n, the
number of vernier cycles in the second loop, the time can
be calculated by
T=K 1m-K2n+K3
where KI, K2 and K3 are functions of the time and
resolution of the vernier loop, the system clock tick, and
the system overhead. Variations in the timing in the
hardware require that each of the K's be determined
experimentally by a calibration routine. However,
nominal values for these constants were, in microseconds,
Kl=119
K 2 =1.5
89.2±1.5 for
K3=
{
was 5001 + 500B, where 1 is the execution time for the
test instruction and B is the execution time for the null
operation. The same 1000 cells were then all filled with
the null operation and the sequence executed again,
giving 1000B. The value of 1 was calculated, converted
to microseconds, and printed. The first eleven bytes of
the input card image were printed to the left of 1 and
the comment field was printed to its right.
A sample output is illustrated in Figure 6 showing
timing measurements made to validate manufacturer's
book values for instruction times.
Column A gives the octal operation code whose
mnemonics are in column 1. Column B indicates indirect
addressing if an asterisk is present. Column C describes
an even address (if 0) or an odd address (if 1) corresponding to column J. If the instruction is not
indirectly addressed, this corresponds to the effective
address of the instruction. If indirectly addressed, this
corresponds to the location of the cell pointed to by the
address field of the instruction. Column D indicates
indexing if set to 1. Column E describes whether the
original instruction address is even if 0, or odd if 1, as
indicated in column H. If the instruction is indirectly
n> 1
89.75±2.05 for n= 1
Experiments
It is of qualitative interest to consider two simple
experiments that were executed using the above timing
routines. The first measured actual instruction timing
in the computer. The second measured the time range
and average value for real-time routine.
A program was written to construct a table of
instruction times similar to that supplied by the
manufacturer except that, instead of specifying memory
overlap, it explicitly specified the memory banks used
by the instruction. The program was driven by a set of
data cards that specified the instruction combinations
to be tested. This allowed a subset of the table to be
generated or the sequence of entries to be permitted for
particular applications. It also allowed unusual combinations; e.g., indirect address and operand both in a
register, to be tested.
When operated in the normal mode, the Sigma-7
(with 32K memory) uses one memory bank for even
addresses and the other one for odd addresses. The
program set up 500 instruction pairs. The even or odd
one of each pair contained the specified instruction.
The other one in the pair contained a branch to the next
instruction (the fastest null operation available). These
1000 cells were bracketed. by calls to $TIMON and
$TIME.· When this· sequence was executed, the time
~
!!of. Q. §. f.
1t8 -0
~8 -0
~8 -0
~8 -0
~8 -1
~8 -1
~8 -1
48 *1
30 0
30 0
30 1
30 1
30 o
30 o
30 1
30 1
30 -0
30 -0
30 -0
30 -0
30 -1
30 -1
30 -1
30 -1
30 -0
30 -0
30 -0
30 -0
30 -1
30 *1
30 -1
30 *1
66 0
66 0
66 1
66 1
66 o
66 o
66 1
66 1
66 *0
66 *0
66 -0
66 *0
66 _1
66 *1
66 -1
66 -1
1 0 0
1 0 1
1 1 0
1 1 1
100
101
1 1 0
1 1 1
o 0
1. 0
o 0
1 0
100
1 1 0
100
1 1 0
o 0
o 1
1 0
1 1
o 0
o 1
1 0
1 1
1 0 0
1 :) 1
1 1 0
1 1 1
1 0 0
1 o 1
1 1 0
1 1 1
o 0
1 0
o 0
1 0
1 0 0
t 1 0
100
1 1 0
o 0
o 1
1 0
1 1
0
o
0 1
1 0
1 1
§.
!!
3·00
1!.69
2·69
3.0_
3.04
2·73
2.73
3·07
l'SO
l·lt8
1·lt9
1·83
2.lt2
2·11
2.11
2.lt6
2·70
2·39
2·39
2.73
EVEN
EVEN
eDD
eDD
EVEN
EVE;\/
eDD
eOD
EVEN
eoo
EVF.:'l
eOo
EVEN
eDO
EVEN
BOD
EVEN
EVEN
eOD
eoo
EVEN
EVEN
eOD
eOO
EVE;\/
EVEN
eDO
eOD
EVE'I
EVEN
eDO
eM
EVEN
eDD
EVEN
!'lOD
EVEN
eDD
EVEN
eDD
EVEN
EVEN
eDD
eOD
EVE"
EVEN
eDO
eDD
2.H
2.lt3
2·lt3
2.78
3·00
2.69
2.69
3.03
3.03
2.73
2·73
3·07
2.73
2·67
2·72
2·81
3.34t
3·29
3.34
3.lt3
3.61
3.62
3.57
3.70
3·67
3·67
3.61
3.75
!
AND.6
AND,6
AND,6
AND,6
AND,6
AND,6
ANO,6
AND,6
AW,6
A~~,6
AW,6
AI'I,6
A'll, 6
Aw,6
A;.I,6
Aw,6
AII,6
AW.t6
AW,6
AW,6
AW,6
AW,6
AW,6
AW,6
AW,6
A'II,6
Aw,6
AW.t6
AW,6
AW.t6
AW,6
AIII,6
AW"I.t6
AW"l.t6
AW"I.t6
AWM.t6
AWM.t6
AWM,6
AW'1,6
AWM.t6
AW"1.t6
AitlM,6
AWM,6
AWM,6
AW"1,6
AW!'1.t6
AWM,6
AWfo1,6
:!.
-EVEN,1
-EVEN,1
-EVEN,1
-EVE'J,1
-~'D,1
_~DO,l
-e~O,1
-e~!),l
EVE'll
EVEN
!'I DO
~
(1'110 AI)O EVr.N)
(IND A:)D ~DD)
(1'10 A~D EVEN)
(I'ID A!)O eDO)
(1'10 A~O EVEN)
( HID ADD ~!')O)
(1'10 A,)!) EVEN)
(1'10 ADD ~DI)
8'0
EVEN,l
EVEN, 1
~DO,l
eOO,l
-EVE'll
-EVEN
-EVEN
-EVE",
_e:>o
_~')D
-eoo
_~')o
-EVEN,t
_EVE'l,1
-EVEN,1
*EVEN,l
-&:>0,1
-&:>0,1
-&')0,1
*~D".t1
EvEN
EVEN
e:>D
(INO ADO
(1'10 ADO
(1'10 A,)O
(1'10 AOO
(1'10 A')"
(1'10 AOD
( PolO A,)O
(1"10 ADD
(1'10 ADD
cIND ADD
(I"JO A,)O
cIND AOD
(IND A,)O
cI'lD ADD
(1"11) ADO
(IND A"')
EVEN)
el)O)
EVEN)
~!)~)
EVEN)
~""")
EVE"J)
eOO)
EVEN)
~O!»
EVEN)
eOI)
EVEN)
eD")
EVE'l)
~"D)
e'D
EVEN,1
EVEN, 1
eDO,l
eDD,1
*EVEN
-EVEN
*EVEN
-EVEN
_eDD
_~,o
_e!)D
.eDD
(It>olD
(INO
(INO
(IND
(IND
(I'lD
A')D EVEN)
ADD ~OD)
ADD EVr.~l)
ADD eDO)
A')D EVEN)
AnD.
~DD)
(hID ADD EVEN)
(1"'0 ADD
Figure 6-Instruction timing test output
eDO)
Instrumenting Computer Systems and their Programs
addressed then the effective address is even if 0 or odd
if 1 as shown in column K. If the instruction is not
indirectly addressed the field has no meaning. Finally,
column G lists the calculated instruction times in
microseconds. For all runs, the contents of register 1 is
zero.
Results of these tests indicated that most instruction
times were within ±0.10 fJ.sec of the nominal times
published by the manufacturer. The test data for
identical experiments repeated to ±.Ol fJ.sec for four
tests made over a two week period. A few instruction
times, e.g., Branch on Incrementing/Decrementing
Register (BIR/BDR), were as much as .16 fJ.sec less than
nominal under some conditions. The odd memory bank
appeared to be consistently .04 fJ.sec slower than the
even bank for each reference the instruction had to make
when there was no overlap (all references to the same
bank). Comparison of the times for similar instructions
on a condition-by-condition basis showed identical
(±.Ol fJ.sec) times (examples: Add Word/Subtract
Word, BIR/BDR, and Add Word to l\t{emory/Ex~
change Word (both read-modify-write), Load Byte/
Halfword/Word, Store Byte/Halfword (but notWord)).
A three dimensional graphic input device was
developed at UCLA. It is similar in concept but different
in many details from the Lincoln Wand developed by
Roberts at Lincoln Laboratories. 7 The differences stem
from efforts to make it lower in cost, eliminate some of
the difficulties experienced with the M.l. T. wand, and
interface it into the UCLA Sigma-7 computer and
graphics system. It is described in detail by Makranczy.8
The wand is a hand-held pointer containing a
microphone in its tip. Four sonic transmitters are
located in the corners of the graphics area. The associated hardware determines the time it takes sound to
travel between the transmitters and the microphone.
These four times can be used to determine the location
of the wand. The calculation to convert the four times
into X, Y, and Z coordinates could be done either by
special hardware or by the Sigma-7 computations. An
embryonic form of the TIME subroutine was used to
determine the average time required by the software
conversion under simulated tracking conditions. Measurements indicated that 224 (±4) }Lsec were required to
convert one set of data using the software. Since each
set was available only once every 40 milliseconds, the
computational load was less than 0.6 percent of the CPU
time.
CONCLUSIONS
The work described above was concerned with two
nearly independent tools for low level self-measurement
533
in computers; self-simulators and timing programs. In
each case a need was recognized, satisfactory existing
tools were developed to work as well and efficiently as
possible within the environment at UCLA (which is
typical of many large computer user environments).
The methods used are applicable to other environments.
Self-simulation
There is a class of experiments and environments for
which self measurement via simulation is the best tool
available. It has low initial cost, portability, and easy
adaptability to the environment and to varying
experiments, compared with external hardware measurement. It does not involve the system shutdown and
reliability problems frequently associated with attachment of a special hardware. It can instrument a class
of object programs that cannot be statically analyzed.
It can collect a class of low level raw data that is not
available to other software measurement techniques.
Conversely, measurement via simulation introduces,
at best, a rather large speed artifact and a space and
facility limitation which tend to increase the cost of
operation and restrict the range of measurable
systems.
The simulator programs that were described here
have a lower artifact by at least an order of magnitude
and a greater demonstrated adaptability than any other
published simulators.
Timing
While much is said about fast machines, efficient
programs, time-saving algorithms and devices, etc.,
very little has been done to provide the user with a
means to measure the basic element of these statements
-time. Gross time measurement devices are commonly
provided for accounting and control purposes. Microscopic measures such as individual instruction times are
provided. But it is the intermediate range of a few tens
to a few thousands of instruction times that the user
must work with when evaluating, comparing, or improving his programs, algorithms, and operating
systems.
The timing program that was described here provides
a convenient means for timing events in this range to an
accuracy of about one instruction time. When the basic
accuracy of the hardware clock is not good enough its
short-term stability may still be good enough to allow
comparative measurement to the desired precision.
This timing program is practical for a broad class of
534
Fall Joint Computer Conference, 1970
time measurement tasks but it does place some
important restrictions on the environment in which it
can be used and it introduces an artifact that may, in
some cases, be intolerable. A range of hardware
improvements have been suggested9 which would eliminate restrictions and/ or reduce artifact for these
timing functions.
REFERENCES
1 R A ARBUCKLE
Computer analysis and thruput evaluation
Computers and Automation pp 12-15 January 1966
2 J A SMITH
A review and comparison of certain methods of computer
performance evaluation
The Computer Bulletin pp 13-18 May 1968
3 F D SCHULMAN
Hardware measurement device for IBM system/360 time
sharing evaluation
Proceedings of 22nd National Conference of Association
for Computing Machinery pp 103-109 1967
4 G ESTRIN D HOPKINS B COGGAN
S D CROCKER
Snuper computer-a computer instrumentation automation
AFIPS Conference Proceedings Spring Joint Computer
Conference 1967
5 XDS Sigma-7 computer reference manual
Scientific Data Systems Inc Santa Monica Calif
No 90 09 50
6 IBM reference manual-IBM 8!fjstem/360 principles of
operation
International Business Machines Corp Poughkeepsie New
York Form A22-6821
7 L G ROBERTS
The Lincoln wand
AFIPS Conference Proceedings Fall Joint Computer
Conference Vol 29 pp 223-227 November 1966
8 T A MAZRANCZY
Logic design and interface of a Lincoln wand system
MS in Engineering University of California Los Angeles
June 1969
Also published as UCLA Engineering Report No 69-11
9 R A KOSTER
Low level self-measurement in computers
PhD in Engineering University of California Los Angeles
December 1969
Also published as UCLA Engineering Report No 69-57
SHOEBOX-A personal file handling system for textual data
by RICHARD S. GLANTZ
The MITRE Corporation
Bedford, Massachusetts
margin, and typography coded as nonalphabetic prefixes to words (for those applications where it is relevant). No attention need be paid to page boundaries,
which are, after all, an artifact of paper systems
It must be emphasized here that SHOEBOX* is
only a cover term. As relevant research products within
the larger context of investigation mentioned at the
beginning of this paper come to fruition, they are
refined and incorporated into SHOEBOX. Thus the
system is a continually evolving one, and this description of it is already obsolete. However, we do intend to
maintain upwards compatibility.
Other systems oriented toward handling personal
files are being developed by Engelbart,2 Nelson and
van Dam,3 and Reitman. 4
INTRODUCTION
The SHOEBOX system, a part of MITRE's long-term
effort in the development of text-processing systems, 1
is designed to be the electronic analog of a personal
desk file drawer. A desk drawer is conveniently at
hand and readily accessible. It contains documents,
reports, adversaria-probably most of which, if the
work of others, haven't been thoroughly read, or if
one's own work, remain unfinished. This material is
organized under whatever whimsical scheme suits one's
fancy; and as one's fancy changes, the file contents are
variously combined or further segregated. (Or at least
one would like to perform that kind of reorganization,
at present a formidable undertaking.) Needless to
add, the texts are set down in a variety of formats, the
only common factor among them all being a close
adherence to the grammar rules of natural language.
Such an unstructured environment is the bane of
digital mechanization, but it is to this problem that we
have addressed ourselves.
The system described below is more than a passive
repository for textual information. As an interactive,
time-shared, computer-based system, it can serve a
community of users, working privately or in concert.
Each user· can engage in such activities as browsing,
searching, annotating, reorganizing, editing, indexing,
and composing. He can digress at any time, perform
another activity, and return to his original line of action.
He can share his collection with others. He can apply
one activity to the results of another: a particularly
good example, and one that is possible on few commercial information storage and retrieval systems, is
performing a search on the results of a previous search.
Of course, the architecture of the computer and its
peripheral gear impose some constraints on the form
of the textual information, much the same as typewriter model and page size doin manual filing systems.
SHOEBOX has three conventions: a maximum line
length of 72 characters, no word division at the right
DESIGN CONSIDERATIONS
SHOEBOX is designed to be especially accommodating to its human masters. Since the anticipated
users of the system may have had no (professional)
exposure to computing machinery, we deemed it
important to ease the culture/technology shock. At
the same time, we wanted to provide a versatile system
capable of a wide range of text manipulations. Of
equal importance, we wanted a system that could
be transported to other computer centers. These
overall considerations influenced our decisions in the
realms of hardware configuration, software control,
and data base structure.
The system is interactive, as mentioned earlier, to
provide the user with immediate response to his
action and to allow him to react immediately to that
response. For terminals, displays were chosen over
typewriters or teletypes because of the ability of displays to present large amounts of text almost instan-
* The name derives from the containers in which one of our projected users currently stores his vital information: they bear a
striking resemblance to footwear packages.
535
536
Fall Joint Computer Conference, 1970
~'::"~}
====~-::
ITEM
===-:.-=
?:-:= } ITEM
--_.•. -
} ITEM
choice and need only remain consistent within anyone
file.
Meta-textual information can be coded as well. FOl'
example, if page reference to the hard· copy original is
needed, a line containing the page number and having
the category "p" associated could be used at the change
in page.
Note that items, files, and file drawers have no fixed
size. They expand and contract to accommodate
however many lines of text are inserted or removed.
BASIC OPERATION
Figure I-Data base structure of SHOEBOX
taneously. In addition, their comparatively silent
operation is more conducive to the human thought
processes the system is supposed to enhance. For
transportability, the system operates on the rather
common IBM 360/50, under OS. The display consoles
are IBM 2260's, whose prime attraction is their
availability and relatively low price. We would prefer a
larger capacity scope with some kind of cursor or position controller like a "mouse," but no acceptable
versions were available at the inception of this project,
or are now, for that matter. Further details on the
hardware and system software are discussed later in
the paper.
From the user's point of view, the data base is a
collection of files, each labelled with a mnemonic of
24 characters or less. (See Figure 1.) The files may be
placed into a number of private file drawers, and
each of these also has a mnemonic label. One file
drawer, termed public, is available to anyone using the
system. *
A file is a sequence of lines of text, which may be
grouped into items. An item, which is typically several
paragraphs in length, may have a one or two character
category code associated with each line. The category
code can be used to indicate titles, authors, dates,
descriptors, personal annotations, or what-have-you.
Although the user mu~t identify which lines have which
categories, the code scheme itself is completely his
* There is also a system file drawer, which contains the programs
SHOEBOX actually calls on to run itself. This arrangement
makes modifying and improving the system quite convenient.
Source programs are reorganized and manipulated in much the
same way as straight text. This aspect of SHOEBOX will not
be discussed here.
To facilitate the detailed discussion which follows
later in this paper, it will be helpful if we introduce at
least the basic file manipulation operations.
After logging on to the system by identifying himself, the user opens the file drawer he intends to work
with and selects a particular file to examine. Until he
chooses another file, subsequent commands (with a
few obvious exceptions discussed below) are considered to apply to the file he has "placed on
his desk." The command EXAMJNEFILE(irving) ,
entered on the top line of the CRT, will select the file
named "irving" and will display the initial lines of
irving on the remainder of the scope. *
Beyond the right margin of each text line are displayed the line category, if any, and the line position
in the file. Line positions are numbered sequentially
upwards from 1; they are automatically maintained· by
SHOEBOX and need not be a concern of the user
except for ontological reference.
To browse through irving, the user can repeatedly
enter the command NEXT, which will step him through
the file one scopeful at a time. The command PREVIOUS reverses the direction of travel. l\1ore rapid
skipping around is achieved by entering an integer n,
which will cause irving to be displayed beginning at the
nth line. To jump directly to the last several lines of the
file , the user enters LAST. Content-directed browsing
is also possible. Suppose he is curious as to whether the
description "fig newton" occurs later in the file. The
command FIND('fig newton') will cause SHOEBOX
to search the rest of irving for the next line containing
the character string "fig newton" . The displayed
response is either the relevant portion of irving or the
comment NOTHING FOUND. This is a primitive
kind of search; later in the paper we will discuss the
more powerful search capabilities available in SHOEBOX.
* We will adopt the convention henceforth of printing in full
caps system commands and system responses.
SHOEBOX
Personal comments can be interspersed throughout a
file. Whatever is entered below the response line on the
display can be incorporated into irving with the command INSERTSCOPE. The new material will be
treated the same as any other part of irving, although
it would be judicious to mark the comment lines with a
distinctive category code.
When the user is finished with irving, he can place it
back in the file drawer with the command FILE. Alternatively, he can call out another file, say EXAMINEFILE (arnold) , which puts irving away and places
arnold on the desk.
With this brief introduction to the "flavor" of SHOEBOX, we would like to turn our attention first, to the
very important human accommodation factors, and
second, to a detailed exposition of the really powerful
things the system can do.
HUIVIAN FACTORS
In the belief that an interactive computer system
should be a complement to human thought rather than
an intrusion, SHOEBOX commands are designed to
mimic human textual activity. At the same time,
actions which could be harmful if employed inadvertently are made somewhat difficult to perform.
One way we have made the system easy to learn is by
grading the entire instruction set. The grading is done
on the basis of both name and capability. For example,
the novice may use the command EXAMINEFILE(irving) to call out the file labelled irving. After a
brief exposure to the system, he would undoubtedly
prefer using the abbreviated equivalent command
EF(irving). All long-named, frequently used commands
have "obvious" abbreviations: IS for INSERTSCOPE,
ML for IVIOVELINE, SF for SUBSTITUTEFILE,
S for .SUBSTITUTE, etc. More experienced users
can step up to the level of extended commands, e.g.,
EF(irving 55) will bring irving out from the file drawer
and display it beginning at line number 55. Thus the
user can promote himself to advanced levels to match
his own needs, work habits, etc. We are currently engaged in publishing a series of graded instruction
manuals and reference guides to aid and encourage
this kind of personal development.
Once learned, retention is high. The operations performed by the user, for the most part, parallel human
desires, not machine requirements. The choice of
command names and their verb or verb-noun construction is a familiar mnemonic device. Consistency
also plays a role. The top of the scope is reserved
exclusively for user commands; the second line, for
system response.
537
We have endeavored to adhere to the principle that
for every user action, there is a machine response.
Ordinary conversation between humans becomes trying
unless the listener occasionally nods his head or murmurs some sort of acknowledgment. When the conversational partner is a computer, a lack of response or
even a delayed response can be deadly. This is especially
so for the intermediate-level user: the tyro has no
expectations anyway and the sophisticate will sit
and curse the system programmers, but the sophomore
is the one most likely to panic and perform a disastrous
action. After the user enters a command on the command
line, SHOEBOX indicates that it has received the
command by erasing the response line. If the command
is incorrectly formulated, or if the request cannot be
carried out for some reason, a comment identifying
the difficulty is displayed on the response line. If the
command is properly executed, either a confirmatory
statement is displayed on the response line or a relevant
portion of the file "on the desk" is displayed from the
response line down. For commands which are likely to
take over six seconds to carry out completely, a running
commentary of some reassuring sort appears on the
response line. * **
The command set is designed to protect the user
against himself. For example, wholesale deletion of
material requires just a bit more thought. Unlike. most
operations on the "desk" file, the command to delete
the entire file requires that the file be named specifically. In another situation, the unsophisticated user
is not told how to directly replace the contents of one
file with the contents of another. While such a command
does exist, its hasty application could cause the unwanted destruction of the target file. Instead, the
inexperienced user is taught to first append the source
file to the target file and then delete that portion of the
target file he doesn't wish to save. By requiring such
deletion actions to be explicit on the part of the user,
we hope to save him from unnecessary grief.
Perhaps the ultimate in user accommodation is
reached with the facility provided in SHOEBOX for
coining personal alternates for any of the commands.
One of the staff members of the project, for instance,
feels happier with EDFIL instead of EXAMINEFILE,
STORP instead of SUBSTITUTE, and ADSCOPE
instead of INSERTSCOPE. Any such neologism can be
defined in the system lexicon with a single command.
* At the time of this writing, we have not fully implemented this
feature: it appears only on search commands at present, as a
rendering of the number of (1) the current line being searched
(in multiples of 20, to avoid overdemand on the central processor)
or (2) the latest line where a match was found.
** See Miller 5 for an extended discussion of responsiveness in
interactive systems.
538
Fall Joint Computer Conference, 1970
Furthermore, because the lexicon will handle any
number of alternates to a SHOEBOX command
name; potentially every user could satisfy his iconoclastic desires.
We all make mistakes. If the user wishes to prevent
SHOEBOX from completing the execution of his last
command, he hits the "enter" key on the console
keyboard again. Control then pops up to the neutral,
()r waiting state. At this point, the user can return the
file, unaffected, to the file drawer with the command
GIVEUP. Or, he can change relevant variables (e.g.,
output format for a PRINTF command) and resume
execution with the command RESUlVIE.
When SHOEBOX itself is suspect, the command ?
will cause the system to interrogate itself, indicate
what its state of activity was, and return to that state.
Sample responses to ? are WORKING, WAITING
(for a command), and SWAPPING (between users). In
case of system failure, the response to ? is a locked keyboard.
SHOEBOX is accommodating up to a point. At
twenty errors, it becomes intolerant and logs off.
SPECIAL CAPABILITIES
Editing
Correcting typographical errors, rewording phrases,
and inserting and deleting. passages are typical editing
operations on a text. With SHOEBOX, the author can
immediately inspect the results of his decisions.
If he remains dissatisfied, he can try again, or he can
put the questionable material aside and come back
later, or he can make a copy of it for subsequent comparison with alternate phrasings.
There are two basic ways to effect local changes in the
stored text. One is to make u~e of the display hardware
and type over the displayed lines of text. When the
command SUBSTITUTE is given, the text lines on the
scope replace the corresponding lines in the file. As a
check, SHOEBOX redisplays the same scopeful, but
from the now modified file.
The second way makes use of a search-and-replace
command called CHANGE. The command CHANGE('a' 'b' n) replaces the string of characters a in line n of
the desk file with the string of characters b. If there is
more than one occurrence of a, only the first will be
affected. Taking the previous sentence as an example
and with the correct choice of n, CHANGE('will be' 'is'
n) will transform the consequent phrase to read, "only
the first is affected".
With its ability to insert arbitrarily long strings,
CHANGE can affect as well the text outside line n. On
the specified line, deletions are closed up; and insertions are spilled over to a new line (and line numbers
greater than n are incremented accordingly to allow
for the interlineation). The contractions and expansions
caused by a CHANGE command are not bubbled
through the entire file. That would degrade the response
time. Instead, when he has completed his editing modifications, the user can request that.the file be PACKed.
This operation is analogous to the request one makes of
a secretary to "type over" a manuscript; however,
with an electronic file, the redoing takes only seconds.
CHANGE is a graded command. If a second numerical argument is specified, as in CHANGE('a' 'b' m n),
the first occurrence of a, if any, in line m, line m+ 1, ...
line n is replaced by b. The command CHANGEALL
makes the same replacement for every occurrence of a.
IVlultiple changes within a line can be achieved by
providing successive pairs of strings in the argument,
as in CHANGE('a' 'b' 'e' 'd' m n). Another CHANGEtype command affects the line category code only.
An extensive error analysis is provided which informs
the user of an error in syntax, the non-occurrence of
a in a line, the non-occurrence of a line number in the
file, and, for the wise guys, the requirement that m
cannot be greater than n nor can either of them be less
than one or greater than the number of lines in the
file.
Copying
Copies of items or of entire files can be made and
placed at the end of any file or within any file drawer.
For safety's sake, however, no command can make
reference to a particular place within a file unless that
file is on the desk (so that the affected portion can be
visually inspected). Thus, only portions of the desk
file can be copied and placed at specified points within
the desk file.
The commands which copy from the desk file are
exemplified by the following:
APPENDTO(arnold 34)-places a copy of line 34 of
the desk file at the end of
arnold (which can also be
the desk file)
INSERTLINE(12 34)-places a copy of line 34 of
the desk file before line
12 of the desk file
In the first example above, if arnold doesn't exist in the
file drawer, a new, empty file with that name will be
made; and then the appending operations will be
performed. Items as well as individual lines can be
SHOEBOX
539
AFTER COMPLETING THIS QUESTIONNAIRE, HIT "ENTER" .
......................................... . IS THE FILE YOU WANT SEARCHED. TYPE SEARCH REQUEST BELOW:
.......................................... ARE THE CODES OF THE LINES YOU WANT SEARCHED IN THE FILE .
......................................... . IS YOUR NAME FOR THE FILE WHERE THE ANSWERS WILL BE PUT .
............. . ARE THE NUMBER OF LINES BEFORE THE MATCH LINE THAT YOU WANT IN EACH ANSWER
................ ARE THE NUMBER OF LINES AFTER THE MATCH LINE THAT YOU WANT IN EACH ANSWER
.............. DO YOU ALSO WANT THE DATE OF THE RELEVANT DOCUMENT ALONG WITH EACH ANSWER?
Figure 2-Questionnaire for SIMPLESEARCH
copied: APPENDTO(arnold 34 52) will copy the item
encompassed by lines 34 through 52 to the end of
arnold. INSERTLINE(12 34 52) would be proces~ed
in a similar fashion. Further, extensions of these
commands allow several non-contiguous passages to be
copied at the same time. In this manner, an extract of an
article could be taken, and stored in a file of such
extracts or tacked onto the article itself. The command
INSERTFILE, with appropriate arguments, will copy
an entire file and place it before a specified line of the
desk file.
To make a separate copy of a whole file, there is no
need to take the file out of the file drawer. The command COPYF(irving arnold) makes a copy of irving
and labels it arnold. If there already is an arnold in the
same file drawer, its contents are discarded first.
Because of the danger of catastrophe with this command, the incautious user is well advised to employ
instead the following two-step procedure:
EXAlVIINEFILE(irving)
APPENDTO(arnold 1 Last)
If there was something in arnold beforehand, the
appending operation will preserve it. An· alternate
safe procedure is to enter first
EXAlVIINEFILE( arnold)
and then, only if the response is ARNOLD NOT A
FILE, enter
COPYF(irving arnold)
The command APPENDFILE(irving arnold) makes a
copy of irving, if it exists, and appends it to the end
of arnold, if it exists. Thus, a third alternative IS
APPENDFILE(irving arnold)
Searching
While rapid access and facile manipulation materially
aid the· collector and analyst of information, the crux
of the problem is discovery and rediscovery of what is
pertinent. There is always an uncomfortable feeling
about pigeonholing material under headings or even
tagging material with a multitude of descriptorscritical snips of information seem to get lost by this
precategorization.
The situation is especially acute in public affairs,
where personalities, events, and issues which received
little notice in the past may suddenly move to center
stage. When past history lies scattered among the files,
retrieval is difficult. The ability of SHOEBOX to
search on the actual words in the texts, as well as on
descriptors and categories, greatly enhances the reliability of the search.
We have already introduced our most primitive
search command, FIND. Briefly, FIND('fig newton')
will search the desk file, from the second text line
currently displayed to the end of the file, for the
first occurrence of the string "fig newton" which lies
completely within a single text line. (At the request
of some users, we have implemented a related command, FINDANCHORED, which looks only along
the left margin.)
A higher degree of search capability is attained with
SIlVIPLESEARCH. When this command is entered,
the questionnaire in Figure 2 appears on the scope in
response. *
Note that:
1. the file to be searched need not be on the desk
2. the entire file is searched
3. the search can be restricted to lines with certain
categories
4. the search does not cease at the first match, but
begins again at the next item
.
5. the "answers" are not displayed but put into a
file for subseq~ent inspection and manipulation
* Not explicitly called out in the questionnaire are the values for
two system variables, which indicate (1) the category assigned
to the date line (or· any other category line to introduce each
answer) and (2) the category of the line which begins or terminates every item. We assume these variables, once set by the
user, are uniform for his entire file collection.
540
Fall Joint Computer Conference, 1970
TABLE I-Composition Possibilities for SIMPLESEARCH
Concept
Example
Searches for all occurrences of
Word
newton
newton, newton's, newton?, newton.", 3newton (supposing the prefixed
numeral denoted typographical coding), 3newton-3raphson, newtonsec/m; i.e., any matching string of characters delimited by nonalphabetics
Concatenation
fig newton
fig newton, fig newton's, "fig" newton, etc.
Disjunction
fig I date
fig, date, fig's, date?, etc.
Specific Optionality
newton %interference rings
newton interference rings, newton rings, etc.
Complementation
newton -, interference rings
newton diamond rings, newton pastry rings, newton circus rings, etc.,
but not newton rings or newton interference rings
Phrasing
date I (fig newton)
date I fig newton
date, fig newton, etc., but not date newton;
date newton, fig newton, etc., i.e, disjunction takes precedence over
concatenation (and over specific optionality and complementation,
as well)
Anchored Stem
'newton*'
'*newton'
same as the word newton, plus newtonian, newtonians, newtons, and
(newtonian), newtons', etc.
same as the word newton, plus antinewton, etc.
Free Stem
'*newton*'
'newton'
'3newton'
both the above, plus antinewtonian, etc.
equivalent notation
3newton, 3newton's, etc;, but not newton, newton's, etc.
Non-specific Optionality
newton 1 rings
newton rings, newton interference rings, newton diamond rings, newton
pastry rings, etc.
newton, etc., followed by up to 7 intervening words and stems,
followed by rings, etc.
newton 7 rings
6. pre- and post-context can be specified (with
FIND, the pre- and post-context are fixed at
and 9 lines, respectively)
°
We will describe the form of the search request by
illustration rather than by formal definition. In this
instance, a formal statement would be pedantic. The
reader is first advised to consult Table I.
As an example, let us suppose an analyst keeps a file
of newswire reports on South Vietnam. Let us suppose
further that many months later he is assigned a task
which involves retrieving those news bulletins which
give actual figures in mentioning American troop withdrawals. One of the search prescriptions he could try is:
'*000' %us 'troop' 3 'withdr' I ('pull' out)
Reports containing any of the following phrases would
be identified and retrieved:
· ..
· ..
· ..
· ..
· ..
· ..
30,000 US troops withdrew ....
5,000 US troops will withdraw .. .
46,000 troops will be pulled out .. .
10,000-man troop withdrawal .. .
365,000 troops could have been withdrawn ...
44,000 troops to pull out ...
It should be noted here that, under SIlV[PLESEARCH,
unlike FIND, these phrases can be found even if they
begin and end on different lines.
After the search has been completed, the results and
a copy of the questionnaire itself are placed in the
designated answer file for examination. Consequently,
the search can be reformulated and applied to the
source file or the answer file. If a third file is designated
as the repository for the second search, the two results
can be compared. Or, the same search can be applied
to another file without rekeyboarding anything except
the file label. Finally, using the annotation and reorganization commands, our Vietnam analyst can compose a
report and incorporate the corroboratory search results.
A third degree of search capability is reached with
CSEARCH (for contingent or complex search). This
search request provides greater selectivity over the
choice of items to be searched within the file and allows
greater control over the format of the answers. Especially potent is the search prescription itself: it allows
unordered search terms, contingent searches, and
synonymic substitution.
The command CSEARCH causes the questionnaire
in Figure 3 to be displayed.
SHOEBOX
541
1
2
**NAME OF FILE->
**SEARCH FROM LINE->
**TO LINE->
**REMEMBER LINE CODES->(
) **IGNORE->(
) **TERMINATOR->
**SEARCH REQUEST ('LINE CODES' 'SPECIFICATION'; .. , ;)-> (
3
5
6
7
8
9
10
Figure 3-Questionnaire for CSEARCH
(The line numbers are displayed to allow modifying
the answers to the questionnaire with the SHOEBOX
editing commands.) Line 1 asks for the name of the
file to be searched; line 2 allows the user to limit the
extent of the search; line 3 provides for the setting of
certain system variables; and lines 5 through 10
accept the search prescription. Table II lists the
additional composition possiblities under CSEARCH.
Conjunction is typically used when dealing with
key words or descriptors. For example, the search
prescription
(k d) wood, preservative
would be expected to'find items relating to preservatives
for wood, where d and k are the categories of the lines
containing the index terms.
$NU.lVI is a two-argument function which can be
embedded in a search specification. To illustrate with
a simple usage, let us assume that the entire search
prescription is of the form:
c $NUM('m' en')
where c is a category code and m and n are non-negative
integers (with or without internal punctuation; e.g.,
52,000, 69.03.14, 3.14159). Then any item whose c
line has a number in the closed interval [m,n] will be
found and selected (provided m and n have a
consistent format). This numerical capability has
many applications; the example shown in Table II for
'
calendar dates is particularly appealing.
One of the most attractive .. facilities within
CSEARCH is the power of pattern substitution. Consider our analyst again. Suppose now he is given the
assignment of accumulating all reports which mention
cease-fire violations in the Middle East. He might
begin by formulating a tentative search specification
arabs 3 'attack' israel
which will find sentences such as "Arabs attacked
Israel last night". But since many nations fall under
the rubric "arab", he will soon realize that a better
specification is
jordan 1 egypt 1 lebanon '1 syria 1 iraq
I
(saudi arabia) 3 'attack' israel
This phrasing will find "Jordan has attacked Israel",
etc. Using stems instead of words, as in
'jordan' I 'egypt' I 'leban' 1'syria' I
'iraq' I (saudi 'arabia') 3 'attack' 'israel'
he can locate "Jordanian troops attacked Israeli
positions", "Lebanese artillery attacked Israeli fortifications", etc. Rather than have to rekey this representation for "arabs" each time he modifies his
search request, the analyst can define them to be mem-
TABLE II-Additional Compositional Possibilities for CSEARCH
Concept
Example
Conjunction
date, fig
date, fig newton
both date, date), etc. and fig, fig/, etc. anywhere in same text portion
both date, etc. and fig newton, etc., i.e., concatenation takes precedence over conjunction
Numerical Interval
$NUM('69.01' '70.03')
items dated between January, 1969 and March, 1970 [see text for
;.
further explanation]
Substitution
$CLASS snacks
the components dictated by the search pattern labelled "snacks"
[see text for further explanation]
Searches for all occurrences of
542
Fall Joint Computer Conference, 1970
bers of a labelled set. Then he would write the previous
search specification as
$CLASS arabs 3 'attack' 'israel'
where he· has defined $CLASS arabs, after further
thought, to be the long disjunction
'arab' I 'guerilla' / (al fatah) / 'jordan' /
'egypt' / 'leban' / 'syria' / 'iraq' ,
'israel' 3 'attack' $CLASS arabs
"Attack", of course, is not the only verb which connotes
aggressive activity. The analyst could again reformulate
his search specification as
$CLASS arabs 3 $CLASS aggress 'israel'
where he has defined $CLASS aggress to be the pattern
'attack' / 'bomb' / 'shell' / 'strik' /
struck / 'hit' ,·'straf' ,'raid' , 'sink' ,
sank / sunk
These class definitions become a permanent part of the
user's file collection. At any time, however, he can
employ the editing commands of SHOEBOX to examine the CLASSes he has defined and to effect a
change in content or label.
$CLASSes can be embedded in one another. For
example, journalistic style allows such synecdochic
expressions as "Amman claims their artillery shot
down ... " Our analyst might very well wish to set up
an equivalence between country and capital, VIZ.:
$CLASS jordan
$CLASS egypt
{'israel' , (tel aviv) }
{'j ordan' / amman}
{'egypt' , cairo}
$CLASS lebanon : = {'lehan' , beirut}
$CLASS syrIa
$CLASS iraq
$CLASS saudi
'.'.'.-
{'syria' , damascus}
{'iraq' / baghdad}
{(saudi 'arabia')
$CLASS jordan I $CLASS egypt'
$CLASS lebanon / $CLASS syria,
$CLASS iraq' $CLASS saudi}
$CLASS mideast : = {$CLASS arab I $CLASS israel}
In this manner, he has defined the set of entities he can
henceforth refer to as "arabs". This maneuver not only
saves him from keyboarding this long pattern again as
he constructs related search prescriptions, it also saves
him. the bother of remembering or redetermining what
political groups of people comprise Arabs in the Middle
East. Thus he can readily specify the reverse request,
'.'.'.-
$CLASS arab : = {arab / guerrilla, (al fatah) ,
and perhaps even further:
(saudi 'arabia') ...
$CLASS israel
and in turn:
/--*}
* The capital of Saudi Arabia is left as an educational enterprise
for the reader.
Concomitant with the power of embedded $CLASSes
is the danger of self-referral. CSEARCH expands all
$CLASSes in the search prescription given it before
actually proceeding with the search. If there is an
infinite loop, or if the expanded search prescription is
so huge that it threatens to take up all the allotted
list space in the computer, the comment VICIOUS
LOOP is displayed on the response line of the scope.
The concept of $CLASS is also useful in dealing
with spelling variations in transliteration. The name
of the leader of Al Fatah has appeared in print as
"Yasser", "Yassir", and ttyasir". Often one entity
has several names: trinitrotoluene, TNT; lysergic
acid diethylamide, LSD, LSD-25; Songmy, Song My,
Son IVly, l\1y Lai, Mylai, l\1ylai #4, l\1ylai Village #4,
Pinkville. Establishing a substitution class both
records the alternations and ends the reliance on one's
memory.
The indolent and the impatient can also use $CLASS
to advantage. Why keyboard "Society for the Prevention of Cruelty to Animals" if a substitution class
with "spca" can be set up? If there is no standard
acronym, make up your own nickname; for example:
$CLASS rocky : = {governor nelson h rockefeller
'nelson rockefeller ,
the new york governor}
When first conceived, $CLASS was seen as a means
to facilitate synonym sets and thesaurus hierarchies
(and hence the name, $CLASS). As programmed,
however, it is an instrument for wholesale pattern
substitution. Any pattern, even a search prescription
itself, can be defined as a $CLASS. Thus, a frequently
required search prescription can be incorporated within
a $CLASS and called out for subsequent use.
There is one search mode in CSEARCH left to discuss-contingency. If a sequence of search prescriptions is given, separated by semicolons, the subsequent
search prescription only applies to the items satisfied
by the previous prescription. While effectively only a
conjunction of searches, this mode of search will save
a considerable amount of search time in large files.
SHOEBOX
By way of illustration, the following search prescription
d
$NU1VI('69.06.20' '69.08');
a
south vietnam;
(h b)
'*000' %$CLASS us 'troop' 3
'withdr' I ('pull' out);
will, first, select from the file all items whose d line
contains a date between June 20, 1969 and the end of
August, 1969; second,. select from this subset all items
whose a line contains the descriptor "south vietnam";
and third, select from this new subset all items whose
h or b lines contain a text passage satisfying the search
specification shown.
At the completion of the search, a line number
reference to each "hit" and the total number of "hits"
are displayed. Based on this information, the user may
decide to broaden, narrow, or reformulate his query.
Or he may decide to place the items found by
CSEARCH in an answer file. To do this, he completes another questionnaire, which allows him to label
the answer file, to store with the answers the original
search questionnaire with the $CLASS terms in the
search prescriptions expanded out, and to control the
formatting of the answer file and certain associated
data.
Reorganizing
Armed with the results of his searching, the user can
make new files, discard unwanted files, merge files together, rearrange items within a file, and move files from
one file drawer to another. For the author, reorganizing
commands can be used effectively to cut-and-paste
portions of text in writing reports. Indeed, in organizational structures where reports are passed from the
lowest stratum to the highest level through a series of
middle management filters, SHOEBOX offers a
convenient way to extract data from an incoming
report, add salient observations of your own, and pass
the "new" report on to the next higher level.
The items within the desk file can be placed in ascending or descending order with the command ORDER.
Among the arguments to this command is a sequence
of {category code, sort key} pairs. If, for any item, the
first pair cannot apply because the code and key do not
co-occur in that item, the second pair is tried, and so on.
This feature is useful, for example, if we wished to
arrange a file of documents by author, or, if none, by
editor. By employing ORDER several times, one can
organize the items in a file say, first with respect to
date; and within date, by author; and within author, by
title.
543
Items can be discarded from the desk file with the
command REMOVELINE(m n), where m and n are
the line numbers delimiting the. unwanted passage.
Alternatively, they can be shifted to the end of another
file, say irving, with REMOVETO(irving m n). Or, they
can be shifted to another position within the desk file,
using l\10VELINE(k m n), where k denotes the line
number before which the passages are to be inserted.
Of course, if m = 1 and n = Last, the entire file is
affected.
Comments keyboarded on the display may be inserted into the desk file with INSERTSCOPE(k);
or they may actually replace specified lines in
the desk file, using SUBSTITUTESCOPE(m n).
Scope comments can also be appended to the end of
any file, say arnold, with the command APPENDSCOPETO( arnold).
I nput/Output
A hard copy of irving can be printed off-line with the
command PRINTF(irving); similarly, PUNCHF(irving) punches irving onto cards. Other commands
allow the reading and writing of files from and to
seven- and nine-track tape or any OS sequential data
set. For example, we have successfully passed files
from SHOEBOX to IBlVI's Conversational Programming System (CPS) and vice versa; we also have
passed files to a KWIC program.
Housekeeping
All files are automatically date-stamped by SHOEBOX with the day/month/year that the file was last
changed in any way. When a file is brought out for
display, this information, together with the name and
size of the file, is displayed on the response line.
If the· user wishes to see all the file labels in his
collection, he enters the command LISTF ( ). The
argument within the parentheses determines the. file
drawer; if there is no argument, all file labels for both
public and private file drawers are displayed.
For both training and system debugging purposes,
a record is made of all commands and other material
entered into the system at the display keyboard and
all displayed responses by the system. The hour /
minute/ second when each command was entered is
also saved. This record-keeping function can be
partially or totally deactivated at log-on time. Otherwise, the record accompanies the off-:-line printout for
each user.
544
Fall Joint Computer Conference, 1970
HARDWARE AND SOFTWARE DETAILS
SHOEBOX is implemented on the IBM 360 under
OS/360 (PCP, MFT, or MVT) , in a 225K high- or
low-speed partition, and with a private IBM 2316 disk
pack. If SIMPLESEARCH and CSEARCH are not
needed, it will operate in 140K. The system as presently implemented will support up to eight IBM
2260 Model 1 (12XSO) display stations in a local
configuration supported by the Graphics Access
Method (GAM). Budget considerations, however,
have limited our work experience to four stations. These
terminals can be located up to 2000 feet from the
display controller. The transmission speed is quite
fast: 2500 characters per second, or on the order of
half a second to write the entire scope.
SHOEBOX is written in TREET, a list processing
language6 derived from, LISP; and the system is run
under the TREET/360 operating system. The TREET
filing system operates, using OS direct access techniques,
by dividing a single OS sequential file into small individual segments called pages, which are dynamically
allocated and released. A SHOEBOX file is an ordered
set of these pages. (The line numbers of the file are not
stored with the file, but they are generated as required.)
In this manner, modification of the file does not entail
rewriting the entire file, but only the pages affected
and the file directory. The directory is hash-coded, so
that file access time is nearly independent of the
number of files.
The approximate capacity of the system is 100 to
300 file labels per file drawer (depending on label length)
with direct access to 2000 double-spaced typewritten
pages of text per file drawer. The number of file drawers
is dependent on the amount of space available on direct
access storage devices.
Initial response time to a request is on the order of a
few seconds. Time to process completely the request is a
function of whether other jobs are utilizing the central
processor or the input/output equipment, whether we
are given a partition in high- or low-speed core, and the
complexity of the request.
Because of the experimental nature of the project,
plus the variety of accounting algorithms that we
have been experimental guinea pigs to, we have been
unable to compile meaningful operating cost figures for
SHOEBOX. We hope to be able to do so in the near
future.
CURRENT DEVELOP1VIENT EFFORTS
In the SHOEBOX system described here, searching
within a line is carried out sequentially, character by
character. An experimental system has been programmed to test the potential savings of an index
search. That is, for each file, an alphabetized list of its
words was compiled, together with a set of pointers
to their locations in the text. There are two advantages
to searching the index instead of the text itself: (1) the
time of search is more-or-Iess independent of the size of
file, and (2) the search, being sentence-oriented, takes
cognizance of natural text boundaries; e.g., a request
for the phrase "fig newton" won't deliver the item
containing the passage, "The Birge-Vieta method isn't
worth a fig. Newton-Raphson isn't worth much either~"
There are compensating difficulties: (1) what algorithm
determines sentence boundaries (recall that a period
has more than the terminal function)?, (2) how should
right-anchored stems occurring in the search prescription be handled?, and (3) must the index be
recompiled after every modification to the file? Nonetheless, our findings with this experimental program
showed savings in search time of an order of magnitude.
With this encouragement, we are in the midst of incorporating a similar index search in SHOEBOX.
For use in a community of research workers, we
would like to implement a "mailbox" feature. At
log-on, the individual's name would cause any messages
left for him by others to appear on the display. A less
intrusive alternative would be for a message like
SOMETHING IN YOUR MAILBOX to appear.
Other projects in the early design stages are (1)
graded error messages, (2) structured file drawers, and
(3) statistical capabilities.
Under consideration is a facility for designating ORe
member of a synonym set as having "print" status.
This option would be especially welcome in composing
reports: the author could keyboard his personal acronym or nickname for a wordy phrase or hard-to-spell
proper noun, but the display and the file would contain
the "official" forms.
It is our intention to incorporate into SHOEBOX
increasingly sophisticated linguistic techniques of the
kind represented in SAFARI,7 a l\1ITRE text processing system in which the information content of
English sentences is stored and retrieved directly.
ACKNOWLEDGMENT
In the age of big science, progress is a group effort.
Henry Bayard, Carter Browne, Stanley Cohen, J e'anne
Fleming, Louis Gross, Ted Haines, Lewis Norton, and
Donald Walker have all contributed to the design,
implementation, and testing of the system. We also are
indebted to Thyllis Williams of Inforonics, Inc., for
guidance in both design and testing.
SHOEBOX
REFERENCES
1 D E WALKER
Computational linguistic techniques in an on-line system for
textual analysis
MTP-105 The MITRE Corporation July 1969
2 D C ENGELBART W K ENGLISH
A research center for augmenting human intellect
AFIPS Conference Proceedings Fall Joint Computer
Conference Vol 33 Part 1 pp 395-410 1968
3 S CARMODY W GROSS T H NELSON
D RICE A VAN DAM
A hypertext editing system for the /360
In M Faiman and J Nievergelt (ed) Pertinent Concepts in
Computer Graphics
University of Illinois Press pp 291-330 1969
545
4 W REITMAN R B ROBERTS R W SAUVAIN
D D WHEELER W LINN
AUTONOTE: A personal information storage and retrieval
system
Proceedings 24th National Conference of the ACM
pp 67-75 1969
5 R B MILLER
Response time in man-computer conversational transactions
AFIPS Conference Proceedings Fall Joint Computer
Conference Vol 33 Part 1 pp 267-277 1968
6 E CHAINES
TREET, a list processing language and system
MTP-104 The MITRE Corporation March 1969
7 L M NORTON
The SAFARI text processing system: IBM 360 programs
MTP-103 The MITRE Corporation September 1968
HELP-A question answering system*
by ROGER ROBERTS
University of California
Berkeley, California
INTRODUCTION
minals, in the process of using the system. Users would
ask questions of HELP, in their course of work at a
terminal, in the same maner as they would consult a
reference manual. Therefore, if HELP was to be useful,
it had to be easier and quicker to use than a manual.
A further design consideration was that many different HELP systems would be constructed, each with its
own data base and each by a different person. This
implied that a "shell" would be designed, which
contained all of the lOgic necessary for HELP, but without a data base. A working HELP system would then
consist of this "shell" and an appropriate data base.
Since many different people would be constructing
HELP systems, the procedures for building a data base
should be uncomplicated.
The above considerations led to the following conclusions. The analysis of the questions was to be kept
as simple as possible. Complex syntactic analysis was
ruled out since activation and response times had
to be low and core space had to be limited. In addition,
the relationship between the questions and the responses
had to be straightforward, so as to facilitate the
construc,tion of a data base.
That a system could be designed with these constraints was supported by work done prior to this paper.
In this preliminary version of HELP,! it was observed
that the meaning of most questions, of the type we
would encounter, is independent of word order. This
observation allowed for a design which only reacted to
particular words in a question, called KEY WORDS,
and ignored both the word order and the remaining
words. Using this mode of analysis produced a question
answering system which both conformed to the restrictions stated above and correctly answered the
questions put to it.
HELP-A Question Answering System-enables a
user, sitting at a console of a time-shared computer, to
obtain information based on questions typed in. This
information might concern the operating system itself,
the format of commands to the user interface executive
program, the use of a selected subsystem, or an area
totally separate from the computer. The content of the
data base in HELP is completely arbitrary, and determined by the creator of each individual HELP
system. Questions are presented to HELP in standard
English and elicit one or more separate responses,
depending upon the nature of the question. If HELP
cannot generate an appropriate response, a standard
"I don't know" message is output. A second system,
called QAS, was developed to enable a user to conveniently generate a HELP program. This paper will discuss
the structure of both programs. All of the work discussed in this paper was performed on a modified
SDS 930 computer, developed at Project Genie at the
University of California, Berkeley.
BASIC PHILOSOPHY
One of the maj or considerations in the design of
HELP was to produce a system with a fast response
time for the majority of the questions it encountered.
In other words, a system was desired which would
require no more than one second between the time it
was called to the time it was ready to accept a question,
and, for 75 percent of all questions, would require no
more than one second between the time a question was
terminated and the time the printing of the answer
began. It was felt that this constraint was necessary
since HELP was to be an aid to users sitting at ter-
STRUCTURE
* This
work was partially supported by Contract No. SD-185,
Office of the Secretary of Defense, Advanced Research Projects
Agency, Washington, D.C. 20325.
The primitive objects used by HELP are called
KEY WORDS. These are words which have been
547
548
Fall Joint Computer Conference, 1970
defined previously, and only a member of this set of
KEY WORDS will be considered in the formation of
the answer. Certain sets of these KEY WORDS are
singled out as defined KEY WORD LISTS, and these
KEY WORD LISTS are used by HELP in determining
what answer to give. The basic idea is to extract the
KEY WORDS from the question, and from this set to
determine what KEY WORD LISTS are present.
For example, assume that the words "file", "open", and
"input" have been defined as KEY WORDS and, in
addition, no other words have this property. Then the
question "What is a file?" would present to HELP the
set of KEY WORDS "file", the question "How can I
open a file?" the set "open, file", and the question
"What is used to open a file for input?" the set "open,
file, input". These sets of KEY WORDS are the only
pieces of information which are extracted from the
questions and, in fact, are unordered sets. "Which
instruction is used to open an input file?" would
generate the same set as above, namely "open, file,
input". Notice also that all words not KEY WORDS
are ignored, so the question "Input file open?" would
have been just as meaningful to HELP.
Now that we have these KEY WORDS, what do we
do with them? As mentioned above, some sets· of KEY
WORDS are defined to be KEY WORD LISTS, and
these lists are used to determine what information
should be given in response to a question. When creating a data base for HELP (to be described below), a
KEY WORD LIST is defined by specifying the
KEY WORDS which comprise the list and the response
to be generated when this list is recognized in a question.
This link between a KEY WORD LIST and a response
is the major mechanism which HELP uses to answer a
question. To return to the above example, assume we
have now defined the KEY WORD LIST "file" to
have the response "A file is a collection of data .... "
Also, assume we have linked the KEY WORD LIST
"open file" to the response "The instructions to be used
to open a file ... " and the KEY WORD LIST "open
file input" to the response "To open a file for input
use .... " Now, with these definitions, we would want
the question "What is a file?" to elicit the first answer,
the question "How do I open a file?" to elicit the second
answer, the question "How do I open a file for input?"
to elicit the third. For HELP to do this, another
mechanism is required, one which can decide which
KEY WORD LIST to extract from the set of KEY
WORDS in the question. Without this additional
mechanism, we would encounter a problem. For even
though the word "file" is present in all three of the
above questions and this word is a KEY WORD
LIST itself, we obviously do not want the description
of a file to be generated in response to the second two
questions. These two questions are specific enough to
preclude that answer.
HELP decides which KEY WORD LIST to use by
the following mechanism. The set of KEY WORDS in
the question is searched to find the longest KEY
WORD LIST, and the message associated with this
KEY WORD LIST is used as the response. This
operation allows HELP to give the answers described
above. Assuming that the KEY WORD LIST of zero
length is always defined, and is linked to an "I don't
know" message, the only time we cannot find a longest
KEY WORD LIST in the set of KEY WORDS is
when we have two or more KEY WORD LISTS of
maximal length. In this case, we generate the responses
associated with all of the lists with this property. To
continue our example, assume the KEY WORD LIST
"close file" is also defined, and linked to the response
"To close a file use .... " Now let us see what happens
with the question "How does one open and close a
file?" The set of KEY WORDS taken from the question
is "open, close, file" . We first see if there is a defined
KEY WORD LIST of length 3 (the order of the original
set) . In this case, there is not. We will then find a
KEY WORD LIST of length 2, say, "open file", and
its response will be generated. We then find the other
KEY WORD LIST of length 2: "close file", and its
response is also generated. Now, since no other KEY
WORD LISTS of length 2 exist, and we have found
at least one of this length, we stop searching and consider the answering phase complete. Notice that if the
question was "How do I open or close?" HELP would
have output "I don't know", since out of the set "open,
close" the only defined KEY WORD LIST is the
default one of length zero.
Even though the above mechanisms are uncomplicated and make no use of word order, they allow
HELP to answer questions with great accuracy, and
little redundancy. The assumption that a longer list
of KEY WORDS in a question (i.e., more modifiers),
implies that a more specific answer is required seems to
be quite adequate in determining which answer is
desired. For an example of how a user of HELP can go
from the general question to the more specific, see
Figure 1.
Also shown in this figure is a facility in HELP which
will be described in greater detail below. It is the idea of
a "text subroutine", and it both aids the writer of a data
base and reduces the size of the HELP program. With
this facility, answers to less specific questions can be
built up out of answers to more specific ones. This is
accomplished by having a response "call" another
body of text, in much the same way as standard computer languages do. This means that body of text can exist just once, but can be used by many different answers.
HELP
549
The details of the mechanisms by which HELP
attempts to answer a question are described below.
ROOT
NODE
GENERATING ANSWERS
==> : POINTER TO RESPONSE
X: "END" FLAG SET
VALUE
We first read in the question and partition it into
words. A word, in this case, is defined to be a sequence of
non-blank characters. We then look up each word in a
hash table. If the word is found in this table (i.e., it it is a
KEY WORD), we place its index in the table into
a temporary buffer. If the word is not found, we perform
some simple spelling transformations (e.g., saves-+
save, going-+go, file.-+file, etc.), and check the hash
table again. If the word is still not found, it is completely
disregarded.
After the entire question has been reduced, the
resulting set of numbers is sorted by value. If any of
these numbers are duplicated in the list, all of the
repetitions are removed, so that we get a strictly
increasing ordered set of numbers. We now present
this set to a data structure called the ANSWER
[J2Q
L-UNK
R-UNK
nI < n2< n3 < n4
nl < n5 < nS < na
n3 < n7
DEFINED KEY WORD LlSTS={n l,n 5},{n l ,n s}, {n l,ns,n a},
{n 2},{n 3,n 7},{n41
Detin1t1ona
KEY WORD LIST
RESPONSE
FILl
Ml:
A FILl IS A COLlECTION OF DATA.
OPEN INPUT FILl
142:
USE BRS 15 TO OPEN A FILl FOR INPUT.
O~N
otrrPUT FILl
Figure 2-Answer lists
M3:
USE BRS 16 TO OPEN A FILl FOR OtrrPl1l'.
OPEN FILl
~:
[M2] [M3] (WHERE [M) MEANS A "CALL" ON
CUlSE FILl
~
MESSAGE M).
:
USE BRS 17 TO CLOSE A FILl.
15
M6:
BRS 15 OPEN FILl FOR INPUT.
BRS 16
M7:
BRS 16 OPEN FILl FOR OtrrPllr. (M8)
BRS
(~)
M8: A=CONTROL WORD, X=DUAL FILE NUMBER.
DUAL FILl NtImER
M9:
A DUAL FILl NtMBER HAS THE COW.AND INPUT
FILE IN THE rowER 12 BITS AND THE COMMAND
OtrrPtrr FILE IN THE TOP 12 BITS.
Q,uestion Phase
?WHAT IS A FILl?
A FIlE IS A COLLECTION OF DATA.
?HOW CAN I OreN A FILE?
USE BRS 15 TO OPEN A FILE FOR INPUT.
USE BRS 16 TO OPEN A FILE FOR
OUTPtrr.
LISTS, which contains all of the defined KEY WORD
LISTS and pointers to their associated responses.
The ANSWER LISTS structure is a binary tree, with
each node consisting of three fields; a LEFT LINK, a
RIGHT LINK, and a VALUE field. The VALUE
field can contain either an index into the KEY WORD
hash table, or a flag indicating that this node is an
"end of list" node. The RIGHT LINK of a node is
either null, or points to another node whose value
field is greater than itself. The LEFT LINK of a node
points to either a node whose value field is greater than
itself, a node whose VALUE field has the "end" flag
set, or a response (in the text storage table) (see Figure
2).
A KEY WORD LIST and the pointer to its associated response exists in this structure as follows.
If there are n members of the KEY WORD LIST,
there are n 1 nodes in the tree which describe it; one
for each of the KEY WORDS, and one for the "end of
list" node. Each of these nodes exists on a different
level of the tree, where level has the following recursive
definition. Level 1 is defined to be the set of those
nodes which can be reached from the root node by
following RIGHT links. For m> 0, level m+ 1 is the
+
?BRS 1,5?
BRS 15 OPEN FILE FOR INPtrr.
A=CONTROL WORD, X=DUAL FILE Nm4BER.
?TELL ME ABOtrr A DUAL FILE NUMBER?
A DUAL FILE NlMBER HAS THE COMolAND INPtrr FILE IN THE LOWER 12 BITS AND
THE COMMAND otrrPtrr FILE IN THE TOP 12 BITS.
Figure I-Definitions and output
550
Fall Joint Computer Conference, 1970
KEY WORD LIST we generated from the question
does not exist in the ANSWER LISTS structure. We
then search for pre-defined lists among the subsets of the
original list, beginning with the maximal proper ones.
If at any point during this search we find a pre-defined
list, we ouptut the response associated with it and with
all such lists of the same order, and terminate the
answering phase as above. In the event that no subset
of the given list exists in the ANSWER LISTS, a
standard "I don't know" response is generated, and
we return again to listen for the next question.
I
·CHOICE OF _ _ _
MAPPING
REGISTER
1-----1
MAPPING
REGISTERS
ADDRESS IN_
SUB-BLOCK
TEXT STORAGE
DICTIONARY
INSTRUCTION
Figure 3-Dictionary addressing
set of nodes which (a) are pointed to by LEFT links
of level m nodes and, (b) which can be reached by following RIGHT links from the nodes in (a). In other
,vords, the first node in every KEY WORD LIST is in
level 1, the second node is in level 2, etc. Now, for the
KEY WORD LIST of n members, the first member is
described by some node in level 1. The LEFT link of
this node points to a node in level 2, and the second
member of the KEY WORD LIST is in this set of
level 2 nodes (i.e., start from this node and follow
RIGHT links until the desired node is found). The
LEFT link of this node just found will point to a node
in level 3, etc. After descending n levels in this manner,
the last node of the KEY WORD LIST will be encountered. The LEFT link of this node will point to a
node with the "end" flag set, and the LEFT link of this
node will point to the response associated with the KEY
WORD LIST.
Since the nodes throughout the tree are ordered by
value, the algorithm for deciding if a list of KEY
WORDS is a defined KEY WORD LIST is quite
simple, and requires very little time to compute. A
failure exit is caused if and only if either a null pointer
is encountered when traversing RIGHT links, or an
"end" node is not encountered when the entry list is
exhausted.
If the KEY WORD LIST constructed from the
question is, in fact, a pre-defined list, we will find it in
the above structure and will reach an "end of list" node.
This node contains an identification of the appropriate
response to be generated. In this case, the question has
been answered successfully, so we go back to listen for
another question. However, let us assume that the
Since the size of the HELP program was a consideration, we elected not to store the text of the
responses literally. Instead, we utilize a dictionary and
have the response which is stored in HELP be a sequence of calls on that dictionary. Our dictionary can
contain a maximun of 2048 (text) words, while the
address field of the dictionary reference instruction
only allows for specifying one of 256 words. Therefore
to allow any word in the dictionary to be referenced, we
separate the instruction operand address into two
fields. One of these fields specifies one of four "mapping
registers," while the other field designates one of 64
words in a dictionary sub-block (see Figure 3). The
four mapping registers are given initial values at
the start of the text output phase, and instructions
exist to change their contents when necessary. Experience with several HELP programs has indicated
that the map change instructions account for only 3
percent of the total number of instructions in the text,
so this device significantly reduces the size of the transformed text.
In addition, we introduced the subroutine facility
to allow a body of text to be associated with two or
more responses, with virtually no increase in storage
space. Consequently, the internal structure of the text
which in output in response to a question is not a string
of characters, but a sequence of instructions in a simple
language (see Figure 4). As can be seen from this
figure, these instructions can be divided into several
classes (i.e., use word n from the dictionary, output a
single character, end the message, call another body of
text as a subroutine, etc.). We have found that transforming the text in this manner also considerably reduces the space needed to store the responses. The
SDS 930, for which this program was written, has a
user address space of 16K 24 bit words. The entire
HELP program resides in this space and can contain
the equivalent of from 30 to 40 printed pages of text,
enough to entirely describe the user interface of our time
sharing system.
HELP
ADDITIONAL STRUCTURE
Since natural languages contain synonyms, a method
of defining equivalences between words was built into
HELP. This facility allows us to equate not only one
word with another, but also sets of words with each
other. When we say equate, we mean that HELP will
respond with the same answer no matter which of the
words of a synonym equivalence class is used. For example, we might cause "run" and "execute" to be
synonyms, so that the two questions "how do I run a
program?" and "how do I execute my program?"
will elicit the same response. As another example,
suppose we want the key word "help" to cause an
explanation message to be generated. In addition, we
want anyone of the words from the set: "exit, finished,
goodbye, stop" to cause HELP to return to the TSS
executive. As above, the KEY WORD LIST consisting of "help" would point to the desired message,
and the words "finished", "goodbye", and "stop"
would be equated to "exit". "exit" would, in turn,
indicate to HELP to stop its execution (see below).
TAG
OZZ
MEANING
xxx xxx
Dictionary entry preceeded by a blank..
map to be used.
ZZ =
Map contains high order 5
bits of dictionary address, XXXXXX are low
order 6 bits.
100
AXX XXX
Alpha. character or multiple blanks.
A=l ==> preceed by blank..
X>5 : X+33b=character .
x<6:
101
AXX XXX
X=# of blanks.
ASCII character or control.
A=l ==> preceed by blank..
0<=X<=15 :
X=character.
16<=X<=22: X+lO=character.
23<=X<=27: X+36=character.
110
AXX XXX
x=28:
Text subroutine return.
X=29:
End partial message.
X=30:
suppress blank before next entry.
X=31:
CR, LF.
Digit or common 2&3 letter words.
A=l ==> preceed by blank.
O<=X<=1,5 :
III
PQR XXX
MOPrBL+X=WORD address.
16<=X<=25 :
X=digit.
26<=X<=31:
MOPrBL+X-10=WORD address
Control
X=l: Text transfer.
entry (9 bits».FQR
New address=(next
X=2:
Text subroutine call
x=4:
Change map QR to field of next entry
x=6:
Subroutine call on undefined text
Figure 4-Format of 9-bit instructions for text storage
551
A problem has now been created. If a user asks the very
natural question "How do I stop HELP?" he will receive the answer about how to use HELP in addition to
terminating the program. Presumably this is not what
he wanted. The solution to this problem is to define
the KEY WORD LIST "exit help" to be a pseudosynonym of the KEY WORD LIST "exit." Now, when
the same question is asked, "stop" ,vill be reduced to
"exit," "exit help" will be reduced to "exit," "exit"
,vill terminate HELP, and no message
be generated.
In the sme way, many multi-word KEY WORD
LISTS can be equated to one another, with the resulting
desired reduction.
The synonym facility is implemented by using the
same ANSWER LISTS structure described above.
In the case of a synonym, the terminal node of a
KEY WORD LIST path in the tree indicates that the
list in question is equated to a certain node in the tree,
and does not point to a message.
There exists another piece of machinery in HELP
which has been quite useful. All of the responses which
can be pointed to by KEY WORD LISTS do not have
text associated with them. Some number of them (10
in particular) indicate to HELP to perform some
"special action." One special action is to terminate the
program. So, as above, saying "goodbye" to HELP
will cause the user to exit from HELP. Another special
action is to commence execution of another HELP
program, and have the ensuing questions directed to it,
rather than to the original program. This facility is
helpful for two reasons. First, the total amount of information about the entire system is too large for one
HELP data base. Even if the capacity of the data
base were expanded, problems of ambiguity would
arise owing to the context dependency of the questions.
Second, since different areas of the system are maintained by different people, it seemed advisable to have
the HELP programs also maintained separately, so
that one area could be modified without global repercussions. With this mechanism, any HELP program
can call any other HELP program. -A user therefore has
immediate access to all information about our system,
with very few contextual problems arising.
As mentioned above, a question can elicit more than
one response if it contains more than one KEY WORD
LIST of the same length. If a user asks a question of
this type, pressing a break key (rub out , in our case)
during the output of any of the several messages will
stop just that message. Output will then continue with
the next message in the sequence. This feature has
proved to be quite convenient, especially in the case of
long, multi-part answers where the user only wants to
see one part of each.
".ill
552
Fall Joint Computer Conference, 1970
TEXT
FILE
I
I
I
I
I
I
I
I
I
I
I
Produces
QAS
CONSOLE
CONSOLE
UNANSWERED
QUESTIONS FILE
Figure 5-QAS and HELP
concerns the KEY WORD hash table. The algorithm
which we use to construct a hash code from a word in
the question guarantees that all words of less than 6
letters will transform uniquely (we transform the
word into base 26 representation). Also, since the hash
code is 24 bits long, while the hash table has room for
only 2 i 10 entries, the probability that two arbitrary
words will have the same hash code is quite small. We
therefore do not check to make sure that a word whose
hash code we find in the table is, in fact, the word we
want. We make the assumption that if we find a word's
hash code, we have found the word. This obviously
reduces storage, since we do not have to retain the words
themselves.
This last mechanism might seem strange, but we
felt that since this was only a question answering
facility and not, say, an assembler, we could exist with
a small amount of inaccuracy. Our experience has
shown that errors due to recognizing the wrong word
almost never occur, and that when they do, only cause
extra answers to be generated (due to recognizing an
undefined word as a KEY WORD).
C01\1PACTING DATA
CREATING A HELP PROGRAIVI
As we have discussed earlier, an important criterion
in the design of HELP was to keep its size small. Some
of the methods used have already been presented
(encoding the text into a sequence of interpreted
instructions and mapping the dictionary references).
There are also two more which will now be shown. The
convention we made concerning the dictionary was
that it would contain words of only two or more
alphabetic characters. Now, in the SDS 940, all of the
alphabetics have an internal representation of 32 or
greater. Therefore, by subtracting 32 from the last
letter of each word, we compacted the words as densely
as possible and were still able to know the locations of
the word boundaries. However, this scheme by itself
would be quite inefficient, since half of the dictionary,
on the average, would have to be counted through to
find a word. Accordingly, we have a DICTIONARY
ADDRESS TABLE of 64 entries, each of which points
to the start of a 32 (text) word block. To locate a word
in the dictionary, the high order 6 bits of the dictionary
address are used to select one of the entries in the
DICTIONARY ADDRESS TABLE. Starting from
this location in the dictionary, the nth word we encounter is the word we want, where n is the lower order 5
bits of the dictionary address. In this manner, the
dictionary is as compact as possible, and the time to
find a word is not astronomical.
The second method of reducing storage in HELP
We now describe the machinery by which a user may
create a question answering (HELP) program. Each
such program contains the code for execution and the
data base, unique to it, which indicates KEY WORDS,
text to be output, and the relationships between KEY
WORD LISTS and that text. The means of defining
these objects (i.e., creating a data base) is another
program, denoted QAS, for Question Answering
System. In QAS, a user can define KEY WORDS and
KEY WORD LISTS, can define responses to be typed
out, can associate these responses with KEY WORD
LISTS, and can create his particular HELP program.
He can also discover what objects have already been
defined, what synonym relationships exist, the size
of the various internal tables, etc. In other words, QAS
is designed to allow a person to interactively construct a
HELP data base, defining and redefining objects as he
sees fit (see Figure 5). A brief description of some of the
operations which can be performed in QAS is given
below.
1. Define a KEY WORD LIST and the named
response which is associated with it.
2. Define a named body of text.
3. Define a KEY WORD LIST equivalence class.
4. Define a KEY WORD LIST which will take one
of the "special actions" described above.
5. Edit a named response.
HELP
6. Ask for the HELP program associated with
QAS, to ask questions about QAS.
7. Investigate the size of various tables.
8. Redefine a KEY WORD LIST.
9. Given a word, determine which KEY WORD
LISTS it is a member of.
10. Given a word, determine what synonym relationships exist between it and any other words.
11. Given a list of words, determine which of its
subsets are KEY WORD LISTS.
12. Given the name of a message, determine which
KEY WORD LISTS point to it.
13. Take the input from a file, instead of from the
console.
14. Write the dictionary on a file.
15. Create the HELP program.
553
SYNONYMS.
INPUT
READ
NUMBER
NO.
NUMBER
NO
As indicated above, each body of text given to QAS
must have a name attached. The pupose of this name is
to allow for the subroutine facility described previously.
The inclusion in a body of text of the name of another
body of text will cause the second body of text to be
inserted during message output. This second body of
text can, in turn, "call" another, etc. An example of the
input given to QAS can be seen in Figure 6.
From Figure 6 we see that the structure of the input
presented to QAS is in the form of "commands",
followed by the arguments for the command. For
example, the command, ANSWERS, haS' as its arguments a KEY WORD LIST, a text name, and a body
of text. This command will, after receiving the arguments, define the KEY WORD LIST, compile the
body of text into its internal form, associate the name
given with the body of text, and cause the newly-defined
KEY WORD LIST to point to this text. Another
command, KILL KW LIST, will erase the pointer
from the given list to a response or a synonym. This
allows us to redefine a list if the original definition was
faulty.
Figure 6 also shows the power· of the subroutine
facility. We can define the answers to specific questions
by giving the text to be output. We can then build up
the responses to the more general questions by utilizing
calls on the more specific text.
QAS has proved to be a very powerful tool for the
creation of a HELP program. Using it, a person can
construct a preliminary HELP for, say, our test editor
in a few hours. Then, after other users have tried it and
asked questions which the writer did not anticipate,
QAS can be used again to modify the data base. To
facilitate this procedure, the writer can tell QAS, during
the creation of HELP, to have HELP write on a file
all the questions it cannot answer. The wTiter can then
our PUT
WRITE
ANSWERS.
FILE
[FILE ]
A FILE IS A COLLECTION OF DATA.
OPEN nlPUT FILE
[OIF]
BRS 15 IS USED TO OPEN A FIlE FOR mpl1r.
OPEN OurPUT FILE
rOOF]
BRS 16 IS USED TO OPEN A FILE FOR ourPUT.
OPEN FILE
[OF]
[OIF] rOOF]
INPtJr NUMBER
[ INNUM]
BRS 36 IS SUED TO INPUT A NUMBER.
Figure 6-Format of input to QAS
554
Fall Joint Computer Conference, 1970
4HELP.
TERMINATE QUESTIONS
wiTH A '1'.
QUESTIONS ABOtJr MATERIAL IN R-2!.
THIS VERSION OF HELP WILL ANSWER
TO LEARN MORE ABOUT THE USE OF
(11/'Zl/68)
HELP, TYPE "HELP?".
?HOW CAN I READ THE LENGTH OF A FIlE?
USE BRS 143 WITH ATTRIBtJrE NtMBER 2 TO READ THE IENGTH OF A FIlE.
HELP receives a great deal of use, generates useful
answers, and, using QAS, can easily be updated to allow
for modifications and oversights. Figure 7 gives an
example of a short session with HELP.
CONCLUDING COl\1MENTS
?TELL ME ABOtJr BRS 143?
READ STATUS.
BRS 143:
THE CALLING SEQUENCE IS:
A:
TABlE ADDRESS OR DATA (DEPENDS ON
X:
THINGY NUMBER
B:
DECODES AS FOLLOWS
a,S).
IF A TABlE ADDRESS, A is
INCREMENTED TO POINT TO ONE PAST THE LAST WORD TRANSFERRED.
BIT ~: ~ IF A HAS DATA, 1 IF A POINTS TO A TABLE
BITS 1-11:
'TYPJo;' OF THINGY
BITS 12-23: 'ATTRIBtJrE'
'TYPE' IS 1 FOR A DRtJoi FILE, 2 FOR A JOB, FOR DETAILS SEE PAGE 9-2
IN R-2L
?WHAT IS A THINGY?
A "THINGY", AS USED IN BRS 143 AND 144, IS EITHER A FIlE OR A JOB.
?HOW CAN I OUTPtJr A STRING?
USE BRS 35 TO OUTPUT A STRING.
?MORE ON BRS 35?
BRS 35: OtJrPUT STRING.
X=FILE NUMBER, AB=STRING POINTER.
The algorithm which we use to find KEY WORD
LISTS from the set of KEY WORDS in a question has
one drawback. If the number of KEY WORDS in the
question is large, while the length of the longest KEY
WORD LIST ill the set is small, the searching time is
very long. This is due to the fact that, starting from the
original set, we check every subset. We have never
experienced a problem of this sort, since most of the
questions presented to our HELP systems have three or
less KEY WORDS. However, it is a possibility. To
solve it, a test would have to be made before starting
to check the subsets of a given order, to insure that the
number of these subsets is less than some pre-determined maximum. If not, all of those subsets would
not be tested. The calculations involved are trivial, and
could be incorporated if necessary.
?BRS 2 3?
BRS 2:
EXEC ONLY
CLOSE SPECIFIED FILE
A=FILE NUMBER.
NON-EXEC IS BRS 2~.
BRS 3 DOES NOT EXIST
Figure 7-A session with HELP
investigate this file occasionally to discover what he
has overlooked.
It is also possible to have HELP write on a file all
of the questions which it receives. In this way, we can
determine how much use a particular HELP system is
getting, and how well it is doing. Our experience at
Project Genie is that our efforts· in designing a simple
question answering facility have been successful.
ACKNOWLEDGl\1ENTS
The author would like to acknowledge the help of both
Bret Huggins and Butler Lampson. Mr. Lampson
designed the initial structures of the ANSWER LISTS
and the dictionary, and Mr. Huggins implemented
them. In addition, both contributed many hours of
their time to discussions during all phases of the
design of HELP and QAS.
REFERENCE
1 C S CARR
HELP-An on line computer information system
Project Genie Document No P-4 January 19 1966
CypherText: An extensible composing
and typesetting language
by
c.
G. IVIOORE and R. P. IVIANN
The Cyphernetics Corporation
Ann Arbor, Michigan
INTRODUCTION
CypherText is a programming language designed for
text formatting and typesetting in a time-sharing
environment. Text to be formatted or typeset is input
on a terminal and may be output at the terminal or on
various typesetting machines.
Although a number of computer typesetting languages
have been written for particular applications (such as
newspaper work), few of these languages are adaptable
for any other application. 1 , 2,3 This inflexibility has
remained one of the most serious limitations of existing
computer typesetting languages.
CypherText, an extensible language, overcomes this
problem of inflexibility to a great extent. Because
CypherText is truly extensible, it is possible to tailor
specific formatting capabilities to meet the needs of
particular typesetting applications by predefining formats for each application. Both .large scale projects
such as catalogs and parts lists, as welJ as smaller
operations, such as job-shop typesetting, may now be
accommodated within the scope of one language.
By predefining form9,ts, a set of format definitions for
a specific application may be "packaged" so that the
definitions come "ready to use," i.e., the user does not
have to know anything about how to make up formatting definitions for himself. This "packaging" of
formats has already been accomplished for architectural
specifications, technical report writing, and job-shop
typesetting applications. In the first two cases, the
format definitions are so comprehensive that the user .
almost never requires any of the unextended features
of the language. In fact, most users are unaware of the
"unpackaged" features because the packaged definitions
meet all their formatting requirements.
In addition to providing wide formatting flexibility,
CypherText also provides flexibility in choosing typesetting devices on which the text is to be output. Other
typesetting languages have typically been geared to one
555
or a few specific typesetting machines. CypherText, on
the other hand, is "device independent": a "postprocessing" feature allows users to set their text on
many commercially available typesetting devices,
including photocomposition devices, "hot lead" devices,
and even typewriter-like terminals, with no change
required in the input text.
The extensibility of CypherText and the flexibility it
offers derive from the structure of the language and the
method of its use.
THE STRUCTURE OF CYPHERTEXT
The major structural features of CypherText are its
command syntax, command definition capability, and
string storage capability.
Syntax
One prerequisite of an extensible typesetting language is an unambiguous syntax. Every effort has been
made to keep the CypherText syntax simple and
consistent.
CypherText input consists of the text to be typeset
and the formatting instructions for the text. The
formattjng instructions ("commands") are distinguished
from the text by "command break characters." Though
the command break character may be any character the
user chooses, throughout this paper the slash U) will be
used. The following fragment of input shows some text
and one command:
as shown on the following page/NEXTPAGEl
In the above example, the text "as shown on the
following page" would be set on a particular page, after
which the command "NEXTPAGE" would cause any
subsequent text to be set on the next page.
More than one command may be placed within the
556
Fall Joint Computer Conference, 1970
break characters, provided that the individual commands are separated by semicolons, as in the following
example:
as shown on the following page./NEXTPAGE;
CENTER/Chapter VI
In this example, the two commands "NEXTPAGE"
and "CENTER" are placed within the same set of
slashes; "NEXTPAGE" causes a skip to the next page,
after which "CENTER" causes the text "Chapter VI"
to be centered at the top of the new page.
Some commands require one or more modifiers
(parameters) to fulfill their formatting functions. In
these commands, the parameters are separated from the
name of the command by a space, and multiple
parameters are separated from each other by commas.
For example, the command "SPACE" requires as a
modifier the amount of vertical space to be left on a
page, expressed in points. Thus, the command
/SPACE 24/
causes a vertical spacing of 24 points.
Among the commands requiring multiple parameters
is "NEWTYPE", which has as modifiers the name,
style, and point size of the type face to be set. Thus,
/NEWTYPE TIMES ROMAN,8/
would cause a switch to 8 point Times Roman as the
current type face.
A list of the most commonly used CypherText
commands and their functions is provided in Table 1.
Command definition
The capability of defining new commands is integral
to the extensibility of CypherText and contributes
greatly to its ease of use.
New commands are created by combining a number
of basic commands and assigning a name to the
combination. The name is assigned by means of the
"DEFINE" command. In the following example, a new
command called "PT", requiring one parameter,
"LINES", has been defined. The definition of the
command appears between the quotation marks, and
consists of three basic commands: SKIPIF, NEXTPAGE, and ENDIF:
/DEFINE PT(LINES),
"SKIPIF<,72, LINES *12;
NEXTPAGE;ENDIF" /
Having defined the new command "PT(LINES)", it
would be used by supplying a value for the parameter
TABLE I -Commands
DEFINE
Used to define a new CypherText command. It gives a name to
the command and indicates how the parameters are to be used.
ENDIF
(See SKIPIF)
EVALUATE
Evaluates an arithmetic expression and stores the value in a
specified string name.
INCLUDE
Requests that the contents of some string (or combination of
strings) be set as text at this point.
Requests that a 'leader' of some particular character be used to
fill out the current line of text. Used mostly in tables.
MAP
Gives a character whose occurrence is to be 'mapped' into some
string. Every subsequent appearance of the mapped character
will be treated as though the string of characters it is mapped
into had occurred instead.
NEXTPAGE
NEXT PARAGRAPH
NEXTFIELD
Cause a new page, paragraph, or field (respectively) to be started
at this point.
OUTPUT
Specifies the output device to be used for setting the text (for
example, LINOFILM, PHOTON 713, terminal, etc.)
PUSH
POP
Together, allow the current contents of some string to be saved,
and then later recovered.
SET
Assigns a new value to some string. Corresponds to the use of
the equal sign (=) or replacement operator in most programming
languages.
SKIPIF
Allows commands and text to be skipped (or ignored) in the
setting process, if a specified condition is met. No text will be
set or commands processed until an ENDIF command is encountered.
SPACE
Leaves a vertical space of the specified amount, on the page
currently being composed, at the point the command occurs.
USE
Gives the name(s) of one or more files whose contents are to be
included as input at this point. These files may include commands
or text or both.
CypherText
"LINES". For example, the command
IPT lSI
would cause any text following the command to be set
on the current page if more than 15 lines remain, or to
be set on the next page if less than 15 lines remain.
557
Stored strings may also be used in a way analogous to
the use of variables in algebraic programming languages. Thus, stored strings may be used in an arithmetic expression, as a parameter to a command. For
example, the sequence
ISET LINES, "12"1
String storage
The capability of assigning names to strings of
characters and of storing the strings for future use is
also crucial to the extensibility of CypherText. Strings
are assigned names and stored for retrieval by means of
the "SET" command. For example, the command
ISET X, "NEXTPAGE" I
would store the 8-character string "NEXTPAGE"
under the name "X".
Such stored strings may be used as commands,
parameters to commands, or even as text to be set. For
example, after the above command, the command "X"
is equivalent to the command "NEXTPAGE."
D sing stored strings as commands or as parameters
to commands merely involves substituting the string
name for the string. For example, the sequence
ISET LINE, "12"1
ISPACE 5*LINES/
causes a vertical space of 5 times the number of points
specified in the string named "LINES" to be left on the
current page.
Reserved String N aInes
1\1any of the formatting functions of CypherText are
controlled by the use of "reserved string names". These
are string names whose contents are constantly
monitored by CypherText. Whenever the value of one
of these reserved strings is changed, CypherText takes
some special action. For example, the reserved string
variable "LINELEADING" indicates the amount of
space to be left between each line of the final text.
Changing the value of this string will change the amount
of space left between lines. Thus, the command
ISET LINELEADING, "12" I
ISPACE LINEI
stores the value "12" under the name "LINE", so that
when "LINE" is used as a parameter to the "SPACE"
command, a vertical spacing of 12 points is left on the
page.
D sing stored strings as text to be set involves the use
of the "abbreviation character." Though this character
may be any that the user chooses, in the fol1owing
example the "at sign" (@) has been used.
Commonly used words, phrases, or paragraphs may
be assigned string names and stored; whenever the
words, phrases, or paragraphs are to be used as text,
only the string name need be used, preceded by the
abbreviation character. For example, the command
SET CT, "CypherText,
an extensible language,"
would store the quoted text under the name "CT".
Whenever the user wants to include the text "CypherText, an extensible language," he has only to type in
"@CT". In this case, 35 characters have been reduced
to the 2-character abbreviation "CT".
indicates that from this point on, 12 points of space are
to be left between each line in the output text. For
typewriter-like terminals, this command is effectively a
double-space command. As another example, the
formatting of the top and bottom of each page is
controlled by two reserved string names, "HEADER"
and "TRAILER". Any combination of commands and
text may be stored in these strings. Whenever CypherText begins a new page of text, it examines the contents
of these strings to determine what to place at the top
and bottom of each page. For example, the command
ISET HEADER,"/SPACE 36;CENTER;INCLUDE
TTEXT; SPACE
36/"1
stores in the reserved string "HEADER" a set of
commands which will center at the top of each page the
current contents of the string named "TTEXT", with
36 points of space between this line and the top of the
page, and 36 points of space between this line and the
first line of text. Of course, the contents of the string
"TTEXT" may be changed at any time, via the "SET"
command. Thereafter, each page will have the new
contents of "TTEXT" as a centered title.
558
Fall Joint Computer Conference, 1970
TABLE II-Reserved Variables
PAGEHEIGHT
Controls the height of each page.
set so far during a particular run. The value stored in
"TOTALPAGES" may be conveniently used to set a
page number on each page.
Many of the defined string names are used primarily
for testing certain conditions. The defined string name
P AGELEFT contains the number of points (vertically)
left on the current page, before it will be necessary to
start a new page. Before beginning the setting of a table
in his input text, a user may embed a conditional skip
command ("SKIPIF") in his input which will test
PAGELEFT to determine if there is enough room on
the current page for the entire table. If there is not
enough room, CypherText will start a new page; if there
is enough room, the table will be set on the current page.
A list of the most commonly used defined string names
and their functions is given in Table III.
l\1:any other features of CypherText, such as automatic justification and hyphenation, are not discussed
here because they are available in other languages as
well. 4,5,6 The primary emphasis here has been to
illustrate the extensible features of CypherText, particularly those features which differentiate it from other
typesetting languages.
PAGEWIDTH
Controls the width of each page.
USING CYPHERTEXT
FIELD
Controls the number, width, and placement of columns on the
page. Also controls the placement of text within the field:
centered, justified, flush right, flush left.
HEADER
Controls the formatting of the top of each page. Title, if any,
spacing, and so forth.
HYPHENATION
Controls automatic hyphenation, which is done only if the
contents of this string name is "ON".
INDENT
Specifies the amount of the indentation at the beginning of each
paragraph.
JUSTIFICATION
Controls the amount of 'filling' with spaces allowed to justify a
line of text.
LINELEADING
Controls the amount of space to be left between lines.
PARAGRAPHLEADING
Controls the space to be left between each paragraph.
TRAILER
Controls the formatting of the bottom of each page, as with
HEADER, at the top.
TYPEFACE
Controls the current type face (TIMES, BODONI, etc.).
TYPESIZE
Controls the current type size.
TYPESTYLE
Controls the current type style (ITALIC, BOLD, etc.).
A list of the most commonly used reserved string
names and their functions is given in Table II.
Using CypherText to transform original copy into
finished text is a five step process:
1.
2.
3.
4.
5.
Embedding
Inputting
Proofing
Postprocessing
Typesetting
Embedding is the insertion of CypherText commands
into the original text. The commands may be written in
by an editor for later inputting by a typist, or, in the
case of experienced users, the commands may be
embedded extemporaneously as the text is being input.
The following example shows an original manuscript
with the commands embedded by an editor:
Defined String N allles
"Defined string names" is another class of string
names which has special meaning to CypherText. These
are strings which the user may always assume to
contain some particular piece of information. Whenever
the user references one of the defined string names,
CypherText determines the current value of that piece
of information and supplies that value as the value of
the string. For example, the defined string name
"TOTALPAGES" always contains the number of pages
/~''l.-/
/~fA- /l1iJ.lIlYrICA-J {JOl-0J
CYPHERTEXT: A DEt40NSTRATION
0./
~
~I
/s~ /~; ~ATI;4feS, t(o/'1AIII,. /Cj ~.
~CypherText
enaoles you to transform unformatted rough copy
into finished text by embedding CypherText commands in the
rough copy.
~The CypherText commands provide for all
the formatting
requirements of the printed page, including justification,
hyphenati on, tabulation, I eaderi ng, and runarounds.
CypherText
In this example, the commands specify that the
heading is to be centered and set in 12 point Helvetica
Bold, while the two paragraphs are to be set in 10 point
Times Roman. (Note that the command for starting a
new paragraph has beeh abbreviated to "#".)
After the commands have been inserted, the "embedded copy" is input into a general purpose timesharing system on virtually any terminal input device.
Several advantages derive from the fact that the copy
is entered into a time-sharing environment: first, the
copy may be stored on any of a number of direct-access devices, depending on factors of economy and convenience; second, output from other programs in the
time-sharing system may serve as input to CypherText;
and third, the copy is always immediately accessible
for updating.
The following example shows how the embedded copy
would appear on a terminal during inputting:
output. However, for many applications, the proof copy
obtained at the terminal is satisfactory enough to serve
as final output for reproduction by printing or other
means. For these applications, where limited type
variety and non-proportional spacing are of no concern,
the proof copy is the end product of the CypherText
process and the last two steps, postprocessing and
typesetting, are omitted.
Whether or not the proof copy is the final output,
proof copy is useful for checking the formatting and for
catching typographical errors. If errors are found, or if
the formatting is to be changed, it is a simple matter to
edit the input copy by using any of the text-editing
facilities of the tjme-sharing system. After the copy is
edited, further proofs may be output until the user is
satisfied that the text is composed as desired.
The following example shows proof copy obtained at
a model 37 teletype terminal:
CYPHERTEXT:
/center/
/NE\lTYPE HElVETICI',80U' ;12/Cypt-lERTEXn: /& DEMONSTRATION
/ space 12; tlEI'ITYPE TIMES, RfH,/&N, 10 ;'TEXT /
*CypherText ena~les you to transforr' unformatted
rough cory IntC' flnlshprl text t-y el"!t->etitiin,.
CypherText co~rAntis in t"~ rou~h copy.
*T~e CypherT~xt conrAn~s provlrle for all the
for~attln~ r~culr0rnents of the prlnt~~ page,
Includln~ justification, "ynt-enatlon, tabulation,
leaderlng, ~n~ run~rou~r1s.
READY
After the copy has been input, immediate proofs may
be obtained by having the system compose and print
out the text at the terminal. Of course, the proof copy
takes on the limitations of the terminal on which it is
TABLE III- Defined Variables
DATE
Current data, in the form DAY-MONTH-YEAR.
LINECHARACTERS
Current number of characters set so far on this line.
PAGED OWN
How much text has been set on this page, i.e., how far 'down'
the page text has been set.
PAGELEFT
How much space is left on the page, vertically, before it will be
f.ull.
PAGELINES
How many lines have been set on the page currently being
composed.
TIME
Current time of day, in the form HH:MM (24-hour time).
TOTALPAGES
Total number of pages set so far in this run.
559
A
DEMONSTRATION
CypherText enable. you to transform unformatted
rough copy into finished text by embedding CypherText
command. in the rough copy.
The CypherT8xt command •. provide for a 11 the
formatting requirements of the printed page, including justification, ~phenation, tabulation, leadering, and runaround ••
For those application~ where a variety of type faces
and proportional spacing are important, the next step is
to postprocess the input copy for setting on a particular
typesetting device. Postprocessing is handled automatically by the system, producing a tape (paper or
magnetic) to drive any of the most commonly used
typesetting machines.
To achieve complete typesetting flexibility, the
CypherText language has been made as "device
independent" as possible. This independence has been
achieved by defining the input language independently
of the characteristics of any specific typesetting device;
the output is targeted to an idealized typesetting device
(which does not actually exist). Producing output for an
actual typesetting device is the function of the postprocessing program, which translates the device independent output to the particularities of the desired
typesetting machine. Translating the copy for typesetting on different machines requires only a change in
the "OUTPUT" command, which takes one parameter,
the. name of the desired typesetting machine. The
"OUTPUT" command is also used for obtaining drafts
at the terminal, typewriter-1ike devices being considered
a special kind of typesetting machine. The device
independent translators generally run in parallel with
the CypherText language itself, as co-routines, effectively making the entire process a one-pass operation.
The final step, typesetting, consists of running the
postprocessed tape on a particular typesetting machine
to obtain finished, typeset copy. The number of type
560
Fall Joint Computer Conference, 1970
faces and sizes, as well as the spacing characteristics,
depend, of course, on the typesetting machine itself. The
following example shows the sample text set on a
Linofilm Quick:
CYPHERTEXT: A DEMONSTRATION
CypherText enables you to transform unformatted
rough copy into finished text by embedding CypherText
commands in the rough copy.
The CypherText commands provide for all the
formatting requirements of the printed page, including justification, hyphenation, tabulation, leadering, and runarounds.
Although CypherText can be used in any composing
and typesetting application, it is especially suited for
text requiring frequent revision, complicated or repetitive formatting, and high speed and accuracy. Despite
the sophisticated capabilities of the language, experience
has shown that both novices and trained editors alike
can be taught to use CypherText easily and effectively
in a broad range of composing and typesetting
applications.
APPENDIX A
SYNTAX OF THE LANGUAGE
Normally CyperText operates in "text mode", a
mode in which the characters in the input stream are
simply set according to whatever current formatting
parameters are in effect. Commands which alter the
formatting parameters may appear anywhere in the
input text stream. These commands are bracketed by
the current "command break character", which is
normally a slash(j). One or more commands placed
between command break characters in this manner is
called a "command group", and must follow certain
syntactical rules.
The syntax of a command group is given below.
Rigor in the formal sense has been sacrificed for
readability. Such sacrifices are indicated by enclosing
parentheses. In the definitions we use the convention
that lower case character strings stand for a generic
type. Upper case strings and punctuation characters not
mentioned in these conventions must appear as shown.
Square brackets surround optional material. Three dots
fol1owing a syntactic unit indicate that it may be
repeated an arbitrary number of times. The sequence
, : =' is used to mean 'is defined as'. A vertical bar is
used to indicate that one of the options in curly
brackets should be chosen. Curly brackets are also used
to group syntactic units for some purpose. The special
generic name 'nullstring' and 'blankstring' stand for a
string of no characters and a string of one or more blank
characters, respectively. The generic name 'alphanumericstring' stands for an arbitrary string of upper
and lower case letters and numbers. The generic name
'numericstring' stands for a string of digits, possibly
with a leading plus or minus sign, and an optional
embedded decimal point.
commandgroup : = commandbreakcharacter
commandstring
commandbreakcharacter
commandstring : = [commandelement;].··
commandelement
commandelement : = {primitivecommand 1
macrocommand
stringname 1 nullstring}
primitive command : = (one of the commands from
Table I) blankstring parameterlist
macro command : = macroname blankstring
parameterlist
stringname : = alphanumericstring (of length less than
64 characters, beginning with a
letter, and which has previously
appeared as the first parameter of a
SET or EVALUATE command).
macroname : = alphanumericstring (of length less than
64 characters, beginning with a letter,
and which has previously appeared
as the first parameter of a DEFINE
command).
parameterlist : = [{ (parameterlist) 1
simpleparameter} ,] • .•
{(parameterlist) 1 simpleparameter
1 nullstring}
simpleparameter : = {alphanumericstring 1
stringexpression 1
numericexpression}
stringexpression : = {stringname 1 quotedstring}
[& stringexpression]
quotedstring : = "alphanumericstring" 1
'alphanumericstring' }
numeric expression : = {numericstring 1 stringname}
[arithmeticoperator
numeric expression]
arithmeticoperator : = {+ I-I*I/}
1
APPENDIX B
Implementation details
CypherText has been implemented for a PDP-10
time-sharing system. It is written entirely in assembly
CypherText
language. This choice was dictated by the fact that the
only other option available at the time was FORTRAN.
FORTRAN was felt to be too awkward and inefficient
to use as an implementation language for what is
essentially a string-handling program. It should be
noted that higher-level languages available on other
computers (such as PL/1) would be unquestionably
preferable for implementing this type of program.
The programs, both first and second passes, are
reentrant. In fact, the PDP-10 system allows the first
pass to be shared simultaneously by a number of
time-sharing system users. The first pass program
occupies about 6500 (36-bit) words of memory for the
code. A minimum of 6000 additional words are needed
for working storage (page buffers, string storage, etc.).
The size of the second pass programs, which are
usually loaded with the first pass for a particular run,
varies considerably with the type-setting device selected. All the current second pass programs are less
than 2000 words long, including both code and working
storage.
The device independence of the PDP-10 input/
output support allows input text to be accepted from a
variety of media. The same comment applies to system
output. No scratch files are written by the system, but
CypherText does access several support files in the
course of a run, which must be stored on a random
access device.
561
The running time of the program varies with the
number and complexity of the commands embedded in
the text. For "straight matter", such as non-technical
books, running time for first and second passes combined is about .3 seconds per 1000 characters. For very
complicated work, such as some parts catalogs, run
time may approach 2 seconds per 1000 characters.
Unless final copy is being printed at the terminal,
additional time will be needed on the type-setting
device chosen to set the text.
REFERENCES
1 G M BERNS
Description of FORM AT, a text processing language
Comm of the ACM Vol 123 March 1969 pp 141-146
2 TEXT360: Introduction and reference manual
Form C35-0002 IBM Technical Publications Dept White
Plains N Y March 1969
3 Harris Composition System: Language manual
Harris-Intertype Corp Cleveland Ohio March 1970
4 Textran-2: User's manual
Form T2-102-3 Alphanumeric Inc Lake Success N Y 1969
5 J W SEYBOLD
The market for computerized typesetting
Printing Industries of America Washington D C 1969
6 HYPHENATION360: Application description
Form E20-2130 IBM Technical Publications Dept White
Plains N Y 1969
Integration of rapid access disk Illemories
into real..time processors
by R. G. SPENCER
Bell Telephone Laboratories, Incorporated
Naperville, Illinois
speed random access stores. This disk complex is also
well-suited as a low-speed data buffering memory for
data links or analysis information.
INTRODUCTION
In large real-time systems such as telephone, traffic
control, and process control, the required amount of
high-speed random access memory becomes cost prohibitive. In these types of systems, much of the data
stored in memory is accessed infrequently. For such
low priority data, a rapid access disk or drum memory
controller can be used to advan~age; such a controller
is described in this paper.
In a real-time processor, the multiprogram environment generally consists of two types of programs. The
first type is event-associated and is executed only
when a specific event occurs. The second type is a
routinely run program. The event-associated programs,
typically the high runner programs, use the largest
percentage of the processor real time. If the required
response time for an event is greater than the average
latency of a rotating memory, data pertinent to each
event can be stored on a disk file. Upon demand, an
autonomous disk controller delivers data to the system.
A program requests a block of data from the controller, and instead of waiting for the disk controller
to deliver the data, the program exits to an executive
program. The executive program calls another program
to be executed. When a disk task dispenser program
finds a request for data completed, it returns control
to the program requesting the data. With this mode
of program flow, many disk requests for data can be
operated concurrently. With :::t large queue of random
requests, the disk controller can execute a job at most
positions on the disk as it rotates. Thus, the throughput
of the disk controller can approach the data rate of
the disk.
A disk controller system can serve as a memory for
many other types of data. It can store the only copy of
low priority or infrequently run programs. It can serve
as a backup for main programs normally held in high-
The system
In a real-time system, the processing capacity is
usually limited by the amount of real time required to
handle a given capacity. To maximize the capabilities
of a system using a disk file controller, the operation of
the disk as a memory should not require excessive real
time. To satisfy this requirement, the controller runs
autonomously from a large hardware queue in the
controller. It further communicates directly with the
random access memory on an interleaved bus cycle
with the central processing unit (CPU).
The basic cycle times of the CPU, random access
memory, and disk file controller are the same. However, the buses can be used twice every CPU cycle,
since the disk file controller's cycle time is staggered
one-half of a CPU cycle. During the first half of its
cycle, the CPU uses the high-speed memory bus; the
disk file controller is capable of using the same bus
during the CPU's second half-cycle. The CPU provides a path from the disk file controller to the highspeed memories as shown in Figure 1.
Since the high-speed memory cycle time is twice the
bus cycle time, the CPU and disk file controller cannot access the same high-speed memory during the
same cycle. To make best use of the capabilities of the
disk file controllers, several independent high-speed
memories are used on the same bus. Although the
controller can communicate with any memory, the
desirable program system is designed so that the disk
controller communicates most frequently with highspeed memories having low CPU occupancy. Because
many independent sources compete for use of the
563
564
Fall Joint Computer Conference, 1970
IEOUIn I"'FEI
IDII'
HIOH S'EED
MEMOIIES
ICOIE,
SEMICONDUCTOI,
ETCI
'IOCIIIINO
IN'OIMA"ON "
'01 EACH
IIOUIST
DISK IEOUEST
REGISTER (Dill
,
,,
,
,
CPU
OUEUE OF
,;!
REOUESTS - _ '_ _ _ I
LOCATION
INFORMATION
The disk file controller
r--t-{-' "-'--r-,
I
I
seconds, on the average. If the same request is entered
in both duplicate controllers, the first to reach the
proper disk location completes the job, in an average
of 10 milliseconds. With the duplicated and phaselocked disks each working independently, the average
latency is thus reduced. The throughput is doubled,
and the system reliability is greatly increased.
As depicted in Figure 1, the system is expandable to
meet any requirements. The number of disks per
controller is variable as is the number of controllers
and high-speed memories per system.
I.. - ~
I
\ - J' .J
I
I
I
Figure l-Processor complex
high-speed memories, a priority-blockage circuit is
incorporated in the CPU, Once each cycle, this circuit
selects the highest priority controller or the CPU, The
circuit grants the controller use of the bus, only if the
controller accesses a memory different from that accessed by the CPU during its first half-cycle, If the
controller requests the same memory, it is blocked
until the next cycle, when it tries again. A disk controller can be blocked for a limited number of contiguous
cycles. The disk data rate and the CPU cycle time determine this limit. Before the next word overflows
from the disk, the controller will be granted the use of
the bus.
In the simulation (see Simulation results), the system
studied could be blocked for three contiguous cycles
before the CPU need be interrupted to allow a disk
controller access to the memory. In this simulation
one word was read from disk every seven CPU cycles.
Thus, up to two tracks could be read into the same
high-speed memory used by the CPU, without causing
the disk to overflow. In an actual operating system,
the CPU never occupies one particular memory every
cycle for long periods of time (excluding a program
memory).
Since the least reliable hardware in a processor is
a disk file, it should be duplicated to decrease the downtime of the processor. Byphase-Iocking the disks (rotationally 180 degrees) with duplicate information, the
average latency for the pair is half that of a single
disk. If the rotation time of a disk is 40 milliseconds, a
request submitted to that disk is returned in 20 milli-
Within a controller complex, each disk is electronically divided into a large number of pie-shaped sectors.
Each disk face is further split into a number of radial
tracks. Figure 2 shows a division consisting of 100 sectors and 100 tracks: 10,000 sector-track data records in
all. Each data block has a distinct record address. The
opposite disk face is similarly segmented into another
10,000 addresses. Addressing to a word within the
block is accomplished' by specifying a "starting" word
within a sector-track. When multiple words are desired,
a "number of words" is specified in the request. With
this type of address scheme, request sizes range from
one word to an entire disk face.
Information concerning a request is placed in two
queues as indicated in Figure 1. One entry is made in
the disk request register (DRR), located in the controller hardware, specifying location information only
SECTOR
99
Figure 2-Disk segmentation
Integration of Rapid Access Disk Memory
ORR: IN EACH DISK
CONTROllER
ORB: IN HIGH SPEED MEMORY
565
TO PROCESSOR
COMPLETE DISK ADDRESS
. OF WORDS & STARTING WOR
LOCATION OF DATA
STATUS OF REQUEST
0t--_~
ORR
-
-
-
-
-
-
-
-
-
-
----------
':" REQUEST
M
SEARCH
SEQUENCER
24 BITS-------.t
SECTOR
CLOCKS
Figure 3-Disk request buffer (DRB) and disk request
register (D RR) organization
Figure 4-Disk controller
(i.e., sector, disk, and face). Each slot in this queue is
typically less than 12 bits in length since this hardware
is moderately expensive. In this queue, the number of
slots is expandable and depends on the throughput
requirements of the disk controller. Each register position in the DRR has a corresponding four words in
high:speed memory (as shown in Figure 3), which
speCIfy all the processing information for a job. The
disk request buffer (DRB) has the complete disk record
address, disk-face-sector-track, and starting word in
the specified record. It also contains the number of
words following the starting word to be delivered to
the system and the location in high-speed memory in
which the data is to be placed (read mode) or to be
taken from (write mode). The last word in the DRB
is reserved for the status of the job and a "done" indication which is set when a controller completes a
job.
The done indication in the fourth word of the DRB
signals the two duplicate controllers to update the
status of their respective DRRs. Requests shorter than
Y2-disk revolution are placed in both controllers, which
search their respective DRRs for jobs in the next sector
on each disk. For example, if disk controller 0, in the
jth position of its DRR, finds a job which matches the
next sector on one of its disks, controller 0 will access
the four words of the corresponding DRB to obtain
the processing information. If the done indication is
not set, controller 0 will complete the job as specified,
zero the jth slot in its DRR, and write back a done
indication to the fourth word of the DRB (in jth posi-
tion). One-half revolution later, when disk controller
I finds the same job and obtains the fourth word of
the DRB, it detects the done indication, zeros the
jth position of its DRR, and continues searching for
another job.
A complete search of the DRR takes place each
sector for jobs in the upcomming sectors on all disk
faces within a controller. As shown in Figure 4 each
disk controller has two independent circuits 'which
allow two simultaneous operations in each controller.
The sector information is derived from each disk's
timing tracks and is registered in the search sequencer
circuit. Using this information, the circuit searches all
M positions of the DRR. Having found a job (address
sector match), the search sequencer informs the proper
face control circuit which executes the job. The search
sequencer does not search for that face again until
that face informs it of a job termination. In this mode
of operation, if the request size is smaller than the
number of words in a sector, the controller has the
capability of processing 50 of the 100 sectors per revolution on two faces: a total of 100 jobs per revolution.
Thus, a controller community (a controller pair with
duplicated and phase-locked disks) has maximum
capabilities of 200 jobs/revolution with average latency
of one quarter of a revolution time.
Simulator
To understand and engineer the system more fully,
a FORTRAN real-time simulator was written for use
Fall Joint Computer Conference, 1970
566
submission interval was uniformly distributed. The
size of each request was drawn from a distribution
with characteristics as shown in (e) above. Since write
requests generally store data for later use, and since
system response times are not critical factors, all
requests asked for data reads from the disk.
80
...Z
Q
60
III
"i"I
:::I
.......
III
on
....
on
...
:::I
40
~
Simulation results
III
0
~
ID
20
:IE
-
:::I
Z
0
.
.,
~
1
~
T
,u.+cr
",,+2cr ,u.+3cr
20
40
60
80
REQUEST DelAY TIME (MILLISECONDS)
100
2 DISK CONTROLLERS
1000 REQUESTS/SEC
48 ORR s
X
10 ms
..u. = 11.54
CT
9.61
=
=
Figure 5-Distribution of returned requests
on an IBM 360 model 67 computer. At this time, the
simulated system includes "n" controller pairs with
one CPU and one high-speed memory. The CPU occupies the high-speed memory, varying from 0 to 100
percent of the time. The simulator incorporates all
blockage and priority characteristics in the program.
The throughput, request submission rate, and distribution of request sizes are all parameters of the programs. The output of the simulation programs is a
request delay distribution, the percent of CPU realtime blocked, DRR occupancy, and the number of
jobs aborted because of disk da"ta overflow (a low
priority controller repeatedly blocked by CPU and
other controllers).
Data pertinent to the simulation is listed below to
clarify the forthcoming results:
In the delay time distribution shown in Figure 5,
the average request delay was near the Pi-revolution
time predicted. The largest percentage of requests
is answered within the first half revolution time; requests for the same sector are dispersed over several
revolutions.
The next important characteristic is the amount of
real time wasted by the CPU due to disk controller
blockage. Note that in Figure 6, with the CPU using
the high-speed memory 60 percent of the time, the disk
system (delivering 100 requests/second) uses only 1.5
percent of the CPU's real time.
In Figure 7, the maximum and average occupancy
curves of the DRR allow optimum design of the DRR
size for a particular application. For a desired throughput of 1000 request/second, a 12-slot DRR would be
desirable. With some degradation in delay characteristics, any size between 6 (average occupancy) and
12 (maximum occupancy) would suffice.
2.5,-----~------~----~------__- - - - - - - - _
2.0 -t-----lt-------+----
!
~
u
....o
•
1.5
+----I-----I----I----~
:::I
e
~
a.
b.
c.
d.
e.
24 bits/disk word
32 disk words/sector
100 sectors/disk revolution
35 milliseconds/disk revolution
request size characteristics:
1. maximum request size = 32 words
2. minimum request size = 2 words
3. average request size = 8 words
f. simulation run time = 1 second of real time.
The disk address for each request was randomly
distributed. The number of requests submitted at each
o
Z
1.0 + - - - - - + - 1
III
U
III
III
IL
2 CONTROLLERS
0.5 +--__._-1-.1
- - - 20% CPU HIGH
SPEED MEMORY
OCCUPANCY
o
500
1,000
1,500
2,000
REQUESTS SUBMJTTED PER SECOND
Figure 6-Central processing unit (CPU) blockage
Integration of Rapid Access Disk Memory
50~----~~-----T------~------~------~
40+-------~----~------~~----T_~----_;
2 CONTROLLER PAIRS
MAXIMUM OCCUPANCY-
>u
~
JO~------~----~-------r----~T_------_;
A.
=
U
U
o
:
Q
20~------~-----4------~~----+--------1
104-------~--~~------~~----T--------;
o
500
1000
1500
2000
REQUESTS SUBMITTED PER SECOND
Figure 7-Disk request register (DRR) occupancy
567
SUIVnVIARY
This paper presents the design of a high throughput
autonomous disk memory system. Through extensive
use of hardware and software queues and direct main
memory access, the disk controller delivers high
volumes of data, requiring a small amount of the CPU's
real-time capabilities. By the 180-degree phase locking
of duplicate disk files, the latency of the memory system
is reduced to half that of a single disk, while providing
high system reliability. The computer simulation results
show that the design criteria are indeed satisfied.
ACKNOWLEDGIVIENTS
The author wishes to acknowledge his indebtedness
to the many members of the Indian Hill Switching
Division of Bell Laboratories who have participated
in the design of the disk controller. Deserving of
particular mention are D. M. Collins and R. D. Royer
for system and hardware design. Also, many thanks to
S. G. Wasilewfor his design of the simulator.
Management problems unique to
on-line real-time systems
by T. C. MALIA
IBM Corporation
Chicago, Illinois
and
G. W. DICKSON
University of Minnesota
Minneapolis, Minnesota
affect the environment in which it is operating. A more
operational definition is as follows: tit is the amount
of time that the computer could suspend computation
and then resume without changing any of the inputs
or outputs in the system."1 The shorter t is, the more
possible it becomes to class the system as real-time.
For example, a one second interrupt in a missile
launching is intollerable. The inputs to the system
would have to be altered to account for the movement
of the missile. On the other hand, a three hour delay
in a payroll program would not usually require any
such changes. Systems are usually not referred to as
real-time unless t is at most a few seconds and more
often a few milliseconds. One should note that it is
possible to have an on-line system that is not realtime, but the reverse is not true.
We include time-sharing systems as a subset of
OLRT systems. These systems, which "simultaneously" permit a number of users connected to the
system by remote terminals to utilize the power of a
central computer, not only share many of the problems
associated with OLRT systems, but introduce additional complicating factors.
As noted earlier, the scope of this paper is management problems associated with OLRT systems. It
will pertain to not only the managers directly responsible for the system design and implementation effort,
but the top managers of the firm as well. Special
emphasis will be placed upon OLRT systems which
heavily emphasize human interaction such as information retrieval type systems (e.g., airline reservation
systems) and on-line management information systems.
Time-sharing systems will be covered implicitly where
time-sharing problems are similar to OLRT system
INTRODUCTION
In the latter 1950's, the SAGE air defense system
began operating and thus became the first of the large
real-time computing systems. Initially such systems
were feasible for only military use or for a few very
large commercial applications. Today this is no longer
the case. Modern managers need better and more
timely information to keep pace with the rate of
change, the complexity and the competition within
the business environment. Therefore, an increasing
number of organizations will, of necessity, be designing
and implementing on-line, real-time systems. To
better prepare for this evolution, management must
understand the unique problems such systems will
cause; both in terms of th,e initial design and implementation phase, and the potential effects such systems will have on the organization. The purpose of
this paper is to outline the particular problems that
managers will have to deal with in an on-line, real-time
(OLRT) environment.
For the sake of clarity, several terms utilized throughout this paper require some discussion. These are:
(1) on-line, (2) real-time, and (3) time-sharing.
On-line refers to a system in which input data enter
the computer directly from their point of origin and/or
in which output data are transmitted directly to
where they are used.
An exact definition of real-time is difficult because
this is a relational concept. What is real-time in one
instance is not in another. Probably the most widely
used definition is one that says such a system is one
that receives data from remote terminals, processes
them and returns the results sufficiently quickly to
569
570
Fall Joint Computer Conference, 1970
considerations and explicitly where time-sharing systems pose unique problems. Many problems associated
with OLRT systems are similar to those encountered
in the design and implementation of any large computer system. In these instances, the paper will discuss
only those additional complications which operating
in an OLRT environment introduce. Finally, the
paper will not discuss the myriad of technical factors
involved in designing real-time systems, but it will
refer to these factors because of the need for management to control and guide the effort involved in solving
these problems.
OVERVIEW
Regardless of the type of OLRT system involved
or the specific application, there are some general
reasons why the design and implementation problems
of a real-time system are more formidable than those
encountered in batch processing systems. These
reasons include:
1. OLRT systems rank among the very largest
computer systems ever conceived. This is
usually due to the fact that such systems are
assuming functions that in earlier systems were
performed by human operators. In addition,
these systems may, by virtue of their complexity and related expense, be applied to only
the largest and most difficult problems.
2. OLRT systems are more complex due to their
size and type of application. It is very difficult
to engineer, install and maintain a system
with many simultaneous users. Also, the program required to poll and respond to these
users will have much more involved logic than
one written to control only one input device.
3. OLRT systems are new. The science of OLRT
applications was first developed for the SAGE
application in the middle 1950's. The first
commercial application was the SABRE system
which was developed in the early 1960's. These
systems are new in essentially two respects-the
application and the hardware. Frequently the
application of real-time systems is to an already
existing problem. However, usually it is a
problem that has not lent itself to computer
solution before OLRT. Thus there are no
previous attempts at computerization from
which to learn. In the case of the system to
monitor manned space flights, the designers
were confronted with not only a pioneering
attempt at computerizing the problem, but
also the fact that the problem itself was entirely
new. In addition, many of the pieces of hardware necessary to facilitate an OLRT system
are new. Most OLRT installations may be
somewhere between 5 and 100 percent new in an
equipment sense.
4. OLRT systems are more vital and thus disruptive in the event of a malfunction. By
definition, an extended interruption in an
OLRT system will require changing the inputs
or outputs of the system. Unfortunately, if
the delay is extended, severe damage to the
environment may occur before the corrections
are made. The earlier reference to the real-time
space flight monitoring system is a good example of an extremely vital application and one
that could be seriously impaired by a failure
of the system. In a batch processing environment, a down system simply means that records
will not be updated or reports generated for
a few hours. The OLRT system's inability to
function can have a very direct and costly
impact on operations. These systems are
adapted more to the immediate operations of
an organization, rather than historical record
keeping. In the case of the airlines reservation
system, the failure of the system will seriously
threaten a waste in the firm's vital seat inventory not to mention the impact upon customer
satisfaction. 2
PROBLEMS IN THE APPLICATION OF OLRT
SYSTEMS
Management involvement
The McKinsey Company's survey of computer
installations showed that the one thing that the
maj ority of successful installations had in common
was the fact that the executive managers of the company devoted time to the computer systems. 3 This
time was spent in reviewing the plans and programs
for the computer systems effort and in following up
on the results achieved. The involvement becomes
even more crucial in the installation of an OLRT
system. Management must insure that the tremendous
resources involved in the design and implementation
of such a system are. allocated in an optimum fashion.
Thus management must not only plan for the system,
but must also get involved in the planning of the
system. In this planning process, managers should be
very aware that such systems might cause extensive
changes within the firm and should attempt to predict
Management Problems Unique to On-Line Real-Time Systems
the effects of these changes. Possible changes may
include: (1) the eventual reduction in the power of
middle managers, (2) a trend toward centralized
decision making, or (3) the necessity of middle managers
to work in a very restrictive and highly controlled
atmosphere because of the information their superiors
have. By being knowledgeable of these effects, top
management can design their managerial philosophy,
and the system itself, in such a way as to minimize
the undesirable effects and to optimize the areas
where good effects can be achieved. The persons within
the company most affected by the new system must
be integrated into the system design effort to gain
their support and cooperation, which is essential if
the system is to succeed. Throughout the company,
top managers must prepare personnel for the effects
of the change, thereby reducing the reluctance of
people to comply with the system requirements.
Executive management effort is also needed to coordinate the many parts of the system and to insure that
the designers are given the cooperation the system's
eventual success requires.
The system design is far too crucial to leave in the
hands of technicians. The system will change the
work methods of humans and will be dependent upon
humans for proper functioning. This human element
is. extremely important and certainly should not be
ignored. Another reason for the involvement of top
management is' that extremely expensive trade-off
decisions must be made regarding acceptable levels of
system performance, reliability, and capability. For
instance, top management should not allow systems
people to make the decision to spend $1 million annually to improve the response of the system by five
percent. These are decisions for top management to
make, based on recommendations from technical
and operating personnel.
Personnel
The first problem confronting the project management will be that of finding qualified personnel to
work on the system. Because OLRT systems are so
new, there are not many people available with related
expertise or experience. Yet because of the size and
nature of such projects, it will be necessary to acquire
a large number of programmers and analysts. It will
be necessary to train these people in the· new. terms,
new techniques and new hardware, all of which must
be understood and integrated. into the design effort.
In an application where present operating procedures
are being computerized, it would be well to have
people with a knowledge of present operating proce-
571
dures as members of the proj ect team. The importance
of this team can be shown by Martin's statement
that "no single effort is going to have more effect on
the success of the system than the recruiting of the
best possible programming team4."
System design
General consideration
The next problem facing project management is
that of system design. This is unquestionably the
most difficult, yet most crucial phase of the system's
life. What is done in this stage will have a tremendous
effect on later stages and on the success of the system
as a whole. Essentially the objective of this design
effort is to design a system that will best meet the
needs of all the users. This must be accomplished
within the constraints of reliability, design time and
cost.
The reason the design phase is so critical in an OLRT
environment is that all parts of the system must be
integrated, and the shortcomings of anyone part will
degrade the total system. For instance, regardless of
the quality of the balance of the system, if the users
cannot operate the terminals, the entire system is
essentially worthless. Or if one channel of the central
computer becomes overloaded, the performance and
thus the value of the entire system will be affected.
The first step in the design effort is to determine
precisely what the system is to do-what applications
are going to be converted. It is necessary to fully
understand the information handling requirements of
these applications. Having determined the particular
applications for the system, there are three general
considerations which must be evaluated to narrow
in on the specific system configuration. These considerations simply provide a framework within which
the more specific details of the system can be analyzed
and determined. The considerations include:
System Availability-Is the extent to which the
system must make itself available to its users. How
many hours per day will the system be required? What
are the requirements in the event of system failure?
Can the users somehow continue to function off-line
or can they put off their work for some period of
time? Perhaps it is crucial that the system always pe
available; but, what· cost is acceptable to achieve
total· availability? These. considerations all entail the
system's overall capacity for performing the applica,..
tion processing in a prompt and satisfactory way
throughout the period· in which processing is required.
System Variability-Involves determining the long..,
572
Fall Joint Computer Conference, 1970
term volatility of the applications both in terms of
volume and changed requirements. It is difficult to
predict this volatility. The existing system is so differ~nt
from the future system, that it does not even provIde
a good base from which to project an estimate. Most
applications will require modifications and expansion
that, where at all possible, should be anticipated and
planned for when the system is designed.
Communication Characteristics-Is related to the
above two considerations and involves such questions
as how geographically dispersed will the terminals be,
or what speed of response will be required. Analysts
must also determine if there are peaks or cycles, both
in terms of, the volume of data transmitted and in
terms of response time requirements. If such peaks
exist, they present a dilemma to system designers, who
must decide on the appropriate capability level for
the system. If the system is designed with enough
capacity to provide for the peaks, this capacity will
not be utilized much of the time and will thus represent
an unnecessary expense. On the other hand, if the
system's capacity is far below that that the peaks
demand, the syste,m may become so overloaded during
periods of high activity that deteriorated performance
renders it useless. Therefore, at some level, a compromise must be made in terms of minimizing expenses
while at the same time providing adequate system
performance.
The system design will probably be an iterative
process in which it is recommended that durin~ t~e
first phase the complexity of the design be held WIthIn
manageable bounds. In later phases, the more sophisticated features can be added. The largest constraint
will probably not be hardware considerations, but
rather, the complex programming that will be necessary to achieve the desired results. It thus becomes
important that the system design team be aware of
the factors that contribute to the cost and complexity
of the system in order that, where possible, these
factors may be taken into consideration.
There are several specific design factors which are
pertinent in the design of an OLRT system. These
factors are by no means autonomous and somehow
must be integrated and balanced to optimize the
system in terms of overall performance and cost. In
addition, because this paper is primarily devoted to
OLRT systems requiring human interaction, the
aspects of man-machine interface are very important.
This topic will be covered in depth in the last section
of the paper. However, man-machine considerations
will also be discussed where they specifically affect
other facets of the system design. These other facets
include such things as the design of, the data base,
the terminals and' system scheduling all of which
will be discussed independently. It is important to
keep in mind, however, that they are all interrelated
and that each affects the overall system design.
Data base
This design aspect entails the physical and 'logical
organization of the data within the system. In an
OLRT environment, data base design is particularly
important due to the response time requirements and
the typically large amount of data involved. .The
general objective of the data base designers is to
optimize the following interrelated features: (1)
mInImIZe the access time to get information, (2)
maximize the ability of the system to respond to
questions both planned and unplanned, and (3)
achieve the above two features with the least overall
cost. Man-machine considerations will undoubtedly
impact the acceptable limits for the first two objectives.
In addition, for applications where the machines
must interact with untrained users or must interact
on a broad spectrum of topics, the data base designers
might want to enable the user to converse with the
system without having to translate his requirements
into codes or very specific formats. However, while
such free form formats will improve the user's ability
to interact with the computer, it will significantly
affect the system because of the need for special
software to interpret the input. The design team must
be acutely aware of the particular needs of those
using the data base. It must plan for expected needs
of these and future users and the expected increase
in volume of additions/deletions and inquiries to the
data base. There are several packaged data base
management systems available (like TDMS, IDS,
IMS) which designers would do well to investigate
concerning the applicability of these systems to their
needs. If such systems are appropriate, their implementation will obviously eliminate a tremendous
amount of programming. However, systems performance should not be sacrificed to achieve such initial
economy. Designers must devote special emphasis to
the data base portion of the design process because
of the tremendous effect this design can have on the
performance of the total system and on the ability
of humans to readily interact with the system.
Scheduling
This design problem is especially crucial in a timesharing system but, depending on the applications
involved, can be very important also for any OLRT
system. The problem is that the scheduler must be
Management Problems Unique to On-Line Real-Time Systems
established beforehand to determine how the computer is to service the terminals and how it is to carry
out the necessary computations. Essentially the
objectives of the scheduler are to:
1. Minimize the average response time and the
number of users waiting.
2. Recognize the users importance and the urgency
of the request.
3. Serve the users in a fair order and limit the
length of the wait.
Some of the possible scheduling methods include: (1)
first come-first served, (2) round robin (the many
users get small slices of time until their job is completed), and (3) a priority system, where users get
quantums of time depending on the size of their job,
their priority level and system activity. The disadvantage of the first come-first served method is that
users with very short jobs have to wait as long as a
person with a large job. The round robin method
would resolve this problem by completing the short
job in the first time slice and thus reducing waiting
time. As a general rule, the round robin method is
more beneficial than the first come-first served when
the amount of computation required is uncertain. 6
Here again, the particular scheduler used will be
affected by the requirements of the human users and
the desired performance of the entire system.
Data cOInInunications
Due to the nature of OLRT systems, it is necessary
to transmit data over communication lines. In the
great majority of applications, this necessitates using
common carrier's lines, which immediately poses a
problem for managers-that of coordinating the
design and compatability of the system with another
vendor. New hardware is also introduced, whose
capability and compatability must be understood
and implemented. The problem is further complicated
by the fact that these communication vendors have
a whole new set of "buzz-words" like bauds and
duplex lines which must be comprehended. Also, in
order to design an economic and efficient communica~
tion network, it is crucial to understand the various
rates and facilities offered by the common carriers.
TerIninals
The introduction of terminals poses problems similar
to those in data communications. Here a third vendor
may be introduced, further complicating- the coordination and compatability problem. Essentially the
selection of terminals involves, to one extent or another,
573
three interrelated factors. These include: (1) the
man-machine interface, (2) training of users, and (3)
the physical design of the terminals. The first two of
these factors will receive treatment later in the paper.
Essentially the goal of the terminal designer is to
design a terminal which will best enable the user to
interact with it, will require a minimum amount of
training, and will not have a significant detrimental
effect on the cost or response performance of the
system. That is obviously a large order. The trade-offs
essentially involve the initial cost of the terminal
and the ease of use of the terminal in a specific application. The initial cost may be reduced by utilizing an
"off the shelf" all purpose terminal, which is tailored
to meet the user's needs. It is usually the case, however, that such terminals will involve extensive training
for the users and will not achieve the ease of use level
that is best if humans are to readily utilize the hardware. The other alternative is to utilize terminals
that are specifically designed for the particular application. This will· make them easier to use and thus
reduce training requirements, but it will increase the
cost of the terminals. Some basic recommendations
based on past experience are:
1. Keyboards should be optimally designed to
provide the user with a choice of relatively few
options at any step in the solution process.
2. Where feasible, the user should be provided
with tags or plates which contain information
familiar to the user and the coded representation of that same information. These codes
must be recognizable by the computer and
easily scanned at the point of origin.
3. In instances where the input data must be
entered by typewriter type keyboards, it is
essential to provide a means by which the
user can visually verify and correct the data
before it is entered into the processor.
Also important in the physical design of terminals
are security factors. Such things as whether audit
purposes will require a hard copy of all input and
output data, or whether the keyboard might have to
be physically locked to prevent unauthorized users
must be considered. The designers will also have to
determine if they want the terminals to be able to
perform some functions off-line in the event of system
failure.
Failure
A very Important consideration throughout the
design process is that of minimizing both the chance
574
Fall Joint Computer Conference, 1970
of the system malfunctioning and the overall effects
of such a malfunction. It should be obvious that an
OLRT system on which many people are relying for
information has some very stringent reliability requirements. In addition, because much, or in some cases
all, of the information pertinent to a firm's operations,
is contained in this system, its security requirements
-in terms of information being available-are very
high. The hardware reliability problem is usually
solved by duplexing or duplicating the equipment.
Depending on the need for reliability, the entire
system may be duplexed or more simply, various
modules may' ,be replicated. In an airline reservation
system, for example, the entire CPU is duplexed to
permit back-up. An example of a duplexed module
is IBM's 2314 disc drives on which one spare drive
is available in the event of failure. These precautions
obviously greatly add to the cost of the system and
thus reliability design involves some important tradeoff decisions. Usually in cases where the CPU is duplexed, the spare unit is kept busy doing batch processing, but is ready to be switched over in the event of a
failure to the real-time system. The ability to process
while serving as a back-up helps somewhat to alleviate
the reliability expense.
The reliability or security of the data base is also
assured by duplication. This is usually accomplished
by systematically storing a duplicate of every record
in a file' in a slow and inexpensive storage ... device,
usually magnetic tape. To complete these security
precautions, it is necessary to maintain a record of
transactions occurring between the transcriptions. In
this way, if a disc is accidentally erased, the previous
status of the file can be taken off a tape and the subsequent transactions affecting this file can be recreated from. the transaction record mentioned above,
thus bringing the disc file up to its former status.
Assurance of reliability is not as simple as duplexing
operations. There are extremely complex software
routines which must be written to detect pathological
conditions. In such an event, the system automatically
switches to another unit: or informs the operator that
suchan operation is necessary. However, before the
switch is enacted, the status of transactions within
the failing system must be determined and transferred
to a spare system or module. Often times OLRT
systems are designed to "fail softly'''. This occurs in a
situation where only one component. of the system
fails. Rather than interrupting service entirely,. the
system modifies its mode of operation and will continue to carry out the critical jobs, but will give a
degraded form of service. This is called "graceful
degraqation", rather than total s);stem failure.
In. the. event of total failure, the users should be
notified immediately so that they can convert to
bypass procedures. I t is important that system designers have such a set of procedures established so
that users can continue to conduct their business.
Terminal operators might function by utilizing operating information which is periodically given to them
or they might have a central office to phone to get
critical information. Just as it is important to plan
for failure, it is also important to plan methods to
enable the computer system to update its records
with the transactions that occurred while it was
down.
The duplication of data files is complicated in an
environment in which they must constantly be available
for update and inquiry. Here software must be written
to momentarily lock-out-not permit access to-small
portions of the data base and during this time, the
data is copied and subsequent transactions monitored
to facilitate re-creation if necessary. These procedures
will minimize the effect of errors due to (1) electrical
or mechanical failure of hardware .units, and (2)
accidental erasure of .memory through hardware or
software error. Another cause of failure-physical
damage by disaster-must be planned for. In many
installations, the tape copies of the data base are
physically stored at another location to minimize the
chances of destruction in event of disaster. Basic
safety precautions i.e., fire door and alarms and
moisture alarms, are of course, important to minimize
the chances and effects of major disasters. Insurance
is a must, but the amount must be evaluated based
on cost and the probability of various types of disasters.
Security
The security of the system mentioned above pertains to the security of the data once it is in the
system. Also important, is the assurance of correctness
of the data base. This assurance is especially critical
in a real-time system because users. are relying on
the information to make immediate decisions. If the
data are in error, many potentially bad decisions may
be made before the error is discovered. On the other
hand, the data in the system are more difficult to check
because they come in directly ·from many remote
locations. Thus these inputs must be edited by programs and any incorrect or unrecognizable data rejected and the sender notified.
I t is also essential that the data base and the transactions be auditable. CPA's, internal auditors and
other audit agencies will want to review not only the
files and the transactions, but· alsQ .the programs that
are being used. The possibility of auditing around
l\1anagement Problems Unique to On-Line Real-Time Systems
the computer in such configurations is essentially nil.
Therefore, the system must provide the necessary
trails and documents to satisfy the auditor's requirements.
A final area of required security is that of insuring
that the data base cannot be altered or addressed by
unauthorized persons. This is especially important in
time-sharing systems, where controls must be present
to preserve the security of proprietary information.
The problem is typically handled in two ways. First,
terminals may require a special key or badge or code
to activate them. Secondly, the system software may
allow only input from certain terminals. Another
feature like memory protect may be used to allow
only certain portions of memory to be accessed from
some terminals.
It should now be obvious that there are a vast
number of interrelated factors which will affect the
design of an OLRT system. Essentially the problem
confronting system designers is to tie all these factors
together and devise a system which is an optimum
compromise between financial practicality and operating perfection. As of yet, there is no general mathematical procedure which can be followed to achieve
this compromise. Such tools as simulation, however,
'have proved very helpful. The problem with simulation
is that much of the data needed for simulation are
not available until the system to be simulated has
been designed and put into operation. Therefore, the
initial design may best be done by trial and error .and
simulation used to refine the system. In this way the
affects of any design changes can be investigated. On
the other hand, if simulation is used early in the
design phase, many of the facts will not yet be known
and thus the designers must revert to judgment and
intuition. Extreme caution must be utilized in this
situation, to insure that the inputs are reliable or the
GIGO (Garbage in-Garbage out) theorem will come
into effect. Thus if properly utilized, the benefits of
simulation will offset the time and expense necessary
to design and utilize it. This technique will also require
designers to take an organized approach to system
study and will help to insure that no important factors
have been overlooked. It is also a useful tool to assist
designers to plan for future hardware needs.
Hardware selection
The selection of hardware to use in the real-time
environment is, for the most part, a technical matter.
There are some factors, however, for non-technical
managers to be concerned about. The first of these is
the ability of the hardware to expand. OLRT systems
575
have a marked tendency to grow and thus it is important that the selected system can expand in terms
of number of communication channels, size of internal
memory and capacity of file storage. The most important criterion in this selection process should be
that of reliability. In this respect" it is important to
analyze not only the amount of downtime- on projected systems but the type, duration, and'distribution of periods of downtime. In an OLRT system, an
extended period of downtime is much more critical
than several short periods, although several brief
failures would certainly lead designers to question the
reliability of the system.
Modularity is a factor which is pertinent to both
the expandability and reliability of the system. If
the entire system is composed of many connected
modules, capacity can be added in small units so as
to reduce costs for excessive capacity. In addition,
because most failures in a real-time environment are
in one component of the system, modularity can
assure reliability at a much lower cost. For instance,
20-30 percent redundancy in a modular system buys
the same reliability that 100 percent redundancy
buys in a non-modular system. 7 However, connecting
the operations of these modules does put an added
burden on the system's executive routines.
The hardware selection should -also be based on the
knowledge and experience of the vendor in real-time
applications. A very important factor, in this respect,
is the amount and quality of real-time software the
vendor has available. The data communications
software and a real-time operating system entail a
very large and complicated programming effort. Thus
it greatly reduces the work load on the system programmers, if the vendor has such routines available.
The routines should be of proven quality and should
provide an adequate performance level to meet the
application's specifications.
Programming
Programming is by no means a consideration separate from system design. As mentioned, the designers
should clearly assess the programming complexity of
their design considerations. Aside from the technical
programming problems in an OLRT environment,
such programming also requires additional managerial
capabilities of those in charge of the department.
These needs are brought about by the main difference
between programming an OLRT system and a batch
processing system of similar complexity. The difference
is that the former must be a tightly integrated and
controlled piece of teamwork. Programmers are by
576
Fall Joint Computer Conference, 1970
nature an independent, creative group of workers,
most of whom feel they need freedom to work. The
programming team manager must closely supervise
their activities, must control their creativity and yet
must motivate them to solve difficult problems. The
programming job is often very frustrating because
even very minute changes can necessitate extensive
modifications of the work already completed.
Aside from these behavioral problems, programmers
in an OLRT environment are exposed to a wealth of
technical problems which they must work with and
resolve. These problems are essentially:
1. The use of terminal devices requires the programmers to learn their operating characteristics. Programmers must send and receive
special command characters to utilize the
remote terminals and to control such things
as keyboard shifts, carriage return and message
marks.
2. The problem of errors is especially critical in
a real-time environment. Data errors must be
dealt with in such a way that erroneous data
are not allowed to enter the system. Yet the
program response time must stay within the
time constraints.
3. The programmer must adapt himself to the
somewhat different characteristics of the computers used in OLRT configurations.
4. The data that programmers work with will be
unusual. It will have control characters imbedded, and will often be represented by a
code structure different than the one used
internally by the computer.
5. Programmers must be especially cognizant of
testing, storage and timing considerations unique
to terminal oriented systems.
Programming managers can greatly alleviate their
problems by dividing the entire system into semiautonomous sub-systems. If the division is properly
handled, the number of interactions between programs
and programmers can be reduced. Once this is achieved,
however, input/output formats among programs must
be standardized and rigidly adhered to. A standard
procedure should be established which programmers
should follow if they believe a change in the system
is necessary or desirable. No changes, however minute,
should be allowed without following this procedure. A
special control group may be established to coordinate
and evaluate suggested changes in formats and to
decide on changes and communicate these to the
parties affected.
Training of users
Training of the user in a real-time environment is
crucial for essentially two reasons. First, most of the
raw data in the system are provided by personnel
with other operating responsibilities. For instance,
the airline clerk is concerned with selling tickets, the
production worker is involved with his assembly
work, and the bank teller has a line of people waiting
to be served. Thus it is crucial that these people are
trained to easily, yet accurately, input the data into
the system. As noted earlier, the physical design of
the terminals, combined with proper training, will
affect the user's ability to achieve the desired ease
of use.
Secondly, one of the basic purposes of providing
an 0 LRT system is to enable user personnel to extract
meaningful, timely information. Obviously if they
are not properly trained to utilize all the features,
the system is not going to provide the service or have
the effects which its designers intended. Along the
same lines, it has been found that many times the
reason why people do not utilize new equipment is
that they are unsure of their ability to operate it.
To solve these problems, many OLRT users have
connected terminals to small test computers, to
simulate the system, and to enable users to get experience in the man-machine interaction environment.
Another area where training is important is that of
by-pass or off-line procedures when the system is
down. Hopefully, the users will not have too much
actual experience in this mode, so they will have to
be periodically retrained on the proper procedures.
System testing
lVlany of the problems of OLRT system testing were
alluded to in the section on programming. Essentially
the complicating factor is the fact there are a large
number of programs, software, and hardware features
all interacting, plus an infinite combination of input/
output states. Thus it is difficult to systematically
test all these interactions and combinations. In addition, once an error condition exists, it is extremely
difficult to go back and re-create the situation which
caused the error. Despite these difficulties, the vitalness
of the system to the firm's operations, requires that
the system's reliability be fully tested-more so than
other configurations.
By far the most crucial element in OLRT system
testing is to plan the system from the beginning so
as to include all of the testing facilities which will be
necessary. The hardware configuration should be
planned in such a way as to isolate the causes of error.
The preparation of testing facilities must be carefully
Management Problems Unique to On-Line Real-Time Systems
monitored to assure that they are finished and available when the operational portions of the system
are completed. Part of these testing facilities are
programs to simulate the various portions of the
system, such as the remote terminals. The more
sophisticated these programs, the greater assurance
designers will have of the reliability of the system.
As an example of the amount of work involved in
preparing these testing programs, Desmonde tells of
an installation in which more than twice as much
labor was expended in preparing utility programs
and programs for testing and simulating the system,
than was used in writing the operational programs. 8
Robert Head outlines a recommended five step
approach to the complete testing of OLRT systems. 9
For the first step, the individual programs or packages
of related programs are debugged and tested with
simulated programs which duplicate more or less the
functions of both the hardware and control programs
with which the programs will be interacting. The
second step is to test these programs or packages in
conjunction with the control program. This satisfies
the dual purpose of testing both the application programs and the control program, if it was written or
modified in-house. The third step is to supply simulated
inputs from the multiplexor to determine the possibility of this device as a source of error. Also in this
phase, the program packages are further combined
into subsystems and the volume and variety of the
input data is vastly increased to test the performance
and overload characteristics of the sUbsystems. The
fourth step is that of system testing. Here all the
pieces are put together for a final integrated test of
the entire system. Prior to this phase the terminals
have been debugged from an equipment standpoint.
They are now connected to the system in order to
provide entries in a mix, a sequence, and a format
and content that duplicates actual operating conditions. Also at this stage, the automatic switching and
other "graceful degradation" software of the system
should be checked. The final step has to do with
evaluating not whether the system is capable of performing satisfactorily, but how well it is performing
when measured against the functional or performance
requirements. This acceptance testing should be an
on-going process for the life of the system to ensure
an efficient system organization and to provide sufficient lead time for system modifications necessitated
by oversights in the initial design or .by load growth.
Conversion
The problems encountered in the conversion and
implementation phase are not really too different
577
from those in any large system conversion. One of
the factors that makes this conversion crucial is that,
unlike batch processing systems, once the cutover of
a real-time system is accomplished, the user is fully
committed, i.e., he has virtually no satisfactory way
of turning back to his former system. For this reason
and because of the huge sums of money involved and
the typical disruptions such conversions cause, the
implementation must be carefully planned and scheduled and closely monitored. The SABRE system was
implemented on a location by location basis and the
designers recommend this procedure because it: (1)
shortens the learning period at each location, (2)
enables the firm to operate with only a small portion
of its real-time functions undergoing a major change
at anyone time, and (3) the remaining bugs in the system
are eliminated before the entire company is relying
on the system for its operation. 10
MAN-MACHINE INTERFACE
The man-machine interface problem IS certainly
pertinent in discussing the design of a computer
system with which humans must interact. For this
reason, the man-machine interaction issue has been
discussed as a part of the design phase of an OLRT
system. However, because of the complexity of the
problem, the vastness of the questions involved and
the extent of the still unexplored areas, this topic
will be discussed in more detail in this section. The
discussion will center upon what are the causes of
the problem and some general rules that have been
established to deal with the man-machine interface
problem.
Sackman gives an indication of the complexity of
the problem by his statement that "the most difficult
and vexing problems in an OLRT system are not in
the maze of hardware or the intricacies of the software,
they are in the enigmatic nature of the human users."ll
This issue of man-machine interface is by no means
a new one. For a long period of time, our society has
had machines which are highly analogous to man's
muscle and yet controlled by man's brains. In recent
times, we have developed information processing
machines that are in many ways functionally equivalent to man's brains.
In an OLRT environment, users are interacting
with the system in two different contexts. In the
first, the information processing machine is interacting with man's muscle or essentially the machine
is telling man what to do. Examples of such systems
include: (1) the space program in which information
is processed by machines and men are told which
578
Fall Joint Computer Conference, 1970
functions to carry out, and (2) airline ticket agents
that are informed by the system whether or not to
write a ticket for a specific flight. The second context
is where the information processing machine is interacting with man's . brain. In this instance, the manmachine interface is extending and augmenting human
thought. Here the ability to completely and readily
communicate is much more crucial, yet much more
difficult to achieve.
The objective of those concerned with the manmachine problem is essentially to design a system
that will most effectively take into account the limitations and talents of both man and machine. It is
important to realize that the human factors are in
certain respects diametrically opposed to those of
the computer. The respective talents and limitations
we must account for are the reliability, speed, and
accuracy of the computer and the intelligence of man.
Intelligence is the ability to learn or understand from
experience and as a result the ability to respond
favorably in a changing environment. Therefore, the
system must not only utilize the talents of the components involved, but must also enable the human
user to readily and comfortably interface with the
machine to offset his limitations with the talents of
the computer. This interface gives rise to many questions such as: How fast a response from the computer
does the user need for different types of tasks? How
much variability in computer response time can the
user tolerate? How concise or redundant should mancomputer communications be? What are the optimal
languages for man-computer communication? What
sort of feedback should users receive from the computer for various classes of human and system errors?
How can the system help the user when he gets into
trouble?
To answer these questions and to effect an interface, designers have essentially two variables with
which to work-the system hardware and software.
However, in dealing with these variables, designers
must have some concept of what to expect of man.
A knowledge of the underlying psychology and physiology of man is helpful in dealing with this problem.
Some would argue that since man has great flexibility and can readily learn skills, he can ease the
interface problem by adapting. The truth in this
statement is not at all clear. Clearly there are some
tasks man can never learn. He cannot for example
reduce his reaction time below some limiting value
on the order of 100 milliseconds. Some of the other
limiting factors in a. man-machine interface include:
1. The concept of information necessarily involves
a choice of one from a set of alternatives. This
necessity for discrimination however is far
from the limiting factor. The ability of man to
perceive changes is ever so much more acute
than the ability to identify items in isolation.
Professor George Miller has developed "the
tale of seven plus or minus twO".12 This rule
is that for most single perceptual dimensions,
it is true that the average subject can perceive
or can identify at most 7 ±2 stimuli presented
on that dimension. Multidimensional displays
can be used to improve this identity rate.
2. The human reaction time limit mentioned
earlier was for the most elementary tasks.
For more difficult tasks, involving identification, reaction time increases linearly with the
number of choices, unless the identified objects
are drawn from a very familiar set such as
letters or numerals.
3. To maximize the information transmission
speed across a man-machine interface, it is
best to choose a large familiar alphabet. If
this is done properly, rates up to 40 bits per
second can be achieved.
4. The rate of learning or the ability to identify
from a set increases with the familiarity of
the set. It is not always obvious from the
physical dimensions of the stimulus what is
familiar. However, objects or displays which
are in habitual uSe often turn out to be good
choices. Thus despite the fact that man is
flexible, he is not infinitely so. Designers should
take his limitations into account when designing
systems.
The essence of the man-machine interface is the
dialogue which occurs between man and machine.
This dialogue is very dependent on the language and
hardware used, but also on the speed of response.
Ideally the responRe should be rapid enough to not
cause discomfort on the part of the user and to enable
him to forget that he is sharing the system with anyone else. Thus the supervisor or executive is a critical
factor for effective man-machine interaction. The
executive or scheduler must strive to return an answer
to short problems as quickly as the user can react.
For longer' problems, where considerable computation
is involved, the user is psychologically set. to endure
delays. Therefore, the system should provide immediate
turnaround for short jobs and push the congestion
delays and thus variation in response time toward
the "long-problem" end of the spectrum. Psychologically this makes the device appear more private
and self-contained and lessens irritation due to delays.
The man-machine dialogue also presents a language
Management Problems Unique to On-Line Real-Time Systems
barrier. Man's languages are imprecise and context
orientated; computer languages are unambiguous
with minimal context modification. Most users will
generally be untrained in artificial languages precise
enough to be interpreted unambiguously by computers. In addition, the computer processes information
much faster than man can respond. Thus the interface
requires translating and buffering so that the requirements of both man and machine can be met. The
translation can be facilitated by the development of
problem-oriented or people-oriented languages which
do not require specialized programming skills.
Consoles must be designed to enhance the interaction between man and machine. In deciding on the
type of console, designers must determine the advantages of the particular console with respect to
ease of use, flexibility in format and content, and the
achievement of man-machine symbiosis. Ease of use
refers to the amount of special preparation required
and will be affected by not only the console but also
by the interface language used. Flexibility is simply
the ability of the user to get what he wants in the
form he wants. Finally, symbiosis relates to the ability
of the user to hold a discourse with the machine. He
must be able to talk back to it in his language in
developing problem solutions.
The interactive cathode ray tube consoles seem to
best fulfill these requirements. Such terminals, often
called graphic input/ output devices, should allow
other than alphanumeric symbology. Some of the
ones now in use provide capability for drawing, following lines and curves, displaying shapes, and responding by touch only. What is most important is
that they facilitate information exchange between
man and computer directly via graphics without the
need for reducing all such exchange to words.
CONCLUSION
The essence of designing an OLRT system that meets
the user's goals and that incorporates an effective
man-machine interface is to achieve the proper balance
between all the pertinent factors in the system. There
are a multitude of considerations that must be interconnected and blended in the proper proportion to
579
realize the design goals. Control, coordination, and
communication throughout the entire system design
and implementation phase is thus extremely critical.
But before this phase is initiated, designers must be
fully educated on the various aspects of the system
and must understand how these factors will interact
to affect the eventual performance of the on-line,
real-time system. The designers must not only face
up to the technical problems involved but, even more
importantly, must meet the behavioral problems
stemming from the fact that OLRT systems involve
human interaction.
REFERENCES
1 D KLAHR H J LEAVITT
Tasks, organization structures, and computer programs
The Impact of Computers on Management (C E Myers
ed) The MIT Press Cambridge Massachusetts 1967
2 R V HEAD
Real-time business systems
Holt, Rinehart, and Winston, Inc New York pp1-4 1964
3 J GARRITY
Top management and computer profits
Harvard Business Review Volume 41 No 4 pp 6-13
July-August 1963
4 J MARTIN
Programming real-time computer systems
Prentice-Hall Inc Englewood Cliffs New Jersey p 368 1965
5 R V HEAD
pp 63-65
6 W J KARPLUS (ed)
On-line computing
McGraw-Hill Book Company New Yorkp 891967
7 Ibid
p94
8 W H DESMONDE
Real-time data processing systems: introductory concepts
Prentice-Hall Inc Englewood Cliffs New Jersey p 152 1964
9 R V HEAD
Testing real-time systems
Datamation pp 42-48 July 1964
10 R W PARKER
The SABRE system
Datamation p 52 September 1965
11 H SACKMAN
Computers, systems science, and evolving society
John Wiley and Sons Inc New York p 79 1967
12 G MILLER
The magical number seven plus or minus two: some limits on
our capacity for information processing
Psychological Review Volume 63 pp 81-97 1956
ECAM-Extended Communications
Access Method for OS/360*
by GERALD J. CLANCY, JR.
Programming Sciences Corporation
Natick, Massachusetts
programming With a Fixed Number of Tasks) and
MVT (Multiprogramming With a Variable Number
of Tasks) options of Operating System/360. It is similar
to the other "queued" access methods, such as QSAM
and QISAM, in that the application programmer is
removed from the details of device dependencies.
Under control of the QTAM Message Control Program
(MCP), incoming messages are routed to specific input queues on direct access storage, as directed by
message header information. To the application programmer these input queues are very similar in appearance to a QSAM sequential data set, with which
the programmer is most likely already familiar. Even
the accessing macros-OPEN, GET, PUT, CLOSEare similar, differing only in minor detail. The only
basic distinction which the programmer must take
into account is the fact that the "end of data set" condition may only be a temporary one, occurring whenever the program is active and a lull in incoming messages for the application exists.
When the programmer wishes to send a message to
a terminal, he simply constructs the message in main
storage, including a message prefix, and "puts" the
message to his output "data set," which is referred to
in QTAM as a "destination queue." The MCP retrieves
outgoing messages in order from the destination queue
and forwards them to the terminal.
INTRODUCTION
Installations utilizing OS /360 which wish to extend
the operating system's use into a teleprocessing environment all face a similar problem: How to prevent
the significant waste of resources, particularly that
of main storage, that inevitably accompanies a move
from batch to on-line processing? QTAM organization
normally utilizes one region (or partition) for its Message Control Program and one region (or partition)
for each process, or application, program. Thus, the
TP configuration becomes inordinately expensive due
to resident core storage requirements, most particularly
if the applications are low-volume oriented. An alternate approach, via the use of the BTAM facilities,
requires much more extensive knowledge on the part
of both system designers and programmers and may
well generate more severe and complex problems.
The Extended Communications Access Method
(ECAM) was developed by Programming Sciences
Corporation to meet this common problem and, additionally, to minimize the programmers' required
knowledge of teleprocessing and to provide the installation with dynamic operational control over its TP
environment.
MOTIVATION
QTAM overview
Systems considerations
The Queued Telecommunications Access Method
(QTAM)4,5 is part of the software communications
support supplied by IBM under the MFT (Multi-
While QTAM eases the application programmers'
transition from conventional batch data processing
to on-line communications processing, the organization of QTAM raises numerous systems considerations
for the installation, primary of which are the main
storage requirements and the lack of a high-level
language interface to QTAM.
* This work was developed in part under contract to the United
Aircraft Corporation.
581
582
Fall Joint Computer Conference, 1970
Main storage requirement
A QTAM system is organized with the M CP residing
in one partition (MFT) or region (MVT) and the application, or processing, programs in one or more other
partitions or regions. There are at least three advantages
to assigning each application its own partition or region. First, the applications are protected from one
another; second, the addition of a new application program or the deletion of an existing one in no way
effects the operation of another application; and third,
in the event that an application is abnormally terminated, the balance of the applications remain intact.
The major disadvantages of assigning partitions or
regions to applications on a one-to-one basis is that the
main storage requirement can become prohibitive,
perhaps requiring additional systems, and that abnormal termination recovery is left to the o'perator
rather than the system. The main storage requirement
is particularly alarming in view of the fact that, in our
experience, low-volume applications predominate in
most QTAM installations, thus resulting in very inefficient use of main storage. Consider for a moment
the problem faced by an installation with five 40K
applications, each of which handles 300 messages, on
average, in an eight-hour, first-shift period. The total
daily volume of 1500 messages can be handled with
ease on a 360/50 or 360/65, with the bulk of CP time
still available for background work. Yet, if each application is assigned its own partition or region, a total
of 200K must be dedicated to the communications applications. Double the number of applications or the
size of the applications and a 512K system must be
virtually dedicated after taking into account the
residence requirements of the MCP and the Operating
System/360.
Even though CP time is available, it is conceivable
that the residence requirements of the communications
subsystem could severely inhibit the amount of background work which could be executed.
One alternative-assigning multiple applications to
partitions or regions-therefore becomes attractive
on the basis of more throughput per dollar expended
for main storage. However, the questions of added
application complexity, storage fragmentation of the
parition or region, the effect of abnormal terminations
on other applications and subsequent maintenance
must be carefully weighed. It is precisely these considerations which were the prime motivation for the
development of ECAM.
Lack of HLL interface
One additional installation concern is the lack of a
high-level language interface to QTAM, which is sup-
ported only at the assembler level. This is of particular concern to many commercial installations who
have been accustomed to writing most of their batch
applications in COBOL or a similar high-level language. The move to on-line processing may involve
the hiring and/ or training of additional assemblerlevel programmers. In addition, the advantages of
programming in the high-level language-decreased
application development and debug time and costare lost to the installation. Such an interface is, therefore, quite desirable.
DESIGN OBJECTIVES
The major design objectives of ECAM, then, were
to provide:
1. the capability for application programs to share a
common main storage space in a manner transparent to the applications themselves;
2. a high-level language interface to QTAM facilities;
3. automatic restart facilities in the event of abnormal terminations due to specified conditions;
4. the flexibility to reconfigure the application mix
both statically and dynamically; and
5. the capability to execute ECAM in multiple
regions.
In anticipation of the difficulties of debugging both
ECAM and, subsequently, the applications in the
on-line mode, it was also decided that ECAM would
be able to simulate the telecommunications environment in a manner that would be transparent to the
applications and, for most purposes, to ECAM itself.
This allowed most of the program checkout to be conducted in a batch mode and significantly reduced the
test time which would have been required had testing
been done via terminals.
Constraints
Two constraints were placed upon ECAM; no modifications were to be made to OS/360 and all ECAM
code was to be totally re-entrant. Though several modifications were contemplated, the limited gains did not
in our opinion warrant the risks inherent in performing
such modifications. The requirement for invariant code
was necessitated by the possibility that ECAM could be
executed in several regions at once; this avoided the
need to load more than one copy of the code.
The choice of MVT, rather than MFT, for the
ECAM operating environment was dictated by our
ECAM
desire to (1) dynamically manipulate application task
priorities, (2) recover from abnormal terminations and
(3) allow the asynchronous execution of the operator
interface modules with the balance of ECAM.
It was also our contention that the potentially significant main storage savings resulting from the use
of ECAM could justify an installation's move from
MFTtoMVT.
583
ECAM
STRUCTURAL CONSIDERATIONS
The assumption that the main storage requirements
of applications will frequently exceed region size was
implicit to the design of ECAM. At first, we considered
anticipating storage overrun by examining the main
storage queues (PQEs, DQEs, SPQEs, etc.) of the
OS/360 main storage supervisor, but this was rejected
both because it would have made ECAM too sensitive to internal OS changes, and because it would have
been a duplication of the OS effort. Instead, we decided
to maintain a summary counter of the main storage
in use by the ECAM complex at any given instant.
This information, coupled with knowledge of the
region size and the storage requirements of every application, parameters which are contained in ECAM
control tables, enabled ECAM to avoid making requests (e.g., attach an application) which would obviously result in exceeding region size. However, this
approach did not account for storage loss in the region
due to fragmentation, thus making some abnormal
terminations due to out-of-core conditions inevitable.
It did, nevertheless, reduce their frequency to a more
acceptable level.
This inevitability of abnormal terminations and the
necessity to recover from them dictated our design of
the ECAM intertask relationships and led to a distinction between task and queue priorities. Under MVT,
the abnormal termination of any task also results in
the abnormal termination of all of that task's subtasks
as well. Thus, were ECAM to abnormally terminate
when attempting to attach an application subtask
(an implicit request for main storage), the entire
ECAM complex would be terminated, including all
currently executing application tasks, since the ECAM
task is the highest-level task in the ECAM task hierarchy. In order to prevent this, the ECAM task always
attaches an intermediate task (IT) whose sole functions
are to attach and detach, when appropriate, the application subtask and to provide a two-way communications path between ECAM and the application subsubtasks. The code required for IT amounts to only 200
bytes and, since the procedure itself is re-entrant, only
one copy of the procedure is ever required, regardless of
Figure l-ECAM task hierarchy
the number of subtasks generated. The ECAM task
hierarchy can then be represented by the tree structure
shown in Figure 1.
The structure illustrated has resulted from the arrival of two messages, one for processing by application
Al and the other for processing by application A 2 • When
a message is read from an input queue, it is examined
to determine the name of the application which is to
process it. ECAM then creates an intermediate subtask and passes to that subtask both the name of
the processing program which is to process the message and the location of the message. The IT task,
in turn, creates the task for the application program
and passes the message on to it for processing. ECAM
then continues reading input queues until either region
storage is saturated or the input queues are exhausted.
Empty input queues
In the instance when there are temporarily no more
messages to be processed, ECAM sets a timer interval
(the value of which can be altered by the installation)
and enters a wait state for its duration. Though we
would have preferred to wait on a list of events (the
events being the arrival of additional messages to input
queues), with anyone event satisfying the wait condition, the implementation of QTAM prevented this.
QTAM provides the user with two options for the
584
Fall Joint Computer Conference, 1970
"no message" condition when requesting another
message. The first option is to simply wait for a message
to appear on the specific queue for which the request
was directed. This alternative was unacceptable to us,
since ECAM controls the reading of all queues and
since the queue to which the next incoming message
would be directed was not predictable.
The second option provides for the transfer of control
to a user exit routine on the "no message" condition,
and it was this option which we chose to implement.
The exit routine requests a message from the next
input queue, again specifying the same exit routine,
with the sequence repeated until all queues have been
read without success. It is at this point that the timer
interval is set. On its expiration, the entire process is
repeated, including, if n.ecessary, the setting of another
interval, until a message arrives at one or more of the
input queues. The primary advantage of the algorithm
is that it allows for background processing when the
communications subsystem is idle.
One additional problem was encountered here, although this time the situation was attributable to the
OS implementation. OS/360 provides no means of
passing input parameters to the timer exit routine in
a re-entrant fashion. Thus, the timer exit routine itself
had to establish address ability to the mainline ECAM
control queues. This was accomplished by using the
same searching technique as used by the OS supervisors, namely, by starting with the top of the OS task
hierarchy (located via the "Old/New TCB" address
vector in the Communications Vector Table) and
searching for a Task Control Block (TCB) which points
to a Program Control Block (PRB) containing the
name "ECAMn". The n is used to distinguish between
multiple instances of ECAM when the control program
is being concurrently executed from several regions.
When found, registers are loaded with the appropriate
parameters from the register save area in the PTC.
That the save area contains the correct parameters
is guaranteed because ECAM never alters the general
purpose registers containing them after initialization.
The structure searched is illustrated in Figure 2. N ormally, the first TCB encountered will be the correct
one since the "Old" pointer represents the currently
executing TCB, namely that for ECAM, which is
executing the search.
This search is the only OS-dependent routine in all
of ECAM. However, its use was fully justified because
the structure is basic to the design of the entire Task
Supervisor of OS /MVT. Should the structure ever be
altered so also will much, if not most, of the supervisor. As it happens, TCAM6, a new IBM access method
to be released shortly, will eliminate the need for the
timer exit routine.
Task priority
One of the reasons that MVT was chosen as the
operating environment was so that ECAM could control the assignment of task priorities within the communications subsystem. Exclusive of the QTAM Message Control Program, which runs in a separate region
with the highest user priority in the system, there are
three levels of priority within ECAM. The highest
level is reserved for the exclusive use of the Operator
Interface Task (OIT), the next lower level for the
ECAM mainline task an.d all lower levels for application tasks.
The OIT is the primary vehicle for effecting installation control over the communications environment. All operator-ECAM communication is performed via the primary operator's console, utilizing
the Write-to-Operator and Write-to-Operator-withReply (WTO /WTOR) facilities of OS/360. 3 The Operator Interface Task was assigned the highest priority in
ECAM complex to assure rapid response to installation
requirements. The task consists of one overlay module
with one 1158-byte root segment, which remains permanently resident, and seven transient segments which
average lI~O-bytes each. Only one transient is ever
in main storage at any time and only when required.
Their primary purpose is to interpret operator requests
and schedule those requests for execution by ECAM.
CVT
~C_VTt---lf-/~
I
rO_L_D_T_C_B_---t~
NEW TCB
P RB 1
~§
I
,--T_C_B_2~ ~ rRB:ame
_____
Figure 2-Addressability search
j
ECAl\1:
Application task priorities are assigned from an
ascending relative scale of from 1 to 13 and can be
assigned either staticalJy, prior to ECAM initialization, or dynamically by the operator. The ECAM
task is assigned priority level 14 and the Operator
Interface Task is assigned priority level 15. All intermediate tasks are assigned the same priority as their
related application task.
Queue priority
We felt it desirable to distinguish between task
priority and queue priority. The former is normally
assigned as a function of the I/O-boundness of a particular task in relation to the other application tasks;
i.e., for optimal throughput it is desirable to assign
the highest priorities to those tasks which are I/Obound and lower priorities to those which are more
process-bound. However, the priority used for this
purpose has no necessary relationship to the order in
which input queues are serviced. Therefore, each input
queue has associated with it a queue priority. Initially,
it was intended to always return to the highest priority
queue after servicing any lower priority queue, but
this was rejected (prior to implementation) in favor of
cyclic polling of the queues in order to e1iminate the
possibility of not servicing one or more lower priority
queues during periods of heavy message loading.
Input queues are polled in their order of priority.
Each queue is queried for the existence of a message
and, if none exists or if the queue is "busy," i.e., a
previous message from it is still in process, the queue
is bypassed and the next lower priority queue is polled.
If all the queues are either busy or empty,· the timer
interval is set and, on its expiration, polling again
commences with the highest priority queue.
Assuming queue activity, as many application tasks
are activated as possible to the saturation point of
the region's main storage allottment. If and when this
occurs, queue polling stops and special "quiesce" flags
are set in control tables to indicate that a message has
been read which cannot currently be processed. When
one or more of the in-process tasks complete, the
"waiting" message is then processed and the next
lower priority queue read.
ENVIRONMENTAL CONTROL
One of the main objectives of ECAM was to provide
as much flexibility as possible in controlling the communications environment. Five facilities have been
provided which can be used both statically, prior to
ECAM initialization, and dynamically, during execu-
585
tion. These facilities are:
-the ability to make application programs resident or transient
-the ability to activate or deactivate specific
application processing
-the ability to set and alter application task
priority
-the ability to set and alter input queue priority
-the ability to multi-task a particular message
type
All five attributes-residence, state, task priority,
queue priority and multi-tasking-can be predefined
during ECAM generation, utilizing special macros
provided with ECAM,t or dynamically, via the Operator Interface Task. The time-of-day at which the commands are to take effect can also be specified by either
means. A full description of the macros and the command language, which conforms to the 08/360 operator
command format, can be found in References 1 and 2.
Residence attribute
During ECAM initialization, the control tables
which have been defined by the installation via the
macro facility are loaded into main storage and the
initial program attributes are examined. All programs
which have been marked resident are loaded and
permanent intermediate and application tasks are
created for them, regardless of current input queue activity. Tasks for transient programs are created only
when needed and detached (destroyed) when the
storage they occupy is required by another transient
program. Transients may subsequently be made resident by the operator and resident programs can be
made transient.
It should be observed that the special case wherein
all applications are resident is similar to the normal
QTAl\1: organization without ECAM. The great difference with ECAM, however, is the ability to dynamically adapt the operating environment to the
changing communication situation. For example, it
is quite common to find several applications which
have one or more abnormally high peak activity periods
during the day. During such periods, which very often
can be anticipated, the processing programs for those
types of messages can be made resident, or given a
higher priority, or both. This cannot be done if the
applications run in separate regions in a normal QTAM
environment.
586
Fall Joint Computer Conference, 1970
State attribute
The state attribute provides the capability to shut
down or turn on the processing of certain message
types. There are several situations where this may be
desirable:
1. when there is no activity during periods of the
day for these programs; and
2. when the applications being shut down are of
the data collection variety (i.e., requiring no
response) and the main storage is needed to
flatten out peak activity in other application
areas.
under environment simulation later. The other feature
is the capability of having ECAJ\1 control the opening
and closing of the application's non-communications
files as well as the communications input and output
queues. This capability is particularly important for
the transient appJications, since the OPEN and CLOSE
functions for auxiliary disk and tape files can contribute as much as one or two seconds to the total response
time in inquiry/response applications. If these functions can be separated from the application itself,
these files need only be opened when the application
is activated and closed when deactivated-not every
time the application is loaded into or leaves main
storage. A secondary benefit may be a reduction in
both disk arm contention.
Task priority attribute
ABNORMAL TERMINATION RECOVERY
In situations where the mix of application tasks
which are active changes frequently in some definable
pattern-such as a situation where applications A,
Band C are active all day, but D and E are active
only from 1 :00 to 5 :00 P.M.-it may be desirable to
alter the priorities of some of the tasks to reflect the
new I/O-process ratios. The change of priority is effected by ECAM via the CHAP (Change Priority)
supervisor service call of OS/MVT.3
Queue priority attribute
As mentioned previously, this attribute determines
the order in whicn the input queue is queried relative
to all the other input queues. When a request is made
to alter the priority of an input queue, the ECAM
control table linkage is resorted to reflect the new polling order.
Multi-tasking attribute
This feature provide~ the ability to concurrently
process messages of the same type. Multiple tasks are
created by ECAM for all applications with this attribute. Although not necessary, it is desirable to code the
application in a re-entrant manner so that only one
copy of the module is required. Serialization control
is provided by ECAM on input queues containing segmented messages, but greater efficiency is possible if
messages are not segmented.
Other facilities
Two other facilities were incorporated into the design
ECAM. The first, the Test attribute, will be discussed
There are two main classes of abnormal terminations which may occur: those which result from ECAM
requests for more contiguous storage than· is currently
available in the region, and those caused by the application programs themselves.
Storage requests
As was indicated earlier, terminations due to excessive storage requests are expected by ECAM. The
amount of available space left in the region is always
known by ECAM and, therefore, a request which
exceeds the total available at any instant is never
made. However, we chose not to keep track of the
fragmentation of the region, which is caused by applications of varying sizes, since this is a normal OS/
360 function.
Such terminations occur when the Intermediate
Task attempts to attach the application subtask, and
ECAM detects it from the condition code which is
returned by the operating system to the "mother"
task of the terminating subtask. In this case, ECAM
is the "mother" task and the Intermediate Task is
the abnormally terminated task. It should be noted
that at this point a message has already been read
into main storage. ECAM saves the location of the
message and sets both a termination and quiesce flag,
the former to indicate that the application for the
message in question is the next to be executed when
storage becomes available, and the latter to indicate
that transient applications are to be removed from
storage, one by one, as they complete processing of
their current messages, until such time as enough
storage becomes available. As each transient completes
processing, it is detached and another attempt is made
ECAM
to attach the application which started it all. If another abnormal termination results, the entire process
is repeated. Eventually, it is guaranteed that enough
storage will become available, although it may be
necessary to quiesce every transient.
The installation can minimize the effect of fragmentation by designing and coding applications of
uniform size. If necessary, modules can be padded
with blanks if they are under-sized, or link edited in
overlay with equal-size segments. If this is not possible
in all cases, application sizes should be in exact multiples of each other, for example, 40K, SOK and 120K.
A pplication terminations
Some application terminations are inevitable and
although most cannot be anticipated, some can. For
those that can, ECAM allows the installation to specify
for each application up to four abnormal condition
codes, upon the occurrence of which the application
will be restarted. Abnormal termination due to an
"out-of-core" condition (CC = 80A) is automatically
considered a restart condition. In all cases of abnormal
termination, the operator is notified of the condition.
Those applications which terminate due to non-restartable conditions are flagged and made inactive.
A subsequent request by the operator that day to reactivate the application will result in an "Not Restartable" error message.
ENVIRONMENT SIMULATION
One of the great disadvantages of debugging in an
on-line environment is that it requires input from a
terminal, or set of terminals, which may be quite remote from the computer center. This cannot only be
costly, but a very slow and painful process as well. In
order to facilitate the development of application programs, ECAM provides the installation with the ability
to debug programs using sequential input from tape or
disk, while checking out the EGAM interface as well.
This state is communicated to ECAM by indicating,
via the macros provided, that the program is in a Test
rather than Production state. When the program is
activated, ECAM opens a QSAM file rather than a
QTAM input queue and a SYSOUT printer file for
output messages. All of this is completely transparent
to the application programs. Later, when the programmer feels that the application is bug-free, all that is
necessary to do to make it operational is to reset the
Test/Production attribute flag.
587
HIGH-LEVEL LANGUAGE INTERFACE
ECAM was developed primarily for COBOL installations. The move from a batch to an on-line operation utilizing QTAM requires either that processing
programs be written in assembly language or that
COBOL interface modules be written in assembler
language to provide the necessary QTAM I/O functions. ECAM provides these interface facilities. The
standard OS/360 calling sequence is used so that the
application can be written in any OS-supported language, including FORTRAN and PL/I. In addition,
in order to facilitate the processing of messages by
programs written in COBOL, the record/segment
length field in message headers is converted from a
binary toa decimal value on input and the reverse
way on output. The specific interface is detailed in
Reference 1.
OPERATIONAL CHARACTERISTICS
ECAM has been operational since early 1969 in a
large aircraft industry installation, running in a 114K
region on a 360 Model 50, using 2314 disk storage,
which is shared by two CPUs. The number of processing programs has increased from the original
three to ten, all of which are inquiry/response applications, with nine programs averaging 40K in size and
the tenth 80K. Approximately 4,000 messages are
handled daily with a considerable amount of background work, though background throughput is degraded. Response times vary from 3 seconds or less
to a worst case of several minutes. The average response time, however, is within 3-7 seconds for most
applications.
I t should be noted that in the absence of ECAM or
some similar control program, the ten processing
programs, currently running in 114K, would have
normally required 440K of main storage were they to
operate concurrently. The main storage overhead
required for ECAM itself is approximately 12K, with
no applications specified, and approximately 15K, with
six applications being driven by six input queues.
Future modifications are currently under consideration, but a careful analysis of ECAM behavior under
varying conditions is necessary before they are implemented. Among those modifications under consideration are the implementation of a priority input queue
polling sequence, the addition of a data base language
facility and inter-region communications facilities. It is
also anticipated that ECAM will be upgraded to operate
in a TCAM environment. One primary advantage of
doing so would be the elimination of the timer exit
routine, as TeAM provides a multiple-wait facility.
588
Fall Joint Computer Conference, 1970
In conclusion, I must add that perhaps the greatest
personal reward we had. in designing and implementing
ECAM is that it did all it set out to do. There is little
that is revolutionary about ECAM; it was designed
to plug a known gap in communications processing
and this it appears to have accomplished. It is to be
hoped that "fourth generation" software will automatically provide most of these facilities.
generation of test data. To both, I must extend my
gratitude for their aid in both the intermimable debugging process and in producing the documentation
for the system, much of which was used as input to
this paper.
REFERENCES
1 ECAM programmer's guide
Programming Sciences Corporation
ACKNOWLEDGMENT
2 ECAM operator's guide
Without the efforts and dedication of two colleagues,
ECAM could not have been implemented. The author
is indebted to Mr. Richard Dempsey, of Programming
Sciences Corporation (PSC), for the implementation
of the operator interface modules, some seven in all,
and for the generation of the user macros. I must also
thank Mr. Richard Loveland, also of PSC, for his
evaluation studies and subsequent improvements to
ECAM, as well as for his most welcome help in the
Programming Sciences Corporation
3 Operating System/360 supervisor and data management
services
IBM Corporation Form no GC28-6646
4 08/360 queued telecommunications access method message
control program
IBM Corporation Form no GC30-2005
5 08/360 QTAM message processing program services
IBM Corporation Form no GC30-2003
6 08/360 planning for the telecommunications access method
(TCAM)
IBM Corporation Form no GC30-2020
Programming in the medical
real-time environment*
by N. A. PALLEY, D. H. ERBECK and J. A .. TROTTER, JR.
University of Southern California School of Medicine
Los Angeles, California
Care Units, is performed by special purpose analog
devices.
As in many other computer applications areas, there
is an ample selection of available digital hardware
adequate to the patient monitoring task. Interface
hardware including transducers, pre-processors, automated chemical analyzers and display devices of the
required capability and reliability are now becoming
available. The software interface remains the major
barrier to clinical acceptance of the digital computer.
It is not the programmer who will utilize patient
monitoring system, but the physician, nurse, and laboratory technician. They may not appreciate the computer system's complexity nor forgive its idiosyncracies. 4
A major effort ~t the Shock Research Unit has been
to make the computer system transparent to the clinical
staff and to the medically-trained occasional programmer. In all interactions between the clinical staff
and the computer system elaborate and unnatural
coding schemes are avoided. All instructions, lists, and
alternatives are displayed by the computer at the bedside with computer jargon replaced by medical jargon.
Often computer system efficiency must be traded for
this improvement in the physician's or nurse's understanding and acceptance of a procedure.
INTRODUCTION
The Shock Research Unit (SRU) is a specialized clinical
research facility developed for the triple purposes of
rendering intensive care to seriously ill patients, studying underlying mechanisms of the disease process of
circulatory shock, and developing new technologies for
evaluating the status and treatment of seriously ill
patients.
A computer system for monitoring patients was developed at the SRU in 1963.1 Based upon the experience
with the initial system over a five year period, new
specifications for a system were developed. 2 This new
system has been implemented and is now in routine
use in the two bed Shock Research Unit at Hollywood
Presbyterian Hospital in Los Angeles. Figure 1 shows
one of the instrumented beds. The major goal of this
research project is to automate the critical care environment and, since the facility is supported by a federal
research and development grant, patients are not
charged for services.
The computer must· simultaneously acquire data,
control many processes in the ward and manage the
retrieval and display of information on both the current
and prior status of the patient. The adoption of the
general purpose digital computer as an accepted tool
in clinical-medical practice has lagged far behind the
predictions of several years ago. Hospital information
systems, including off-line analysis of patient data, still
constitute the major applications of computers in clinical facilities. 3 Most patient monitoring in the recently
developed specialized Coronary Care and Intensive
General system description
The primary monitoring functions are accomplished
by analog transducers attached to the patient which
directly sense physiological activity. 5 The resultant
electrical signals such as ECG, arterial and venous
pressure wave-forms, are amplified and displayed at the
bedside on a multi-channel oscilloscope. Analog signal
conditioners perform some pre-processing including the
derivation of the heart rate and detection of the R-wave
from the ECG signal, and of respiration rate from the
* The research programs of the Shock Research Unit are supported by grants from the John A. Hartford Foundations, Inc.,
N ew York, and by the United States Public Health Service
research grants HE 05570 and GM 16462 from the National
Heart Institute and grant HS 00238 from the National Center
for Health Services Research and Development.
589
590
Fall Joint Computer Conference, 1970
Figure l-An instrumented bed in the Shock Ward showing the
placement of displays and controls
venous pressure signal. The outputs of these conditioners and amplifiers are passed to a multiplexer and
A/D converter. In some cases, as in the reading of
temperatures, a single point analog read suffices and the
rugital processing consists in multiplying the converted
voltage by the proper factor. The derivation of other
parameters such as systolic and diastolic pressures, and
left ventricular dp/dt involve more complex digital
procedures. The output of laboratory test devices, now
in various stages of automation, for the monitoring of
blood chemistry values, such as P0 2 , PC0 2 and pH,
are also input as analog signals. Another category of
monitoring functions includes cardiac output6 and blood
volume determinations, the latter being calculated from
the dilution of radio-active tracers in successive patient
blood samples.
Automatic monitoring programs are run at a frequency which is a property of the particular program
and varies from once a minute for heart rate to once
every 15 minutes for temperatures. Other programs,
such as those involved in the determination of cardiac
output, are called up by use of the keyboard as needed.
Monitoring, analysis, and display of current patient
parameters is in itself an important task. However, if
this were the only function the system were called on
to perform, a sufficient number of special purpose
analog devices would serve as well. The ability to store
the monitored data in highly structured form, to
retrieve, manipulate and display the stored data in a
variety of modes and post facto rearrangements provides one of the justifications for the use of a digital
system.
An elaborate alarm system is under development
which makes extensive use of the patient data file. 7
The system employs multivariate statistical techniques
. to. examine the simultaneous values of seven physiological variables and compares them to equivalent sets
monitored 5, 15, 30 and 60 minutes previously. Estimates are calculated on the probability of occurrence
of these sets of values and changes, and the system
reports unusual changes to the ward staff. In addition,
critical processes, such as the infusion of fluids and
medication, may be automatically halted.
The patient monitoring system, as implemented, uses
an XDS Sigma 5 computer with a core memory size of
24K, 32 bit words. This Elystem utilizes standard XDS
peripherals including digital I/O, A/D converter, D/A
converter, a 3 million byte fixed head disk drive (RAD),
2 seven track tape drives, line printer, card reader and
5 keyboard displays. Other devices include an incremental plotter, storage oscilloscopes, and an alphanumeric TV display system. Those devices which allow
information to flow between the ward and the computer
are shown schematically in Figure 2.
Data are obtained from the analog and digital inputs,
and from the keyboard displays. Once collected, processed and stored in a patient's file on the disk, they are
retrieved and stored or displayed on a variety of devices
serving distinct purposes. Depending upon the device,
this is done either automatically (scheduled) or upon
request. Most communication between the medical staff
and the computer is conducted through the keyboard
displays. From these devices the ward staff can start
monitoring procedures, store textual data, can for
computation and analysis of the patient data, and
DIGITAL
ANALOG
INPUT'"
OUTPUT'"
SIGMA e
PROCESSOR
...
INPUT
-'OUTPUT
tll~~"\'"
LI
R
usc.....
lIN.,
Figure 2-Schematic diagram of the devices which provide
communication between the· ward and the monitoring
system
Programming in Medical Real Time Environment
MENU
~MTER
8EO NUMBER
£MTER PROCRAM
NUMBER
il HEMODYNAMIC DATA SUMMARY
21 tAROIAt OUTPUT LIST
31 TEMPERATURE DATA SUMMARY
41 URINE OUTPUT SUMMARY
51 BROMSING PROGRAM
61
MARO STATUS REPORT
') PATIENT ADMISSION
II HISTORY
9) PHYSICAL EXAMINATION
10) LIST O~ NURSES' NOTES
11) LIST O~ LABORATORY STUDIES
12) PATIENT OISCHARGE
13) PROGNOSTIC INDEX
141 PATIENT ~ILE PRINTOUT
IS) TREND PLOT
161
PATIENT
~ILE
RETRIEVAL
Figure 3-Keyboard display output showing the highest level list
of available summaries and procedures
retrieve information from old patient files. A special
function key loads a program to display a list of the
most commonly used programs, as shown in Figure 3.
The user then responds with his choice. The program
selected may display data from a file, or present the
user with another list representing a lower level of
choices. Selections from these lists are indicated by
entering the item number. The physiological status of
each patient is displayed above his bed on a large screen
TV monitor driven by a character generator. This
display includes the current values of the most important monitored variables.
591
manufacturers real-time monitor, RBM* (Real-time
Batch Monitor), and a subsystem which has been
developed to provide dynamic scheduling and loading
of program modules, flexible control of analog input,
data management and a variety of interfaces to I/O
devices. The primary requirements of a medical realtime system as they have been met by the SRU subsystem are discussed briefly below_
Progralll scheduling
The subsystem includes a program scheduler which
is capable of initializing tasks at timed intervals asyn-·
chronously with other tasks and without operator intervention. Although this removes the responsibility for
sequencing and program initiation from the applications
programs, one applications program may start another
as discussed below. The number of foreground processes
which may be active simultaneously is limited only by
the total core requirements of those programs, since
the system program control tables may be set arbitrarily large at system generation. The program scheduler utilizes one of the Sigma hardware clocks and the
interrupt structure which allows external interrupts to
be triggered internally.
Dynalllic relocation of prograllls
Since the SRU Patient Monitor must be able to load
program modules quickly and provide an efficient use
of core memory, object code for each task is stored on
the disk with all references satisfied, yet with the
capability of being dynamicaJly loaded using a relocating loader. There are no fixed partitions; rather,
core is resegmented as each relocatable load module is
found on the disk, and loaded into the first available
space that will contain it. Applications programs, which
may be as large as 4K words each, are not re-entrant;
fresh copies are loaded as needed,. and remain in core
until execution is completed, or until the program is
released by the user in the case of interactive keyboard
display programs. The relocating loader is effectively
limited by I/O speed, since modules are stored in core
image form, and need only to be relocated. There is a
public library of FORTRAN systems routines to lessen
the core requirements of individual modules and to
speed their loading.
SR U subsystem facilities
The SRU Patient Monitor is a library of applications
programs,written in FORTRAN, functioning within a
comprehensive executive. The executive comprises the
* A second version of RBM has recently been released with a
RAD editor which facilitates creation and maintenance of disk
files. It also permits foreground tasks to be loaded and run in
response to external interrupts. Conversion to the new monitor
is in progress.
592
Fall Joint Computer Conference, 1970
Dynalllic user control of execution priority
A variety of tasks must be concurrently served by
the same supervisor. These vary widely in complexity
and rate of execution, in dependence on I/O, and in
relative importance to the welfare of the patient. The
system allows the priority of execution of these tasks
to be dynamically altered as a function of the type of
processing, and as a function of the patient's condition
as determined by analysis programs, or by clinical staff.
Since dynamic priority reassignment is allowed without
linking tasks to any particular interrupts, it is necessary
to provide for the capability of queuing multiple programs at each priority level. The four priority levels
available to the applications programs are utilized to
maximize I/O and computation overlap, and minimize
keyboard display response time, while permitting timing
to 1/500th second accuracy within programs for process
conttol applications.
Scheduling and interleaving of real-tillle I/O
One of the major problems of real-time medical
applications is the handling of long duration, low frequency analog input requests. The frequencies and
duration of these inputs vary from signal to signal. A
scheduling structure is provided for the concurrent
input of analog data for multiple analysis programs
and the processing of data. The analog scheduler samples only those channels requested, rather than continuously sampling all 96 analog input lines. Data is
stored directly into the half-word buffer arrays defined
by the program initiating the analog request. Programs are inactive during analog input, keyboard display I/O, and other special systems operations. The
applications programmer may segment large tasks in
order to minimize core requirements during analog
sampling of long duration, using the RAD for temporary storage of arrays. The analog scheduler uses dedicated clocks and interrupts for its operation.
Data .Illanagelllent
Patient management in the critical care environment
requires on-line sequential and random access to large
patient files containing textual and numeric information.
The components and the organization of .these files
vary with changes in the monitoring requirements.
Consequently a method has been devised to associate
a unique description (or outline) with each file which
identifies the set of elements contained in that file.
The outline assists in locating information whenever it
is to be retrieved from the file. The patient file manage-
ment system serves to link the separate processes of
data acquisition, data analysis, and data display, as
wen as providing for permanent storage of all information collected.
Systellls interface routines
The use of a familiar higher level language simplifies
the writing and modification of applications programs.
Communication between the FORTRAN applications
programs and system functions is provided by a set of
system interface routines, the capabilities of which are
detailed in Table I. They are written in assembly
language, but are directly accessed through FORTRAN
subroutine calling sequences in applications tasks.
System parameters
The XDS monitor occupies 5K words of core. Our
schedulers, handlers, file management system, buffers
(currently set for two beds, and five keyboard/ crt
displays), special systems interface routines, and the
FORTRAN public library require an additional 8K of
the 24K words of core. Sufficient core (9K) is reserved
for compiling and running background FORTRAN
programs, so that program development and off-line
statistical analysis can proceed during patient monitoring. However, background processing may be checkpointed during periods of heavy foreground use. Applications programs have access to the background area
plus an additional 2K. Applications programs are added
to the library only after thorough testing, using recorded physiological signals when necessary, so that
program integrity is assured prior to actual use. Initial
debugging of new programs and addition of the programs to the library is carried out in the background
mode, but monitoring must be discontinued while the
updated library is actually being loaded onto the disk.
Between ten and twenty percent of CPU time is
consumed by the analog and execution schedulers,
which run 500 times/second. The overhead applicable
to a particular program depends on the priority level
of that program, and upon the mix of analog input and
computation time in simultaneously executing programs.
A pplications programs
The following description of the hemodynamic monitoring programs, FUZ1 and HEMO, will be used to
illustrate some of the unique capabilities afforded the
FORTRAN application program by the SRU system.
Programming in Medical Real Time Environment
593
TABLE I -System Interface Routines
SUBROUTINE NAME
SUBROUTINE NAME
Function
Parameters
ANA
Analog Input
1) Interval between samples
(in 1/500ths second)
2) Number of samples
3) Present sample index
4) Wait/return code & buffer size
5) Number of channels
6) Array of channel numbers
7) Input data buffer
8) Return priority
ANAOUT
Analog Output
1) Output control
2) Channel number
3) Voltage
AQUIT
Analog Input halt
CCIWR
Status display write
1) Format statement number
2) , ... , n) List of output variables
DELAY
Precision delays
1) Time delay in 1/500ths of a
second
DELETE
Delete scheduled
program
1) Bed number
2) Name of program to be deleted
3) Error return
DIGIN
Digital Input
1) File or bed number
2) Array of words corresponding to
digital input lines
DIGOUT
Digital Output
1) File or bed number
2) Line number
3) On/off code
GETDAT
Patient file data
retrieval
1)
2)
3)
4)
File or bed number
Summary name
Time desired or position code
Number of values requested
HEMO reads arterial, venous, and pulmonary arterial
pressure waveform data, as well as the outputs of the
electrocardiogram (ECG) preprocessor.
From these primary signals, 15 measures are derived
and stored in the patient file. Other programs retrieve
and display this information automatically and on
demand. This monitoring program normally runs once
each five minutes (Normal mode) but optionally may
be run once each minute (Acute mode) or be suppressed entirely (Wait mode) under bedside control.
The hemodynamic program is quite large, and any
combination of primary signals may not be available
at the scheduled initiation of the program. Thus, in
order to avoid loading the program unnecessarily, it is
Function
Parameters
5)
6)
7)
8)
9)
Names of the values
Array for Data
Indicator for textual information
Error return
Intercalliocation pointer
IWAIT
Wait for external
interrupt
1) Number of interrupt to be armed
2) Return priority
KDRD
Keyboard/display read
1) Format statement number
2) Parameter being read
KDWR
1) Format statement number
Keyboard/display write 2), ... J n) List of output variables
PINIT
Start program
1) File or bed number
2) Name of program to be started
3) Time between executions (+), or
interval before starting once ( -, 0)
4) Multipurpose variable passed to
program
PRIOR
Set program priority
1) Desired priority
PUTDAT
Store patient data
1)
2)
3)
4)
5)
6)
7)
8)
TIME
Get or set time
1) Get/set indicator
2) Time of Day
TTWR
Write on ward teletype
1) File or bed number
2) Format statement number
3) , ... , n) List of output variables
File or bed number
Summary name
Time to be stored with data
Number of values being stored
Names of the values
Values to be stored
Indicator for textual summaries
Error return
not started directly by the program scheduler (PSKED).
Instead, a small trigger program, FUZl, the listing of
which is shown in Figure 4, is scheduled to run once
each minute.
Applications programs as started by PSCHED
are not assigned to an execution priority queue.
They are assigned a priority by a call to the
resident subroutine PRIOR which is included as one
of the first executable statements in the program. The
nominal availability of the primary signals and the
N ormal/ Acute/Wait information is obtained from digital inputs controlled by an array of switches at the
bedside (the "status panel"). FUZI first reads the
state of the switches into an array, S, through a call to
594
Fall Joint Computer Conference, 1970
5
b
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24 7
25
26
27 20
28
29
30
31
32
33 1000
34
35
36 30
37
38
39
40
41
42 60
43
44 35
45 45
46
47
48 46
49
50
51 65
52
53
54
55 70
56
57 90
SUBROUTINE FUZI (NBED. IDUM)
IMPLICIT INTEGER (A- Z)
DIMENSION 5(13). BUFF(5). IGl(6),IG2(3)
EQUIVALENCE (ACU'rE, 5(2)), (WAIT, 5(3)), (AP, 5(4», (VP, 5(5»
EQUIVALENCE (IG2, FG2), (MZ, ZM), (HR, 5(6»
REAL FG2(3)
REAL ZM
LOGICAL ACUTE, WAIT, AP, VP, HR
DATA MZ /-1073741824/
DATA IGI/'HR ','STATl', 'STAT2'/
lBED=NBED
CALL PRIOR (2)
NP=10
LOCCT=O
CALL DIGIN(IBED, 5)
IF (WAIT) GO TO 7
CALL DISAST(IBED, 1)
IF (HR) GO TO 20
IF (AP. OR· VP) GO TO 30
FG2(1)=ZM
FG2(2)=99999· 0
FG2(3)=99999· 0
GO TO 46
CONTINUE
CALL DISAST (lBED, 2)
GO TO 90
CALL TIME (I, MOM)
IT=KHANF (IBED, 11)
CALL ANA(lO, 10, II, I, I, IT, BUFF, 2)
CTACH=O
DO 1000 J=l, NP
CTACH=CTACH+l2F(BUFF, J)
CONTINUE
CTACH=CTACH*24/16384
IF(CTACH. GT. 150· OR· CTACH. LT· 35) GO TO 65
IF(ACUTE) GO TO 35
MOML=9
CALL GETDAT(IBED, 'HEMO', MOML, I, IGl,lG2,IC, &35, LOCCT)
IHR=FG2(1)
IF(. NOT. HR • OR' FG2(l) • EQ. ZM) GO TO 60
IF(lABS(IHR-CTACH)' GT' IHR/lO) GO TO 65
IF(MOM-MOML • GE' 5) GO TO 70
GO TO 90
IF (AP. OR' VP) GO TO 70
FG2(1 )=CTACH
FG2(2)=99996.0
FG2(3)=99966.0
CALL TIME (I, MOM)
CALL PUTDAT(IBED, 'HEMO', MOM, 3, IGl, IG2, IC, &90·)
GO TO 90
CONTINUE
CALL DIGOUT(IBED, 5, l)
CALL DELAY (1)
CALL DIGOUT (IBED, 5,0)
CALL PINIT (IBED, 'TIMO', 0, MOM)
CALL PIN IT (IBED, 'HEMO', 0, CTACH)
RETURN
is negative, ANA will start to fin a buffer equal to the
size of the parameter and return control to the appli··
cation program immediately to allow processing of the
data. Where large volumes of digitized data are to be
retained, it is possible for the program to essentiany
double buffer this data and write it out on the disk.
The analog scheduler is triggered by a clock interrupt,
(presently set at·500 times per second), and the interval
parameter specifies the number of 500ths of a second
between analog reads.
If the preprocessor indicates a heart rate of less than
35 or greater than 150 beats per minute, an alarm is
sounded in the ward, using a sequence of calls to
DIGOUT (digital output) and DELAY. Then HEMO
would be scheduled by a call to PINIT. If Acute is
on, the logical array is checked further and if at least
one primary signal is available, HEMO is started by
the system subroutine PIN IT and the trigger program
exists (Figure 4, line 56).
Subroutine PINIT is used to schedule other programs
from applications programs in execution. The calling
sequence includes: the bed to be associated with the
scheduled program, the name of the scheduled program, the desired interval between executions, and a
parameter through which data may be passed to the
scheduled program. A positive value for the executjon
interval represents that interval in seconds. A zero or
negative value specifies the delay (in seconds) prior to
running the program once only.
If no primary signals are available, according to the
Figure 4-Listing of the applications program FUZl
DIGIN, with the bed number and the array name as
parameters, (Table I lists the calling parameters of all
of the systems subroutines for reference throughout this
section). If it is determined that the Wait button is
on, the program exits after calling a subroutine DISAST,
which, through a call to the system subroutine CCIWR,
writes asterisks after the values of the variables on the
status display indicating that they are not current. If
Wait is not on, any asterisks previously written are
erased.
When ECG is available, the heart rate is determined
directly by reading the cardio-tachometer output of
the ECG preprocessor (Figure 4, line 29). System subroutine ANA is used to obtain analog input. It stores
the necessary information into a table used by the
analog scheduler and optionally returns control to the
application program as a function of the return parameter. If this parameter is a + 1, ANA win fill the buffer
specified with the number of points requested while
allowing other programs to execute. If the parameter
HEMO
e··········
· · · ·. e
-...-
...
tMC.uu.". . .
Figure 5:-Diagram of data flow in the SRU Patient Monitoring
System
Programming in Medical Real Time Environment
status panel, appropriate codes are stored in a hemodynamic summary of the list structured patient file
which resides on the disk. To determine the presence
and location of information in the patient file, each
file is accompanied by an outline which is separate
from but descriptive of the file. The flow of patient
data is illustrated in Figure 5. This outline serves as a
unique table of contents for the particular patient's
data. The headings in the outline are the names of the
summaries. The subheadings comprise the names of the
individual items to be stored in the file under that
summary. Figure 6 shows some of the summaries in a
typical patient file, as represented in the hardcopy
........
PATIENT
#
BED
1057
1
•••••••
_......
PATIENT' 1051
BED
HEMODYNAMIC TIME 111/0530
HEMODYNAMI C TI ME 14/0544
ARTER IAL PRESSURE
SYSTOLIC
MEAN
DIASTOLIC
DELTA SYSTOLIC
MAXIMUM DPIDT
hEAN DP lOT
PUlSE DEfiCIT
ARTERIAL PRESSURE
SYSTOLIC
h£AN
DIASTOLIC
DELTA SYSTOLIC
MAXIMUM OP/OT
h£AN OPIDT
PULSE OEF I CIT
VENOUS PRESSURE
hEAN
DEL TA RESP
(MMHG)
75
65
59
5
-0
-0
0
(MMHG)
1
(MMHG)
91
69
58
0
PULMONARY ART PRESSURE (MNHG)
SYSTOLIC
-0
h£AN
-0
DIASTOLIC
-0
ELECTROCARD I OGRAM
HEART RATE
MAX R-TO-R INTERVAL
MIN R-TO-R INTERVAL
"SO or R-TO-R INTERVALS
ELECTROCARO 10GRAM
HEAR T RATE
109
MAX R-TO-R INTERVAL
57
MI N R-TO-R INTERVAL
55
SO OF R-TO-R I IITERVAlS
0.0
........
RESPIRATION RATE
0.0
........
RESPIRATION RATE
16
TEMPERATURE (DEG C) TIME "./0530
RECTAL
36.5
LEfT TOE
31.9
RIGHT TOE
22.9
AMB lENT
22.7
17
TEMPERATURE (oEG C) TIME ""0540
RECTAL
36.5
LEFT TOE
32.2
RIGHT TOE
22.8
AMB lENT
22.6
..•.....
........
URINE OUTPUT (MU TIME 111/0531
TOTAL OUTPUT
363.4
LAST 5 MIN
.7
LAST 60 MIN
30.3
UR I NE OUTPUT (MU TI ME 111/0546
TOTAL OUTPUT
365.4
LAST 5 104""
.6
LAST 60 MIN
17.5
••••••••
CARDIAC OUTPUT TIME 111/0526
CARDIAC OUTPUT LlMIN
BODY SURfACE AREA MSQ
CARDIAC INDEX L/MIN/M
APPEARANCE TIME SEC
h£AN CIRC TIME SEC
CENTRAL BLOOD VOLUME ...
STROKE VOLUME "'HEART fORI< KGM/MIN
RES 1 (MAP-CVP)/CO
RES 2 MAPICO
r
FILE
MANAGEMENT
ROUTINES
"----I
1
.
APPLICATION
PROGRAMS
PATIENT
FILE
MONITORING
DEVICES
PATIENT
OUTLINE
Figure 7-Flow diagram of the applications program which
monitors hemodynamic signals
9
-0
PULMONARY ART PRESSURE CMMHG)
SYSTOLIC
-0
h£AN
-0
DIASTOLIC
-0
97
64
62
DATA FLOW
-0
VENOUS PRESSURE CMMHG)
MEAN
6
DEL TA RESP
-0
13
-0
595
3.41
2
2.09
8
21
Figure 6-Exatnple of hard-copy patient file output showing
several summaries at two different times
output. Data storage is accomplished by a call to the
subroutine PUTDAT (Figure 4, line 49). Symbolic
labels for the items to be stored are contained in an
array which is an argument in the call, as is the array
of corresponding values. The time of day, another
parameter, serves as a sequencing element in each
summary.
If the Acute button were not on (Figure 4, line 36),
indicating 5 minute monitoring, the most recent hemodynamic summary would be retrieved from the patient
file through a call to GETDAT. The parameters in the
call to GETDAT are all analogous to those in PUTDAT,
except Time. This parameter may be an actual time of
day, in which case the values of the most proximate
instance of a summary are returned. Or it may be a
code requesting an instance of a summary by its position in the file, (e.g., the first, last, previous, or next
instance). The current time of day, obtained by a call
to the subroutine TIME, is used to calculate the
elapsed time since the last HEMO instance. If this were
greater than or equal to 5 minutes, the hemodynamic
program would be scheduled; otherwise FUZI exits.
Just prior to starting HEMO, the trigger program
also starts a time code output program, TIMO. Using
calls to TIME, DIGOUT and DELAY, this program
generates a series of variable width pulses representing
the binary coded decimal 24 hour time. This signal is
recorded on a multi-channel analog tape recorder along
with the primary physiological signals.
HEMO proceeds as shown in Figure 7. The status
panel is checked and the appropriate analog channels
596
Fall Joint Computer Conference, 1970
to be read are determined by reference to the bed
number parameter with which the program was started.
A call to DIGOUT, with a bed and line number, turns
on a light at the bedside indicating the signal being
monitored. The arterial pressure signal and the R-wave
trigger output of the ECG preprocessor are sampled
simultaneously for 10 seconds at the rate of 100 samples
per second (the R-wave trigger generates a pulse corresponding to each heart beat found in the ECG signal).
Data acquisition is accomplished by a single call to
ANA which stores 2000 digitized points as 16 bit numbers (half words), in the assigned buffer. On completion
of the A/D conversion a second call to DIGOUT
extinguishes the monitoring indicator light. The array
containing the digitized ECG data is then scanned to
locate the heart beats, the relative positions of which
are stored in a table. The inability to detect a sufficient
number of them in the 10 second sample, or the presence
of excessive noise in the ECG signal causes the program
to take an alternative path.
Assuming a good ECG, the arterial pressure data
points are then scanned with reference to the R-wave
table. The maximum and minimum arterial pressure
values detected between each pair of corresponding
heart beats are stored. Anomalous arterial pulse beats
are located on the basis of pulse height criteria and
transient values which exceed physiological limits are
eliminated. The remaining maxima and minima are
averaged and temporarily stored as systolic and diastolic pressures. The entire arterial pressure data array
is averaged to compute the mean arterial pressure.
The maximum, minimum, average, and standard deviation of the intervals between heart beats is computed from the R-wave table. DIGIN is called again
to read the "status panel". If any switch positions
have been changed, the program exits. Otherwise an
additional 10 second sample of AP and ECG is read
and analyzed as above. The results of the two analyses
are then compared; if the differences fall within preset limits, the second set of data is retained and the
program continues; if not, a third set is read. The new
data are either accepted as consistent or, ultimately,
are stored in the patient file with a code indicating the
inconsistency of the sequential samples.
Venous and pulmonary arterial pressure signals are
then sampled by another call to ANA. From these data,
mean venous pressure, average pulse height, and systolic, diastolicand mean pulmonary arterial pressures are
computed. Throughout the program the values are assessed as to whether they lie within reasonable boundaries. If not, or if the primary signal associated with
that variable is unavailable, a value of -0.0 is assigned and an appropriate missing value code is stored
in a status word. All of the data, including the status
word, are stored in the patient file associated with the
bed number. The array of data is stored by a single call
to PUTDAT ,as an instance of the summary named
HEMO, identified by the current time of day.
SUMMARY
The HEMO program is one of 61 applications programs
currently in the library. It is representative of the
complexity of processing required in patient monitoring
programs. Some examples of other applications programs and their characteristics are shown in Table II.
An additional dimension of complexity is contributed
by the requirement of simultaneous monitoring of more
than one patient. Thus several programs such as
HEMO may be in various stages of execution concurrently. Some of these programs may be executed
on a scheduled basis while others are executed upon
request of the clinical staff, making it difficult to predict
the demands to be placed upon any subsystem of the
computer. Simultaneous collection of data from many
analog devices, storage and retrieval of data from
patient files, and display of information on patient
status on a variety of devices with varying transmission rates is a common occurrence. Some of these
tasks can be deferred or delayed in their execution,
but others with crucial responsibilities, such as controlling the infusion of fluids and medications, cannot
tolerate interference and may be required at any time.
Unlike a process control situation where the responses
of the monitored activity are well defined, patient
monitoring relies significantly upon clinical intervention.
Thus when programming a particular application module for such a system, the programmer cannot foresee
the computer environment in which execution will
occur.
The extensions to the executive system and the interface routines described above free the applications programmer from the logical complexity usually entailed
in writing programs for such a multiprogramming
environment.
Since the patient monitoring system is simply a collection of independent applications programs, wherein
the implications of concurrency are resolved dynamically, the expansion or modification of this library can
be done with only minor regard for such concurrency.
This is a feature which is pleasing to those who have
experienced difficulty incorporating additional features
into an operating real-time system. This openendedness
becomes a necessary feature in the medical research
environment where the system must often be reshaped
to respond to changes in care methodology. Finally,
the ability to write applications programs In
Programming in Medical Real Time Environment
597
TABLE II-Characteristics of Selected Applications Programs
Program
Name
1 FUZ1
Function
Schedules execution
ofHEMO
Primary Input
Signals
Devices IFacilities used
Patient file system(PFS),
digital input (DI),
digital output (DO),
analog input (AI),
program initiation (PI)
Cardiotachometer
Data
Sampling
Execution
rate
(samples I Interval
sec)
(minutes)
50
1
100
1-5
Systolic, diastolic,
mean arterial, mean
venous, and mean
pulmonary artery
pressures, heart rate,
pulse deficits, heart
rhythm, DPIDT etc.
Thermistors
10
15
Rectal, left and right
toe, and ambient
temperatures
Collector tube fluid
column height
10
5
2
HEMO
Monitors hemodynamic PFS, DI, DO, AI
signals
Arterial pressure,
venous pressure,
pulmonary artery
pressure, ECG
3
TEMP
Monitors patient
temperatures
PFS, DI, AI
4
URIN
Monitors urine output
PFS, AI, DI, DO
5
PLT2
Writes 8 variable time- Keyboard! display
trend plots on storage (KID), PFS, AO, DO
scopes
Demand
6
MENU
Displays highest level
list of user options
Demand
7
HEDS
Displays Hemodynamic KID,PFS
variables
Demand
8
DFIL
Generates lineprinter
listing of a patient file
PFS, Lineprinter
Demand
9
CARD
Monitoring and calculation for cardiac
output procedure
KID, AI, AO, DI,
DO, PI, PFS, storage
scope, ext. interrupts
KID, PI
10 LACT
Determination of blood KID, PFS, TTY, PI
lactate
11
Automatic control of
pump operation
PUMP
KID, DI, DO, AO,
PI, PFS
Derived Variables
Densitometer
Laboratory determination entered
through KID
10
Total output,
output/5 min.,
output/60 min.
Demand
Cardiac output, stroke
volume, central blood
volume, peripheral resistance, heart work,
appearance time,
mean circulation time
Demand
Lactate
Demand
598
Fall Joint Computer Conference, 1970
FORTRAN, aside from the obvious advantage of ease
of documentation, encourages the clinician to participate in the development of monitoring algorithms.
ACKNOWLEDGMENTS
The authors wish to express their appreciation to Max
Harry Weil, M.D. and Herbert Shubin, M.D., Project
Director and Co-Director for their support and encouragement, and to David H. Stewart for his invaluable suggestions. Particular thanks are due Miss Cecilia
Pasos for her skill and patience in preparation of the
manuscript.
REFERENCES
1 M A ROCKWELL H SHUBIN M H WElL
Shock I I I: A computer system as an aid in the management
of critically ill patients
Communications of the ACM Vol 9 No 5 May 1966
2 D H STEWART D HERBECK H SHUBIN
Computer system for real-time monitoring and management
of the critically ill
AFIPS Conference Proceedings Vol 33 December 1968
3 J P SINGER
Computer based hospital information systems
Datamation May 1969
4 D H STEWART N PALLEY
M onitm-ing and real-time evaluation of the critically ill
Invited Paper-Journees Internationales d'Informatique
Medicale Toulouse France March 1970
5 H SHUBIN . M H WElL M A ROCKWELL
A utomated measurement of arterial pressure in patients by
use of a digital computer
Medical & Biological Engineering Vol 5 pp 361-369 1967
6 H SHUBIN M H WElL M A ROCKWELL
A utomated measurement of cardiac output in patients by use
of a digital computer
Medical & Biological Engineering Vol 5 pp 353-360 1967
7 S T SACKS N A PALLEY A A AFIFI
H SHUBIN
Concurrent statistical evaluation during patient monitoring
AFIPS Conference Proceedings Vol 37 1970
Decision making with computer graphics
in an inventory control environment
by J. S. PROKOP
Office of the Secretary of Defense
Washington, D.C.
and
F. P. BROOKS, JR.
University of North Carolina
Chapel Hill, North Carolina
INTRODUCTION
displayed in a variety of formats on standard computer
printer paper. The statistics included:
(1) percent availability of stock,
(2) number of purchase orders generated,
(3) lost sales,
(4) total dollar investment in inventory.
The output was in the form of tabular listings and
bar graphs. Also, for each problem, an IBM 2250
cathode ray tube display unit was programmed to
show the same data as appear on the printer output, in
fundamentally the same listing and graphical formats.
Thus the experiment did not attempt to establish the
relative comprehensibility of listed versus plotted data.
Instead it investigated the relative comprehensibility
of printed versus display presentation of such data, both
printed and plotted. The display unit was under the
control of the decider, who was able to specify which of
the twenty-four months and the kind of displayed data
which he wanted to see. In both display and printer
output cases, he was expected to start at the first month
and proceed through the months in order, with freedom
to review.
The course participants were divided into two test
groups, each group consisting of nine individuals chosen
at random. Tests were made to answer:
Computer-driven displays have long been thought to
help decision making. But the justification for using
these devices in decision-making has been long on
intuition and short on quantitative analysis. To see if
this intuition was right, we conducted an experiment.
Eighteen interested and experienced decision-makers
in the inventory control field met for twenty class hours
of instruction in advanced inventory control techniques.
Near the conclusion of the short course, we measured
the participants' decision-making abiJity while using a
computer-driven display device. This measurement was
compared to their decision-making ability while using
information presented to them on paper.
To provide a vehicle for the investigation, a simulator
was written to apply certain inventory control policies
to a hypothetical inventory system handling 34 items.
This inventory system faces a randomly derived set of
orders, price changes, replenishment of stock and other
transactions. The simulator has two sets of input
parameters: one governs the distributions of transactions; the other establishes the management policy for
inventory control. The simulator investigates twelve
distinct policies at one time over a simulation cycle of 24
months.
Each participant was given, as examination problems,
the statistics resulting from two different simulation
runs. Each decision-maker, or decider, made a series of
decisions; at the end of each simulation month, he
ranked the twelve policies in order of desirability. Each
decider used printer output on one problem and graphic
display presentation on the other.
The statistics from the simulation program were
1. Are decisions made earlier? The simulated cal-
endar month (out of the twenty-four months of
simulation) in which the decider feels he has
enough data to commit himself to a ranking for
future action was tested.
2. Are decisions made faster? The elapsed clock
time to decide on a ranking of policies which the
decider would be willing to commit himself to for
599
600
Fall Joint Computer Conference, 1970
future action was tested. The elapsed clock time
to complete the remainder of the problem was
also tested. After committing himself to a
ranking, the participant continued the problem
through the twenty-fourth month.
3. Are decisions made more consistently? That is,
does the decision made at the month of commitment agree better with that made at the
twenty-fourth month, after all data are known?
4. To what degree do the members of each group
agree among themselves in regard to the
rankings?
In summary, the decider made two basic kinds of
decisions. He decided on a ranking at each month in
turn, and he decided whether or not to indicate at this
month that he felt confident enough of his ranking to
recommend that it be used for governing action.
The resulting ordered lists of policy sets and the
preparation times were analyzed in two basic ways.
First, a 2 x 2 Latin square design with repeated
measures was used in an analysis of variance. Rank
order statistics were then used to test the consistency of
each individual decision-maker and the concordance of a
group of decision-makers.
The statistical analysis of variance allocated the
observed differences into (1) differences between graphic
and printed data presentation (treatment), (2) differences between· the first and second problems done by
each participant (order), and (3) differences between
the performance of the two groups the class was
divided into.
The ranking of the policies at the decision month and
the ranking at the end of the entire twenty-four month
simulation were compared by means of the Spearman
uw..:ww_WUt.
< "00
I ~ "00 4- ~ "',000 I
I
I
l O t
0,
)0
11.001'
:------ii--..
--~------------o------:----------o-----:--------0---:
, ___________ 1__________________ 1____________ 1____________ I
I
()
I
0
1_ _ _ _ _ _ ------,-------------______ 1____________ 1 _ _ _ _ _ _ -_,
I
I)
I
0,
I)
I
1
I
, - - -______ 1______ ------------,-----______ 1______ - - - - - - _ ,
I
0
I
0
I
2
t
0
I
,----=-------'------------------,-------------1--------1
:...:---------0---:-------0---1-------,---: ----------,-----:
:--------5---:-----------,------: -------n---:----:-·---T---:
I
l!
4t!-, to 1 100e
I)
I
0
I
I)
I
)
12
TC'lTUIUII. . OPtf'P."S:
1
Losr SiLlS
'.00
••• .,11
I
IH»,5111."
.
,
.,25 .... 0.56
.
lnlL18ILr·,
99."
99.21
:!::!
11 --.~.. -~=:..
i
g~s
.fi~n
==~i:5
::. . __
_~_----=:;L _____ ~ _ _-..JI;;.
..~io&:;;..':....; ________....=
......n,....
-......
.........
...,......
..,..•.
I:::::::::
••,1...
• ...
-
,.~
I
-.111 ••
... .a....
atU""AI
-ft
-••
.&
" ....._ _ _ _ _ I L _ _ _ _ _ _
Figure 2-Sorted listing of simulation results by
policies within month
rank correlation coefficient. A Kendall's coefficient of
concordance was computed to measure how wen the
ran kings produced by each test group on each problem
agreed among themselves.
The results may be summarized as follows:
1. The time to make a decision was decidedly
reduced in favor of the display presentation.
2. A decision could be made on the basis of less
information by using the display device; that is,
action decisions were made earlier in the
simulated two years.
3. More consistent decisions were arrived at by
using this display' device. Even though action
decisions were made earlier, with less information, using the display device, the decisions made
matched better those made with all data
available.
LIlt '!'(I'! at "
o
THE PRESENTATION TO
MAKER
THE
DECISION-
I
, ______________ 1___________________ 1____________ , _ _ _ _ _ _ -I
CA'flGOftT
·lBP.r"'~'T -.~-
:Eir"BIT
:j:::
"U,010.15
CUIIULlTIfI! 10ft!!" or PlJJClln lC'fIOWS roft tIIt'l) POtTC't •
S7
cuftounn "lJftlllll If/I 'fIIlSACTl1JS (;1!W!IlTn OIlDI!I Tns POLlet·
Figure I-Detailed listing of simulation results by
policy within month
The simulation statistics for one month are shown in
Figures 1, 2, and 3. The total investment figure is scaled
by 100,000. A total investment of $423,000 is, therefore,
represented as $4.23 .
Figure 2 is a table which is ordered by several of the
statistics of interest. Figure 3 shows one statistic across
al1 policies as a bar graph. The printed bar graphs are
produced monthly for availability, value of lost sales,
purchase order activity, and total investment.
Decision 'Making with Computer Graphics
casU1.lTnl LOS!
S.t~S
111 ne,.,.I"s",
601
12.000
000000000000000000000001)"',111,',1111111,',1111122222222222
OO',222lJ""5'6,1" ••• "OOO',22211'·'!tS""'7I •• "OOOl'2221) •
• • 2 6 0 • • :I 6 0 • • :I , 0 II , :I 6 0 . . . :I 6 0 III , :I 6 o. II :I II 0 " • 2 , 0 .... 2 6 O • • :I 6 0 • • l f 'l • jill 2 , ~
, ............u ...............................................................................................
2 ............ 0 ...................... 0 ............................... .
III ..............................UII........................................ .
'S •••••• 0 .......................................................................................................... .
6 ................................................................... U ........................................ ..
......................
fOttC1'
" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..
roue",
'0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PQl.Ie:, 1111.........................................................................
0
roJ.le, 12",,"'''''''''''''''' ''''''''''''''''''
Figure 3-Bar graph of simulation results by month
across all policies
Once the printer output was specified, these presentations were mimicked on the IBM 2250 cathode ray tube.
Some exploration of the power and utility of such a
display device was made while maintaining similar
presentation formats for sake of the experimental
design. Figure 4 is the display device representation of
Figure 2, for example, and shows some rearrangement
of material due to display character and line number
limitations. Figure 5 shows the first marked departure
from the printer output of Figure 3. The layout is
essentially the same, but the presentation is dynamic.
A programmed timer advances all lines of the bar graph
simultaneously at one second intervals. If the user
specifies a month at which he wishes to examine the
data, and then specifies the bar graph he wishes to see,
the graph begins at month 1 and then advances at
one-second intervals to the month requested. The user
may alternatively specify half-second intervals. The
movement of the bar graph gives a feeling for the
Figure 4-Display of Figure 2
Figure 5-Display of Figure 3
history and current derivative of the statistic under
scrutiny. In addition to the movement of the bar graph,
the symbols <, > and = are used on the display unit to
indicate whether the value of a particular bar has
increased, decreased or remained equal in comparison
with the previous month.
Figure 6 has no printed correspondent in this
experiment. While the data for cost of lost sa~es,
availability, total dollar investment and purchase actIOn
activity are available as individual bar graphs as
repres~nted by Figure 5, all four of these are available
Figure 6-Quadrant graph of simulation results by month
across all policies
602
Fall Joint Computer Conference, 1970
at the same time in the Quadrant Graph. All bars move
under the same program timer control as the individual
graphs.
The user indicates by a ,Programmed Function
Keyboard (PFKYto the computer what he wishes to see
on the display device. The user is allowed to refer to any
past month's data. He may not, however, move ahead in
simulated time by more than one month at a time.'
THE SUBJECTS OF THE EXPERIMENT
The yxperiment was,designed to examine the decisionmaking processes of experienced, practical and interested
professional administrators of inventory control. Hence
the subjects were solicited carefully. A short course in
advanced inventory.control techniques was designed as
a graduate-level course which would attract only those
who were interested in the subject matter and who were
prepared to understand the material. The simulation
model was the experimental vehicle and was used in
examples and problems which were integrated into the
course. The participants came to the course in statistical
invenFory control for their own professional advancement, under the auspices of the firms for which they
worked. The participants were not informed of the
experiment which was being, conducted, and they
received the full measure of instruction for which they
came.
We solicited participants from nearby manufacturing
companies specifically for this short course. Candidates
for the course had to have experience in inventory
control and had to be in a decision-making position in
the company. No company was allowed to sponsor more
than two candidates.
The participants attended the course for two hours
every weekday morning for two weeks. The mornings
were chosen specifically to ensure that the attendees
would have the active support of their ~ponsoringfirms.
The subjects were divided randomly into two groups
of nine people each. After a substantial part of the
course material had, been given, the participant~ were
given either a problem book with twenty~four months
of simulation output (Figures 1,2,and 3) or assigned to
work a ,problem on the display unit at individual
labor~tory sessions. The second problem was assigned
later in a similar manner except the groups now used the
presentation method that they had not used on the first
problem. It was explained thateongestion on the display
uiIit preclu4ed everyone working both problems in this
way. There was no attempt made to identify individuals
by group membership or emphasize this distinction.
The participants were not graded on these problems
and were encouraged to work them as part of the
education process of the course to investigate some of
the fundamental properties of the inventory control
policies. Although all of the inventory control policies
simulated for the two problems were discussed in class,
the specific problem policies were not identified, in order
to avoid obvious bias. The participants, then, were
asked to make their judgment based solely on the
simulation results. The two problems were of equivalent
difficulty.
An operational setting was postulated for the
problem. Higher-level management had presented the
participant with the output data for the set of twelve
inventory control policies, and had requested a
recommended ranking so that an implementation of
policies could be decided upon. The participant was
encouraged by management to present his recommended
ranking as soon as possible, but cautioned that implementation of the recommended policies could have
serious repercussions in the firm, so his best professional
judgment was required. Participants were reminded to
keep accurate figures on elapsed time spent studying
each month's data, and were also reminded to mark the
decision month at which they would have presented that
ranking as an action recommendation to higher level
management.
In such an experiment there are two possible
approaches to the problem of evaluating the quality of
the decisions made. The most commonly used approach
is to furnish the subjects with the criteria which are to
be used in evaluating the decisions. For example, in
many cases the subjects are first given instruction, then
tested to ascertain how well they perform as measured
against the pre-established criteria.
This method of measurement may be dependable
when the material is objective and the criteria are easily
established. In inventory control (and many other
problems) the weightings to be used in reaching a
decision, are highly individual. For example, one firm
may emphasize high availability, whereas another may
give heavy weight to low investment. When the
experimental subjects are experienced in the field and
have developed their own criteria for decisions, the
method of measuring against instructor-set criteria is
unsuitable. One cannot know the extent to which the
subjects followed the instructor's criteria and the extent
to which they followed their own.
In this experiment we followed an alternative
approach to the problem of evaluating the quality of
decisions The. subjects were experienced in decisionmaking and were familiar with and interested in the
substance of the course. Therefore, they were, given no
weightings, no criteria of excellence by the instructor.
Instead they were explicitly told to apply their own
several diverse sets of criteria. The quality of their
Decision Making with Computer Graphics
decisions was then measured by the consistency of each
subject's own ranking at the month of commitment with
the later ranking when full information was available.
Although this second approach almost eliminates the
meaningfulness of comparisons which show how well the
subjects agree with each other, such measures were
taken as a matter of interest. The use of self-consistency rather than artificial criteria does, however,
improve the credibility of the other statistics. It also
substantially improves the generalizability of the
results, for it shows the effect on decision-makers when
deciding by their own standards, rather than by those
dictated by a ,simplified theoretical model. In subtance,
one attempts thereby to examine the decision process as
it works under operational, rather than classroom,
constraints.
THE DESIGN OF THE EXPERllVIENT
Two main analyses were performed on the data: an
analysis of variance of the Latin square design, and a
computation of rank order statistics.
In the Latin square design of this experiment" it
should be noted that instead of experimenting on
different subjects in each cell of the square, the same
experiment group was involved in both cells of a row. In
effect, each group acted as its own control group.
Experiments in which the same subjects are used under
all q treatments require q observations on each subject,
and are called experiments with repeated measures. In this
experiment q = 2 since we are dealing with two
treatments and each subject is observed twice.
The 2 x 2 Latin square with repeated measures of
Table I was used to analyze the data for:
1. Simulated calendar time to reach a decision
(decision month),
2. Actual elapsed time to complete the ran kings
through the decision month,
3. Actual elapsed time to complete the problem
after the decision month,
4. Correlation coefficients for the consistency of the
committed decision with the final ranking,
TABLE I-Latin Square Design
Order 1
Order 2
Group I
(9 'Individuals)
Display
Printer
Group II
(9 Individuals)
Printer
Display
603
in order to produce an analysis of variance of these
statistics. When we discu~s the effects of treatment in the
following pages, we will be discussing whether the
display device or the printer demonstrated more
influence in our measurements. The effects of order will
refer to the influence of the participants' doing the
problems in the order given to them.
The particular design was chosen in part to isolate
that variation due to natural differences between the
experimental groups. The separation of the source of
variation due to group differences allows a better
measure of' that variation due to the form of data
presentation, which is the statistic of real interest.
Since the values of the decision month are positive
integers, they were, as is standard, transformed by
taking the square root, to make the variances more
homogeneous and at the same time to normalize the
distribution. It is this square root value which is used
in the analysis of variance computations, and reported
in the results.
It is of interest to compare the rank order of the
inventory control policies at the decision month and the
rank order at the twenty-fourth month for each
individual. This comparison gives a measure of each
individual's consistency between the ranking decision
made at the decision month and that ranking decision
made when full information was available. These two
rankings for each participant are compared by means
of a Spearman rank correlation coefficient (rs) test. Once
computed, these values for rs are treated as data for
analysis in the Latin square design previously discussed.
Since the rs values are known to have a skewed distribution, a standard transformation was made on each of the
rs values in order to place the data on a symmetric scale,
so as to normalize the distribution.
In order to find the extent to which the members of
each group ranked the policies the same way under the
same conditions, Kendall's W coefficient of concordance
was computed for each cell of the Latin square. From
this, an average rs vaJue of Spearman's coefficient was
computed for each of the four cells. This gave a measure
of 'the homogeneity of decisions under the conditions
of each cell. These values of average r8 indicate a degree
of concordance, or how well the group members agreed
among themselves as to the rankings. In the interpretation of the result of this computation it should be noted
that this experimental group was not attempting to
apply a common criterion of excellence in making their
decisions. Individual best judgment and experience in
the decision process guided the problem solution. The
course which the subjects attended neither taught nor
encouraged uniformity in decision-making or In
performance goals.
The difference between the two values of r8 just
604
Fall Joint Computer Conference, 1970
discussed is that the single value of average rs derived
by way of Kendall's W statistic is a measure of agreement among al1 nine participants within a cell; whereas
the individual values of r8 derived from Spearman's test
are a measure of each person's consistency.
RESULTS
The data analyzed and the detailed results of the
analyses are available from the authors. This section
of the paper will highlight some of the results.
The usual method in statistical hypotheses testing
involves setting the significance level of the test in
advance of obtaining the data. The convention used in
the analysis of variance deviates somewhat from this
formality. The value of F (the significance level of the
variance under investigation) is reported to exceed a
specified percentile by a comparison with tables of
critical values. This allows each reader to establish his
own significance level and to judge the results thereby.
We will consider a conclusion to be more surely
estabHshed if the probability of its truth is higher. This
methodology does not allow a measure of the power of
the test; however, the procedure is valid for estimating
the probabilities of the observation in relationship to the
assumed sampling distribution. In this investigation we
would have been encouraged to find significance at the
.05 level, and the significance levels actually attained
are noted in this discussion.
The decision month
In this analysis of variance, we were principally
interested in investigating the effect of the treatment on
the subjects. Our first question was: How early in
simulated time can a decision be made?
We found that there was less than one percent
probability that the observed differences between
treatments were due to chance for this question. We can
say with a high degree of assurance that the mean
decision month arrived at by using the display unit was
indeed less than that using the printer output. From
another viewpoint, the participants on the average
needed to look at less data with the display unit to make
a committing decision than they did with the printer
output. N o effect could be attributed to order.
The time to make a decision
The elapsed clock time for a participant to commit
himself to a ranking was analyzed next. The mean time
to decision using the display unit was, with great
certainty (>.999), less than the mean time to decision
using the printer output. This indicates that the amount
of time spent in making a decision was significantly
reduced in this experiment by using the display device,
confirming the intuitive belief that a person can
assimilate a large quantity of data and correlate these
data by using display techniques, as opposed to printer
output. The convenience of having virtually instantaneous recall of data displays by using the Programmed
Function Keyboard is certainly a consideration in the
interpretation of the results. Pushing buttons is just
inherently faster than paging through a book of data,
however well arranged and indexed the book may be.
However much or little this consideration affected the
results, they show that data can be correlated faster and
retained better from a properly programmed display
unit.
Unsolicited comment from individual participants
supported this conjecture without exception. We
observed that the dynamic graphs gave the participant
a much better intuitive feel for the situation, and that he
was more likely to retain this impression and not have
to refer to past data repeatedly. A major help seems to
have been the program control which always started
the dynamic graphs at month 1 and brought them up to
the current month in increments of one month per
second. This forced a continual review of the history and
derivative of the measure under consideration and
undoubtedly reinforced past impressions. It was seldom
that a participant asked that the graph be stopped at a
month prior to his current month so that he could
review the static situation as of that past instant. We
noted when the experiment was well under way that the
participants with more experience as inventory managers used the dynamic graphR extensively, where the
less experienced participants relied on the tabular
listings presented on the display unit.
The time to finish the problem
The analysis of variance of the total elapsed time to
complete the problem after the decision month was
examined. One would expect some speed-up by participants after they had made their commitment decision,
simply to get to the end to see how well they did. There
is some evidence of this speed-up in the time data. How
much of this is due to increased familiarity with the
problem at hand and how much is due to impatience to
get to the final result is difficult to say. The elapsed time
after the decision month was tempered by the requirement that the data be ranked at each month. From
personal observation, the participants appeared to be
conscientious about following the spirit and the letter
Decision Making with Computer Graphics
605
of the instructions, but relieved that the big decision had
been reached, and were in a hurry to finish the twentyfour months to check their final ranking against their
decision month ranking.
The order factor was significant at the .01 level, which
is reasonable and consistent with our previous comments
on the effects of order. In this test the treatment factor
was completely without significance which is also a
reasonable result in view of the observation concerning
the impatience to finish the problem.
TABLE II-Values of Average rs Arranged in Latin Square for
Final Month
Individual consistency in decisions
spite of the earlier month of commitment. This earlier
commitment would be expected to make consistency
worse.
For the transformed Spearman correlation coefficient,
rs, the order factor was highly significant; the significance
was at the .001 level. Thus we accept the hypothesis
that maturation would appear to playa large role in the
decision-making consistency that is being measured.
That is, the ability to meaningfuHy rank a set of
policies grows with practice.
The transformed Spearman rank correlation coefficients, rs , were then subjected to an analysis of variance.
We found a significance level of .05 for the treatment,
and we obviously do not have the clear mandate that
our other treatment factor statistics have given, but the
evidence is that the mean correlation coefficient is
higher using the display unit than using the printer
output. The values of rs give a correspondence between
the participant's ranking of the policies at the decision
month and his ranking at the last month of the
simulation data, month 24. This, then, is a measure of
the consistency between these two rankings. It is also a
measure of the participant's discrimination ability-that
is his ability to decide whether he has enough information to commit himself to a ranking or not. A decision to
commit too soon in relation to each individual's ability
and ranking criteria would, in most cases, result in a
poor correlation coefficient, whereas being overly
cautious and waiting beyond the point where he had
sufficient information could not be expected to materially improve the correlation coefficient. Thus, we
might say that one interpretation of a low rs would be
that the participant committed himself too early. Other
interpretations are, of course, that he simply used poor
judgment in his ranking, or that he materially changed
his ranking criteria after the decision month. Participants were cautioned to use a consistent ranking schema
throughout. As an extreme example, we pointed out to
the class that to rank the policies based only on lost
sales data through the decision month, then to abandon
that schema and to rank the policies only on number of
purchase orders generated would not be showing
responsible judgment. On the basis of these comments,
we -should be able to narrow our consideration of a
principal cause of low rs to either too early commitment
or poor ranking judgment at some point. Both of these
essentially are measures of decision-making ability and
we can accept either one or both as reasonable interpretations of a low correlation coefficient. Observe that the
greater consistency observed for the display results is in
Order 1
Order 2
Display
Printer
.639
.856
Printer
Display
.485
.947
Group I
Group II
Group consistency in decisions
The results of the decision process at the end of the
twenty-fourth month, when the decider had full
information available to him, were next examined for
averager s • The resqlting average rs is represented in our
usual Latin square format in Table II. Here the effect
of Group II going from printer output at Order 1 to
display unit output at Order 2 is pronounced. There was
a moderate increase in the average rs for Group I going
from display to printer output, which may be ascribed
in part to maturation. However, the average rs almost
doubling in Group II when going from printer output to
display output may be more than can plausibly be
ascribed to maturation alone. In the' case of these
rankings at the twenty-fourth month, the values of
average rs are a valid measure of concordance. Remember that in the rankings at the twenty-fourth month,
the deciders all had the same amount of information
available to them, which would not have been the case
for a decision month ranking. Additionally, the
participants at this point were concerned only with the
ranking process, and not the additional question of
whether cr not to indicate a decision month.
CONCLUSIONS AND REMARKS
The strongest result statistical1y was that actual time
to make a decision was reduced in favor of the display
presentation.
606
Fall Joint Computer Conference, 1970
A second statistically significant result was that a
decision could be made earlier,or on less complete data,
by using the display unit. This is the most significant
result economically. And a one percent result is very
strong, statistically.
The mean time over both problems to reach the
decision month using the display device was 52 minutes.
The mean time using printer output was 82 minutes.
This result points to the use of a display presentation
when economy of time or simply volume of printed
output is a serious constraint on the system or the
decision-maker. The mean decision month was 9.2 while
using the display device and 11.3 for the printer output.
While the two results reported above have the
respectability of high statistical significance, the next
results to be discussed· are at least as important in the
evaluation of the experiment. These are the results
which answer the question of whether a bf3tter decision
can be made with a display device. We will claim that a
decision at the month of commitment that is more
consistent with the final decision is a better decision.
The results from Kendall's W statistic and from
Spearman's rank correlation statistic show that the
subjects when using the display tended to make
decisions more consistent with themselves, and even with
their group.
The economics of a system of display devices for
decision-making will not be explored here, however, it is
evident that the very specialized research equipment
used for this experiment is both expensive and unnecessarily elaborate for an operational system.
The minimum display unit for implementation of an
information system of· this general type should have
alphanumeric display capabilities and a programmed
function keyborad, or equivalent means of easy display
selection. The size of the display face is crucial to the
extent that it must be able to contain enough material
to be of interest and still allow character size and
spacing to enhance readability. For instance, the IBM
2250 used in this experiment has a display face twelve
inches square with a maximum capability of fifty-two
lines of seventy-four characters each. The information
in the displays for this investigation is rather densely
packed and is digestable only by someone sitting in the
console chair immediately in front of the display face.
A smaller display face would mean that displays would
have to be segmented; the same information in smaller
characters on a smaller display face would be the wrong
compromise. With segmented displays, more programmed function. keys would be needed and the
problem of how to ask for a particular display becomes
more complicated for the user. It is unfortunate that the
great majority of available alphanumeric display units
have small display faces--·eight inches by six inches
appears to be a popular size. Other features of the IBM
2250, such as an alphanumeric typewriter keyboard,
line-drawing capability, and a light pen, are unnecessary
for this application.
In addition to the display device proper, this experiment used other system facilities. The display unit had
a self-contained buffer of 8,192 characters. Of this, a
maximum of 2,000 characters of buffer stora.ge were
used at anyone time. The display program in the main
storage of the IBM 360 Model 40 used approximately
13,000 characters for program and 21,000 characters for
tables. An additional 46,000 characters of disk storage
were used for table overlays.
The display system evidently achieved the objective
of presenting a complex situation, which involved many
inter-relationships, in a manner such that the key
concepts and fundamental correlations were clearly
understandable. The display Rystem appeared to facilitate interpretation and extrapolation of the relevant
data. The reduction of reaction time of top-level
decision-makers in this environment is both an interesting result and an important objective of any executive
display system.
One point of great interest for further work would be
the exploration of the differential cost or savings of
decisions using display units and printer output. This is
a rather difficult area to define, since dollar values and
weightings must be assigned not only to the reduction
in inventory valuation and the cost of lost sales, but also
to the generated purchase actions, availability of
material, timeliness of decision, system cost and other
factors.
Statistics on the frequency of use of the various
displays should be collected, both automaticalJy and by
experimenter observation. The correlation of the frequency of use by display type with the individual's
consistency of decision would be most important for t.he
design of extensions of this system.
Whatever the extension of the experiment, there
should be the capability for the decider to request a hard
copy of any display he wishes. If line drawing capability
is used, this, of course, implies the availability of the
equivalent of a line plotter for hard copy output. This
requirement is more operational than experimental. We
have no doubt as to the utility of such a feature for the
decider in an operational environment, and if a display
unit has a line drawing capability, it should be used with
this requirement in mind.
SELECTED BIBLIOGRAPHY
Computer characteristics quarterly (second quarter)
Keydata and Adams Associates Inc Wat.prtown Massachusetts
1968
Decision Making with Computer Graphics
R G BROWN
Statistical forecasting for inventory control
McGraw-Hill Book Company New York 1959
D S BURDICK T H NAYLOR
Design of computer simulation experiments for industrial systems
Communications of the ACM 9 May 1966 pp 329-339
W G COCHRAN G M COX
Experimental designs
John Wiley & Sons, Inc New York 1962
W L HAYS
Statistics for psychologists
Holt, Rinehart and Winston New York 1963
IBM system/360 operating system graphic programming services
for IBM 2250 display unit
International Business Machines Corporation Form C27-6909-4
December 1967
IBM system/360 component description, IBM 2250 display unit
model 1
Form A27-2701-1 January 27 1967
H R LUXENBERG R L KUEHN eds
Display systems engineering
607
McGraw-Hill Book Company New York 1968
T H NAYLOR J L BALINTFY D S BURDICK
C KONG
Computer simulation techniques
John Wiley & Sons New York 1966
K WERTH T H WONNACOTT
Methods for analyzing data from computer simulation experiments
Communications of the ACM 10 pp 703-710 November 1967
G W PLOSSL 0 W WIGHT
Production and inventory control
Prentice-Hall Inc Englewood Cliffs NJ 1967
H SACKMAN W J ERIKSON E E GRANT
Exploratory experimental studies comparing online and offline
programming performance
Oommunications of the ACM 11 pp 3-11 January 1968
R G D STEEL J H TORRIE
Principles and procedures of statistics
McGraw-Hill Book Company New York 1960
B J WINER
Statistical principles in experimental design
McGraw-Hill Book Company New York 1962
Concurrent statistical evaluation
during patient monitoring*
by
s.
T. SACKS, N. A. PALLEY and H. SHUBIN
University of Southern California School of Medicine
Los Angeles, California
.
and
A. A. AFIFI
University of California
Los Angeles, California
BACKGROUND
Assessment of the circulatory and respiratory status
of such a critically ill patient requires measuring a
number of variables: arterial and venous pressure ;
blood flow and volume; electrocardiogram; blood gases
such as oxygen and carbon dioxide and blood constituents such as potassium. Repeated assessment of
these variables is required since the critically ill patient is not in a steady state, but may undergo rapid
and often unpredictable changes in status". 3 A number
of other patient monitoring facilities employing digital
computers are currently in operation across the country. Two such units engaged in the simultaneous
monitoring of multiple variables are at the Pacific
Medical Center4 in San Francisco and the Latter Day
Saints Hospital 5 in Salt Lake City.
At the k.~lock Research Unit, a combination of
sensors and transducers is used for measurement of
vital signs and additional parameters of clinical importance, and the data is processed to derive numerical
information helpful to the physician. Information
which is supplied directly by sensors applied to the
patient's body include eleven primary measurements
and twenty-five parameters which are recorded and
displayed with a frequency ranging from once a minute
to once every twenty-four hours. All numeric and
textual data are stored in an on-line patient file organized by type of data and by time. The data may
be retrieved by the user through a bedside K/D and
by current scheduled applications programs. Given this
large amount of sequential data, the physician must
have some means of combining it into a meaningful
evaluation of changes in the patient's status. 6 All
present commercially available patient monitoring
The Shock Research Unit, a specialized clinical research facility, has been developed by the University
of Southern California's School of Medicine for the
purpose of rendering intensive care to seriously ill
patients. Included is a medium-sized digital computer
with a real-time system which monitors the critically
ill patient. In addition, the system is being used to
study the underlying mechanisms of the disease process
and for developing new techniques of evaluating and
treating seriously ill patients.
The Shock Research Unit was started in 1962 and
since that time approximately 1,000 patients have
been treated at the unit. In mid-1963 a computer was
obtained and a system developed for monitoring
patients. 1 In 1968 the Shock Research Unit obtained
a third generation computer and applications programs
for a much-enlarged system of real-time monitoring
were written. 2
"The patient in circulatory shock is an example of
the need for immediate response to clinical observations. Low blood pressure and reduced blood flow are
characteristic of the patient in shock. He may become stuporous or comatose due to the inadequate
circulation to the brain. His kidney may cease to function and his respiration may fail.
* The research programs of the Shock Research Unit are supported by grants from the John A. Hartford Foundation, Inc.,
New York, and by the United States Public Health Service
research grants HE05570 and GM16462 from the National Heart
Institute and grant HS00238 from the National Center for
Health Services Research and Development.
609
610
Fall Joint Computer Conference, 1970
systems depend on alarm limits which are manually
set and may not be adaptable to the particular clinical
situation. These alarms are based on absolute values
of single variables and do not take into account relationships among variables. When these univariate
alarm systems sound too frequently, the usual response
of the person in charge is to set wider alarm limits.
Such actions have no statistical basis and may be
detrimental to patient care.
The availability of an on-line computer monitoring
system allows the examination of many variables simultaneously as well as the observation of their interrelationships. The purpose of this paper is to describe
the development and application of an automated
screening procedure for evaluating physiological data
obtained from continuous monitoring of critically ill
patients. Three criteria, motivated by clinical experience, are used in the evaluation of the patient's
data. The first is the absolute value of the monitored
variables. These values contain the information necessary to determine the current status of the patient
and to assure that the monitoring equipment is operating properly. The monitoring interval then may be
modified appropriately. However, in a dynamic system
the information of interest to the clinical staff is contained in the sequential changes in the measured
variables. These may reflect sudden, unexpected
changes in status or the expected responses to treatment and constitute the second criterion. Variations
are sometimes more meaningfully interpreted relative
to the absolute values of the variables. The third
criterion, therefore, is the proportionate change in the
monitored variables.
l\,:Iany of the variables which are routinely monitored
in a critically ill patient are highly correlated and the
clinical significance of a given measurement becomes
more apparent when examined in the context of the
remaining measurements. For example, Figure 1 illustrates a scatter diagram of a typical random sample
of simultaneously measured systolic (SP) and diastolic
(DP) pressures. The data tend to accumulate in an
elliptical region with the highest density near the center. While the vertical and horizontal dashed lines
determine the 95 percent confidence intervals for SP
and DP individually, the elliptical region includes the
same region for the pair of measurements. Point A
illustrates a measurement which lies within the individual normal limits but exceeds the bivariate limits ,
because low systolic pressure is combined with high
diastolic pressure. Thus normalcy is determined by
knowing both distance and direction from the mean.
The region inscribed by the ellipse may be expressed
by the inequality
SYSTOLIC
95%
LIMITS
O~~--------~-----------o
50
100
DIASTOLIC PRESSURE
mmHQ
Figure I-Scatter diagram of a set of values of systolic and
diastolic pressures indicating univariate and bivariate 95
percent confidence regions
where C is a constant and D2 is the l\1ahalanobis
distance for the two variables SP and DP.7 This Mahalanobis distance may be computed for any number
of variables. If Y is a vector of r observations, Y is the
mean vector, and S is the covariance matrix, then
D2= (Y - Y)'S
1
(Y - Y).
Because D2 incorporates interdependencies among
the vft,riables, unusual combint1tions of variables or
changes result in abnormally large D2 values, even
though the variables or changes when regarded individually may fall within normal limits.
U sing data sampled from patients previously monitored in the Shock Research Unit, these ideas provided the basis for a system to respond in real-time
to changes in patient status. The responses of the
system include:
1. Informing medical personnel of unusual changes
in the set of monitored variables.
2. Selecting data for display.
3. Selecting data for recording on a permanent
file.
4. Running of special analysis programs.
These responses will be discussed in detail below.
Development of method
Forty-one patients were chosen randomly from the
750 patients monitored in the SRU up to August, 1967.
Concurrent Statistical Evaluation
Only those patients who were observed for at least
four hours were included.
Seven variables were selected from the many which
are routinely monitored: systolic pressure (SP) , diastolic pressure (D P), mean arterial pressure (MAP) ,
mean venous pressure (MVP), rectal temperature
(RT) , heart rate (HR), and respiratory rate (RR).
Each patient's record was examined and that fourhour period which had the least missing data was
chosen. Measurements on sets of these variables were
recorded on each patient at five-minute intervals over
the selected four-hour period. Estimates for any missing data, which accounted for less than 5 percent of
the total data, were made by interpolating between
the nearest recorded values before and after the missing observation. From these absolute value sets the
following were calculated: .5-, 10-, 15-, 30-, and 60minute changes, proportionate .5-, 10-, 15-, 30-, and
60-minute changes.
Figure 2 illustrates the successive changes in a
single variable over time. It should be noted that this
choice of intervals was made in order to account for
both long-term and short-term variations. An example
of the calculation of 5-minute changes and proportional
changes in a set of variables is illustrated in Table I.
The value of the IVIahalanobis D2 was calculated using
the appropriate sample mean vector and covariance
matrix for each vector of absolute values, x-minute
changes and proportionate x-minute changes (x = .5,
10, 15, 30, 60). In the remainder of this paper frequent
reference will be made to these eleven types of measurements, namely, absolute values, the five x-minute
changes, and the five x-minute proportionate changes.
TIME COMPARISONS
W
...J
m
«
0::
~
r'"
-60
"""~So
MINUTES
..........~
o
611
TABLE I-An Example of 5 Minute Changes and Proportional
Changes in the 7 Variables Set
Variable
Name
SP
DP
MAP
MVP
RT
HR
RR
D2
Region
Value at
Time
Value at
Time
t
t-5
122
80
94
1
37.7
98
21
122
87
98
1
37.8
100
22
12.9
B
8.5
A
5-minute
5-minute
change at
proportional
Time t change at Time t
0
-7
-4
0
~0.1
-2
-1
11.8
B
O.
= 0/122
-0.088 = -7/80 .
-0.043 = -4/94
O.
= 0/1
o .003 = 0 . 1/37 . 7
-0.020= -2/98
-0.048 = -1/21
43.1
C
This procedure yielded eleven distributions of D2.
Percentiles necessary for setting monitoring limits
were then calculated for each of these D2 distributions.
In monitoring a critically ill patient, it is inevitable
that, on occasion, values for one or more variables
are missing. This may occur if a measurement is taken
while a catheter is being flushed or if the EKG leads
are accidentally disconnected or simply because monitoring of all variables is not started simultaneously.
A preliminary screening procedure will exclude such
invalid measurements. Consequently, tables of D2 for
incomplete vectors of observations are necessary. It
is possible to empirically derive and store the 1309
tables of D2 percentiles necessary to handle all combinations of missing variables. Hmvever, in order to
minimize storage requirements and allow the system
to operate in real-time, ail alternative procedure was
developed as follmvs.
If the population mean vector and covariance matrix
were used in computing D2, and if the observation
vector were normally distributed, the distribution of
D2 would be that of a Chi-square variable. Since the
variables under consideration are not exactly normally
distributed and sample estimates were used instead
of population parameters, the empirical distribution
ofD2 deviates from that of Chi-square. However, they
do remain similar in shape. Thus it was hypothesized
that the ratio of a percentile of the Chi-square distribution to the corresponding empirical percentile of
D2 for a given type of measurement is independent
of the number of components in the vector of measurements. That is, for absolute values, x-minute changes
and proportionate x-minute changes, we assume that:
VIIC,IIIUII1' ••
AL.A ••
Figure 2-X-minute changes in a given variable for
x = 5, 10, 15, 30 and 60
pth percentile of D2 distribution based on l' components
pth percentile of Chi-square distribution with r d. f.
612
Fall Joint Computer Conference, 1970
System algorithm
The basic algorithm for this system comprises the
following steps:
80th
95th
99th
PERCENTIL'ES OF 0 2
Figure 3-Monitoring regions with alarm limits based on the
empirical distribution of D2
pth percentile of D2 distribution based on 7 components
pth percentile of Chi-square distribution with 7 d. f.
for r= 2, ... ,6.
From this assumption, approximate empirical percentiles for the'D2 distribution based on any number
of components were generated from the D2 distribution
percentiles based on seven components.
Each D2 distribution is divided into regions designating the degree of normalcy of a set of measurements as shown in Figure 3. These limits are based
on the empirical distributions of each set of values in
the base sample. In the figure the limits are taken as
the 80th, 9.5th, and 99th percentiles. Region A may be
classified as the normal region, containing values
which are expected to occur 80 percent of the time.
Region B, the moderately abnormal region, contains the values expected to occur between the next
20 percent to 5 percent of the time. Region C, the
abnormal region, includes the 95th to 99th percentiles, and Region D may be interpreted as the
highly abnormal region since it contains the extreme
values which would be expected to occur only one
percent of the time. Sets of three limits are computed
for 0, 1, ...', 6 missing variables. The total number of
tables to be stored is thus reduced from 1309 to 77,
and with 3 limits per table, only 231 values are stored
(11 change vectors X 3 region limits X 7 possible
numbers of missing values). In addition eleven 7 X 7
covariance matrices based on the sample data are
stored.
Note that the original choice of the three percentile
limits is arbitrary and may be modified as experience
is gained with the system.
1. Each five minutes, the most recent set of observations is retrieved from the patient file.
2. The patient file is searched sequentially for the
measurements taken 5, 10, 15, 30 and 60 minutes
previously and also for alarm information recorded at those times. For those variables having
a valid present and past value, changes and
proportionate changes are computed. The appropriate stored covariance matrix, or a reduced
matrix corresponding to the variables present
in each change vector, is then used to calculate
D2. In some cases all components necessary for
computing D2 may be missing.
3. For each of the computed D2 values, the appropriate set of three region limits is retrieved
from the tabled values on the disc file. The index
of the set of limits to be retrieved is determined
by the change vector being considered (1, ... ,
11) and its dimension (1, ... , 7).
4. Using the region limits, a cateogry is assigned
to each of the available D2 values.
5. The identity of the most extreme D2 and the
category to which it is assigned are stored in
the patient file.
6. Appropriate system action is taken as described
below.
Uses of the system
The action taken by the patient monitoring system
in response to the computed D2 depends upon the
most extreme category detected. Any D2 value falling
in the B, C or D regions will result in a signal to the
ward staff. The signal is coded to indicate the degree
of abnormality. A red and a yellow signal light and a
chime, under computer control, are mounted near the
status display. The chime signals a D2 value detected
in any of the three regions. In addition, the red light
accompanies region D while the yellow light accompanies region C.
Some measurements such as heart rate and respiration rate, are usually read from the output of preprocessors which derive the information from the raw
data. When an alarm occurs, the digital analysis program reads the original wave-form signal directly to
verify the abnormal value encountered. The EKG
analysis program, which may be run on demand, is
also triggered in response to an alarm.
Concurrent Statistical Evaluation
In many cases, the cause of the alarm is immediately
obvious by noting the values on the status display,
as shown in Figure 4. If the physician wishes to know
in detail the values causing an alarm, he may cal1 a
program on the keyboard display which reports the
current and previous values of the variables used in
computing D2. As illustrated in Figure 5, this program
indicates the time over which the extreme changes
have taken place and the magnitude of the changes.
The physician may then indicate the probable cause
of the alarm. The cause may be a change in the normal
course of the patient's progress or a specific treatment
such as medication, fluid infusion, or adjustments
made to the respirator. Changes from such causes, although resulting in an alarm, do not necessarily reflect
emergent situations. In addition, the alarm may have
been caused by an artifact in one of the monitored
variables. This may occur if a catheter becomes clogged
or is inadvertently flushed while the signal is being
read or if EKG leads become dislodged. This information is stored in the patient file and at the same
time the signal light is turned off.
Summaries of alarm information are stored in the
patient file. These summaries contain the following
information: the time of the alarm, its category and
the specific change or proportionate change causing
the alarm. In addition, if the ward staff responded
to the alarm through the keyboard display, the summary will contain the time of the response and may
thus contain a flag indicating that the cause of the
alarm was an artifact and the particular variable or
19.····0517
STATUS
BED 1
BED 2
64/37
45
6
84/ 3
17.
96.····5:3
F.~ECT .····At·1El
34.6.····25.4
24.8.····24.3
6.····39
37.1.····25.4
24.9.····25.3
0 ..... 2::::
DA\' /'T I t'lE
19....·0201
1.9
14/28
1347
19.····0317
1 .=,
11.····25
2227
29.····0210
7.31.····51
71...-'96
19.····0329
7.49 ..... 24
27:::: ..... 100
5:::: ..... 0224
22.····0224
3.4.····0217
29.····0346
19..... 0346
2.9.····0338
S ....·S ..... DIA
t'1AP
'.}EN
HF.:.···PDEF
F.:E!::;P
TOE L..... F.~
UP5.····UR60
[:1
AT.···ll[:T
RESIST
HCT ....·T1t·1E
PH.····PC02
P02.····SAT
pl.} .····T I t'lE
F.~Ct·1.····T I t'lE
LAC/Tlt'lE
72
8
98.···· 0
22
•
I_I
Figure 4-Bedside status display showing values of the monitored
variables for two patients
.~ •• M
613
S"MMAIY lED 1
"Cu\-. AllH"1 I.
•• \18
1234
11M' Q' ALAIM: 04/0105
IE'IDM· C .LESS TNAM 5 'EICEMTJ
SQuat, Q' AUIM: 5 IIINUTE CHAM'E •
liME
\
SP
:
::,
4
S
I
MW'
IT
HI
7
I.
0100
0105
122
.0
'4
122
.,
I
U •,
S.
22
DELTA 5
sa
I
3' .t
100
21
0
7
4
0
0I
.1 •
CAUSE OF ALA •• : 0. U.. MO ••• I. TIEATIIENT. 2' AITI'AC1 ? 2
VAIIAILE ? 2 'DP,
01
11
il
31
41
UNKND_N OIJGJ.
CATHETEI DAMPED 01 DISCD••rCTED
'LUSHJNG
AIt'LJ'JUS
OTHEI ELECTtONJCS
CODE ? Z
Figure 5-Keyboard/CRT display alarm summary showing
that the set of 5-minute changes falls in monitoring region C.
The attending physician indicated that the value for variable 2
was an artifact caused by flushing
variables involved. If the information was supplied
by the physician, the clinical event related to the
alarm condition is also coded.
The alarm summaries are utilized by the patient
monitoring system in a variety of ways. As indicated
in Step 2 of the system algorithm, the patient file is
searched so that changes may be computed. Summaries of alarms stored at the same time as any of
the five previous sets of values are also retrieved. If
the summary indicates that any value in the set used
for calculating the D2 was the result of an artifact,
that value is deleted from computation. This prevents
a single artifact from causing several alarms as that set
of values is successively retrieved 5, 10, 15, 30 and
60 minutes later.
During the patient's stay, the physician often reviews sets of data on the bedside keyboard display.
Since on any display frame only six sets of simultaneous
measurements may be viewed, as shown in Figure 6,
it is desirable to eliminate redundant observations .
This may be achieved by displaying only those sets
of data falling in abnormal regions. In the same way
the permanent hardcopy record, which is printed upon
patient discharge, can be specified to contain only
significant information. Under conditions of intensive
monitoring where measurements are made every minute, this may represent a valuable reduction in the
bulk of the hardcopy record to be reviewed. Those
sets of variables containing values previously identified
as artifacts may be deleted from both the keyboard
614
Fall Joint Computer Conference, 1970
MEMaDYNAIUC DATA SUIIIIAIIY lED
3
~nnNT NAIIE- 'ICIll, UTHUR
"OSPlTAl NUMBU_ 111171
.au NUM'U - 1G4a
DAVitt""
.. was
aN MUD
svs
M"HG
Oil
""HG
""HG
""HG
MAP
VEitt
Hit
Pit
ItESP
11
DD,HH""
'''IN
'''IN
'''IN
FIItST, 9) LATEST
ENTEit
caDE
10'2343
10/23.1 10/2353 10/2351
1110003
15,0
54,0
70,0
1,0
n,a
54,0
70.0
1,0
n,a
54,0
70.0
1,0
14,0
54,0
n.o
1,0
!l4,a
54,0
n.a
7,0
azo,o
111,0
11,0
120,0
111,0
1$,0
117,1
111,0
17,a
120,0
111,0
lI,a
120,0 .
111,0
17,0
1110007
91.0
n.a
',a
ua.a
51.a
111,0
15,0
4) 'REVIOUS, II '''LillIS,. DAY/TIIiE
come part of the patient's file and are accessible to
applications programs involved in data display. The
stored summary of the alarm information assists the
clinical staff in case review, and provides a basis for
evaluating and modifying the alarm system itself.
Such modifications might include the redefinition of
the percentiles which define the alarm categories or
even the number of such categories. Extensions of
this alarm system might enable a small centrally located digital processor to evaluate sets of data from a
number of analog monitoring modules at various bedsides.
Figure 6-Hemodynamic data summary showing six sets of
values of seven variables
ACKNOWLEDG1VIENT
display presentation and the hardcopy output. This
procedure is also used with the storage oscilloscope
at the bedside which displays a trend plot of monitored
variables. By referring to the alarm summaries the
program which produced this display deletes invalid
data points from the plot.
In order to have the patient file accessible in case
of system failure, teletypes, remote to the ward, produce hardcopy output containing the latest measurements. While the status display is automatically updated every 30 seconds, the teletype, because of its
low speed, cannot be updated at the same rate. In
order to make efficient use of the teletypes and fulfill
their function of preserving data of interest, the teletype records are updated every half-hour or whenever
abnormal values are encountered.
SU:;\Il\IARY
The alarm system described in this paper both depends
on and augments the capabilities of the digitally controlled patient monitoring system. It utilizes multivariate techniques to compute statistics which are
sensitive to relationships among the monitored variables. The degree of abnormality of a computed statistic is evaluated in terms of empirical distributions.
These distributions were derived from a population
of critically ill patients similar to that being presently
monitored by the system. The actions taken by the
patient monitoring system in response to the alarm
depend on the severity indicated by the alarm. The
occurrence of the alarm and the cause, if known, be-
The authors would like to express their gratitude to
Doctor l\1ax Harry Weil, Director of the Shock Research Unit, whose able guidance and support made
this work possible. We would also like to thank Doctor
William Rand who, during his employment at the
Shock Research Unit, contributed greatly to the collection of the data in the preliminary discussions leading
to the formulation of the system. Our thanks also go
to l\1iss Cecilia Pasos for typing the manuscript.
REFERENCES
1 M A ROCKWELL H SHUBIN M H WElL
Shock III: A computer system as an aid in the management
oj critically ill patients
Communications of the ACM Vol 9 No 5 May 1966
2 D H STEWART D E ERBECK H SHUBIN
A computer system jor real-time monitoring and management
oj the critically ill
AFIPS-Conference Proceedings Vol 33 December 1968
3 IBID
4 J J OSBORN J 0 BEAUMONT J C RAISON
J RUSSELL F GERBODE
Measurement and monitorjng oj acutely ill patients by digital
computer
Surgery Vol 64 pp 1057-1070 December 1968
5 T A PRYOR H R WARNER
Time-sharing in biomedical research
Datamation Vol 12 pp 54-63 April 1966
6 A A AFIFI W RAND H SHUBIN M H WElL
A method jor evaluating changes in sets oj computer monitored
physiological variables
Submitted for publication
7 T W ANDERSON
Introduction to multivariate statistical analysis
John Wiley and Sons New York 1958
Associative capabilities for mass storage
through array organization*
by ARNOLD IVLPESKIN
Brookhaven National Laboratory
Upton, Long Island, N ew York
larger storage array. If the small block possesses the
associative property but the large array does not a
method of ,data base organization and array interconnection is possible so that the larger array begins to
exhibit all the properties of the smaller one including
reference speed and content addressability. A geometric
interpretation of this approach is depicted in Figure 1.
A cubic storage array is shown, only one plane of
which has associative capability; this is the z = 0 plane.
A match resulting from an association in this plane will
define another plane, perpendicular to the first. Assuming that the memory reference requires that a
second association be made on the data in this newly
selected plane also, its contents may be loaded into the
plane with the content addressable capabilities, wh.ile
the original contents of that plane are temporarIly
stored in the buffer of Figure 1. The association may
then be completed and the array restored. For purposes
of this discussion, it is assumed that the loading and
unloading capability is implemented by adding to each
bit the necessary hardware to make it a unidirectional
fast shift register.
It is then possible to select or "find" any given word
in the cube in the time required to perform two associative references and the requisite loading and restoring
of the z=O plane. What this scheme accomplishes can
be demonstrated by examining its cost-performance
characteristics. Symbols will be defined in the following
manner:
THE ASSOCIATIVE MEMORY PROBLEM
Since computers first came into wide usage, digital
systems designers have been intrigued by the possibilities of associative or content addressable memories.
The concept is quite easy to understand; whereas, in
the conventional case, the address is furnished to the
memory and the data stored at that location is the expected result, in the associative reference, the data is
furnished and the expected result is a list of all addresses
which contain matching data. Up to now, however, the
ph~sical systems which exhibit the requisite symmetry
to realize this concept have been necessarily very costly
because the commonly used, low cost, random access
memories do not easily lend themselves to this new
operation. Those digital systems designers who predicted widespread use of associative memories by the
late 1960's are found in retrospect to have seriously
underestimated the difficulty in implementing thin
magnetic film or superconducting memory systems,
on which these forecasts heavily depended.l,2,S
Logic designers and programmers have each been
called upon to simulate the associative memory for
specific applications, but implementation in logic has
incurred an almost prohibitive cost-per-bit and software search subroutines expend equally unattractive
lengths of time. 4 The advent of large scale integration
and the rapidly decreasing cycle times of new computers
promise to make either recourse somewhat more attractive but at this time associative capability is still
unthinkable for anything but a small block of
information.
w = word length: number of bits per dimension
Ca = associative portion of cost per bit
Cc = conventional portion of cost per bit
A CONTENT ADDRESSABLE N-CUBE
ta = time duration of a t'wo-dimensional associative
One approach to this problem is to expand the associative capability from a small block of data to a
reference
ts = time required to shift a bit "w" places.
* Work performed under the auspices of the U.S. Atomic Energy
Commision.
For use in approximation, the follo'wing relationships
615
616
Fall Joint Computer Conference, 1970
cause as each new dimension is added:
'I
1. the associative
capability increases exponentiallv:
2. the conventional portioI,l of cost only follows
exponentially;
3. the associative portion of the cost does not
increase;
4. the duration of a reference increases linearly.
_.............. PLANE
/'ALSS~Xlj~T IVE
PLANE
~~------------x
Summarizing for an n-cube:
N umber of associative elements = w n
Total cost = (w n + 10w2 ) Cc
Duration = (n-l)t a+2(n-2)ts
Z
=ta[(n-l) +w(n-2)/lO].
Figure I-A content addressable 3-cube
are assumed to exist
ta = (20/w) ts.
These relationships state that the content-addressable
and shift portion of the cost is ten times the cost of a
conventional memory of the same size, and that the
time required to do a memory reference in an IC memory system is twenty times that of a one bit shift in
logic of the same family. These constants vary with
the technology and mode of implementation used, of
course, but experience indicates that these are reasonable assumptions. 4 What is most important, nevertheless, is that these relationships are expressable by constants, and not what the specific values of these constants are.
In two dimensions, then,
These relationships are summarized in Figure 2.
Whether or not the n-cube is a practical design approach is a difficult question to answer in view of the
current flux in integrated circ.uit technology. IC's are
becoming available which provide the associative, but
not the shift capability. Providing a bussing structure
10.000
1.000
,........,
Cf)
total cost = (Ca +Cc )w2
=
11w2Cc•
With the three-dimensional scheme of Figure 1, there
are now w 3 bits, each of which may be thought of to
have associative capability, but only one out of every
w bits incurs the associative portion of the cost. This is
accomplished at the expense of a reduction in the total
speed of reference. Specifically,
~
)(
'--'
(I)
I-
iii
..,
100
>
i=
c
U
0
(I)
(I)
C
IJ.
0
..,
III:
ID
2
:I
Z
10
total cost = w Cc + w Ca
3
2
= (w 3 +10w2 )Cc
COST PERFORMANCE CHARACTERISTIC:
DIMENSION v S. SIZE OF ASSOCIATIVE FIELD.
+
duration = 2ta 2ts
=ta [2+ (w/lO)}
There is no reason to stop at three dimensions, be-
o
2
DIMENSION
4
OF
N - CI,./BE
Associative Capabilities
so that the information of each plane can find its way
to the z = 0 or associative plane may add considerable
overhead to the system. Also, the question of how to
handle multiple matches in an early plane reference
can only be addressed to the specific application for
which the n-cube is being used. However, one can attempt to take advantage of the exponential capability
increase vs. linear time duration increase with a twodimensional associative array interfaced to a properly
partitioned conventional random access storage bank.
dimensional content addressable memory, which interfaces to the mass storage controller through its own
transfer coupler, which in turn is controlled programmatically through the I/O interface of the computer.
The two-dimensional content addressable memory
(2DCAM) consists of sixty-four 64-bit words which
maybe accessed either conventionally by address or
A PRACTICAL FOUR-DIMENSIONAL
APPROACH
Figure 3 shows a computer configuration featuring a
large random access bank of core storage which can be
referenced by one or more central processors through
the mass storage controller. This configuration is
typical of many large computer installations. Also
connected to the mass storage unit is a small two-
COST PERFORMANCE CHARACTERISTIC:
DIMENSION vs. RELATIVE REFERENCE TIME
,....,
100
~
6
I
""~
~
I&!
~
i
10
I
1,000
o
2
2
4
DIMENSION Of N - CUBE
100
ACCESS TIME COMPARISON fOR LINEAR ANO N- CUBIC fILE SCANS.
1.000
100
:..-...s LINEAR SCAN
10
10
11-----------~~------~--~------0 2 4
DIMENSION
OF
617
100
NUMBER OF ASSOCIATIVE BITS
1.000
10.000
[x 1O~
N - CUBE
Figure 2-Cost-performance characteristics of a
content-addressable N-cube for w = 64 bits per word
618
Fall Joint Computer Conference, 1970
MASS STORAGE
------- -
~
COMPUTER
VIRTUAL
CAM
DIMENSION
4
As is shown in the graph of Figure 2d, this method
compares quite favorably to the time required to scan
256,000 64-bit words programmatically, especially
when it is realized that while the association takes place,
the central processor is free to perform other tasks.
Compared to the most advanced techniques of binary
searching, the n-cube associative search over this data
base can be performed approximately five times faster.
THE BROOKHAVEN CONFIGURATION
Figure 3-Proposed 4D configuration
by content; that is, exhibiting the associative property.
The field of association can be specified under program
control by loading a mask register, thus increasing the
2DCAM's versatility. This device may be built around
integrated circuit content addressable memory modules,
such as are becoming available in various logic families
from several different manufacturers. I t is also important to implement a burst load/unload capability
for the entire 2DCAM, analogous to the perpendicular
shift capability in the n-cube configuration. In the TTL
or ECL logic family, storage cycle times of less than 100
nanoseconds are now commonplace.
The portion of the mass storage which is dedicated
to the 2DCAM will for many applications, virtually
exhibit the associative property itself. If the mass
storage is partitioned as suggested in Figure 3, there
will be four dimensions of associativity, each 64 bits
long, or over 256 kilo-64-bit words capable of exhibiting
the associative property in little more than the time
required to load the 2DCAM twice. There will be one
64 word block which can be thought of as the interfile
index. It is the block in which the first association takes
place and is thus analogous to the z = 0 plane of the ncube. A match resulting from an association in this
table will determine which one of sixty-four sectors of
conventional storage contains the information that is
ultimately sought. An index for that sector ifS then
loaded into the 2DCAM and a subsequent afSfSoeiation
is performed, this time to determine which 64 word block
will be required for the final associative reference.
Thus a partially ordered data field of 16 million bits
has been scanned in the time required to load the
2DCAM twice and perform a content addressable
reference three times, which together would total an
elapsed time of less than twenty rni(T()s(~t(Hlds.
In the Central Scientific Computing Facility of
Brookhaven National Laboratory, the computer of
Figure 3 is one of Brookhaven's Control Data 6600
processors. The mass storage system is a one-million
word Extended Core Storage (ECS) , also a Control
Data product. The ECS controller, designated the 6640,
can service up to four 6000 series computers with a
maximum throughput rate of 600 million bits per
second. 5
The transfer coupler of Figure 3 is represented in the
Brookhaven configuration primarily by a branch of the
Laboratory's remote computer network, known as
Brooknet, as shown in Figure 4. Brooknet can provide
on-line service to eight remote areas, any of which can
be up to 5,500 feet away from the central facility. Each
remote area, in turn, may have eight or less remote
computers on-line within a radius of 1000 feet from a
remote Brooknet multiplexer. As shown in Figure 4,
Brooknet provides selectable data paths for the remote
from either the computer I/O interface or the ECS
controller, to which Brooknet logically appears as a
third 6600. The I/O interface is utilized for status and
fixed format control messages and the ECS path is
used for block data transfer of files. Because it can
provide a high speed interface between a special pur-
}
Figure 4-Brooknet
FREE
I MHZ
SUB-CHANNELS
Associative Capabilities
pose device (such as the 2DCAM) and ECS, a Brooknet link meets all the requirements for a transfer
p'oupler. That is, ECS would suffice as the large conventional storage, the 2DCAM would reside at the
remote system, and the requisite swapping of the 64
word blocks of information are performed as normal
Brooknet data transfers just as if they were input or
output files from a remote batch station. For this
system, in order to maintain compatibility with the
Control Data equipment, the word size must be sixty,
rather than sixty-four bits long. 6
The two-dimensional content addressable memory
(2DCAM) designed for Brooknet has the block diagram of Figure 5. This device consists of sixty-four 60bit words, expandable to 256 60-bit words, which can
perform associative or conventional meinory references. There are six functions defined for it:
1.
2.
3.
4.
5.
6.
Load mask register;
Write (conventional);
Read (conventional) ;
Associate and count matches;
Associate and present addresses;
M ultiload.
The multiload function implements the burst loading
feature required to perform successive associations
efficiently. The entire memory can be loaded in 6.3
microseconds.
To render the 2DCAM hardware and software compatible with Brooknet, a modest control computer is
required to engage in the Brooknet dialogues, and two
more pieces of interface equipment are needed for level
conversion and logic translation. A 2DCAM system
8 ADDRESS
IN LINES
t - - - - ASSOC.
t - - - - MULTIPLE
OUT OF RANGE
8 ADDRESS
OUT LINE
GO DATA-IN
a
GO DATA-'OUT LINES
Figure S-Content addressable memory block diagram
619
I
I
BROOKNET:
EQUIPMENTI
REMOTE
SYSTEM
TO [MOn: REMOTE
CONTROL
•
COMPUTER
FACllITYL~APTER
COMPUTER
CONTROLl£R
/'
I
SMALL COMPUTER
STORAGE BUSS
20 CAM
CONTROLLER
I
I
I
Figure 6-Remote system for 2 D CAM
which is attachable to Brooknet appears in Figure 6.
This configuration represents a departure from the
initial intent of the Brooknet system, which was to
extend the considerable resources of the 6600 computer
to smaller remote processors for controlled periods of
time. In this case, however, it is the remote which
possesses the desired capability of which the central
processors would like to avail themselves.
APPLICATIONS
The multidimensional approach presented can be
adapted to many large computer installations provided
that a mass core storage device is included. The Brookhaven configuration was offered as an example which
utilizes facilities which were already available at that
particular computing center. This scheme for providing
content addressable capability has applications whereever a conventional two-dimensional configuration was
previously considered, provided that the decrease in
speed incurred is not a severe restriction. 7
By partitioning the associative field of the memory
word into sections one can structure his data array so
that multiple associations· are required, and thus take
advantage of the multi-dimensional approach. For instance, if a word has an eighteen bit associative field, it
can be partitioned into three 6-bit operands. A match
in the first plane will define a new plane wherein the
associative field of all words have the same first operand as produced the match. Now it is no longer necessary to scrutinize the first operand so the match operation is performed on the second operand and so on
until the unique word is found. Implementation of such
a procedure presupposes a certain order of structuring
when the data block was first introduced to the virtual
CAM area. Self sorting may be accomplished by using
part of the data word as the address and preserving
620
Fall Joint Computer Conference, 1970
the old address as a sequence number when first storing
the data into the mass memory. Applications in pattern
recognition, storage paging, and table look-up routines
lend themselves to such structuring quite readily, and,
if the application is such that the associative file must
be loaded once and then referenced many ~imes, the
presorting requirement does not introduce an objectionable amount of overhead at all. 8 Indeed, in the Illiac 3
pattern recognition processor, the Iterative Array and
Transfer Memory taken together achieved the n-cube
effect in three dimensions. 9
The multidimensional approach appears particularly
attractive to those applications which can be thought
of as requiring a hierarchy of associations, such as
finding a record in a complex paging scheme (i.e., a file
within a page, a sector within a file, and a record within
a sector) , or where the file itself is multidimensional in
structure, such as for graphic or mechanical information
where f(x, y, z) varies with time. In addition, new
applications might open up where the amount of source
information is so large that up to now consideration of
a truly associative system would have been prohibitively expensive. 4 ,lO
CONCLUSION
Despite some restrictions on its class of applications,
the cost performance characteristics of this approach
have been considered attractive enough to warrant
implementation, especially in large multiprocessing
systems where the structure of system tables and the
traffic in file accessing represents a considerable portion
of the processing time. The implications of large scale
integration and emergence of more and more complex
modules suggest that other capabilities besides content
addressability may benefit from a similar appruach to
effective utilization.
This system is currently being implemented at
Brookhaven National Laboratory.
ACKNOWLEDGMENTS
The author wishes to thank Dr. Y. Shimamoto of
Brookhaven National Laboratory and Dr. J. Robertson
of the University of Illinois for their .suggestions and
encouragement.
This system is currently being implemented by Niels
Schumburg and Bernard Garfinkel of the Applied
Mathematics Department engineering group at Brookhaven National Laboratory.
REFERENCES
1 W F CHOW
Plated wire content-addressable memories with bit-steering
technique
IEEE Transactions on Electronic Computers Vol EC-16
No 5 October 1967
2 P M DAVIES
A simplified superconductive associative memory
Proceedings SJCC May 1962
3 W L McDERMID H E PETERSEN
A magnetic associative memory system
IBM Journal of Research and Development January 1961
4 ASPINALL KINNITMENT EDWARDS
An integrated associative memory matrix
IFIP Congress August 1968
5 6400/6500/6600 Extended core storage system reference
manual
Control Data Corporation Publication No 60225100 1968
6 K R FANNIN
Brookhaven digital communications network
AEC Computer Information Meeting Rice University
Houston Texas April 7 1967
7 DUGAN GREEN MINKEN SHINDLE
A study of the utility of associative memory processors
Proceedings-ACM National Meeting 1966
8 R R SEEBER A B LINDQUIST
Associative memory with ordered retrieval
IBM Journal of Research and Development January 1962
9 B H McCORMICK
The Illinois pattern recognition computer-Illiac III
IEEE Transactions on Electronic Computers Vol EC-12
No 5 December 1963
10 ASPINALL KINNITMENT EDWARDS
Associative memories in large computer systems
IFIP Congress August 1968
Interrupt processing with queued
content-addressable memories
by JERRY D. ERWIN and E. DOUGLAS JENSEN
Southern Methodist University
Dallas, Texas
INTRODUCTION
only in the hardware restrictions on the number of
interrupt lines, but also in the software's inability to
effectively deal with the interrupts it does get., It is
apparent, .then, that in such cases a brute force extension of current interrupt concepts is inadequate.
Instead, a new approach needs to be formulated which
provides improved performance from both hardware
and software.
It is well recognized that on-line computers generally
cannot afford the inefficiencies inherent in scanned or
multiplexed interrupt structures; a multi-level hierarchical system is preferable for such applications. 2
Frequently the on-line interrupts do not all have
distinct priorities, so they can be separated into priority
classes. Each class can then be assigned to some priority level which is shared by all interrupts of that
class. Unfortunately, most machines do not possess
an efficient means of identifying different interrupt
sources within a priority level, and so the user must
either degrade his system performance or undergo
the expense of additional priority level hardware.
The assignment of priority levels to particular functions can be a complex task since the interrupt requests
must be ordered on the basis of their interaction, not
merely on their relative importance. 2 However, it is
difficult to accurately forecast the exact nature of these
interactions in advance, especially since the context
tends to vary widely during system operation. The
resulting assignment compromises can be avoided
by supplying the freedom to dynamically reallocate
priority levels, a powerful tool which enables the executive software to accurately establish the computer's
response to changes in its environment. This capability is currently approached through some combination of arm/disarm commands, program-generated
interrupts, multiple level assignments, and hardware
switching matrices.
One of the disabilities of conventional priority
One of the most significant problems in designing high
performance computing systems is the complexity
of the associated supervisory software. This is especially true in multi-user environments: the software
·overhead involved in user communications and resource allocation normally absorbs a great percentage
of the system's computing power.
An often-proposed solution to this problem is to
remove some of the time-consuming executive functions from the software and perform them in hardware.
Numerous examples of this operation are visible
throughout the history of computer development. 1
These attempts have met with varying degrees of success because as the tasks to be transplanted become
more and more comprehensive, it becomes less and
less obvious exactly what sort of hardware structures
are needed for their efficient implementation.
One of the most vital ingredients in an on-line computer is a powerful and flexible priority interrupt
system. l\10re than any other single feature, the interrupt structure determines the capability of the machine
to respond quickly to both internal and external
stimuli. Whether the computer is used for control
or data processing, its effectiveness is frequently measured by how rapidly it is able to react to conditions in
the user environment.
A fundamental characteristic of an interrupt system
is how many interrupting sources it can handle. Few
of today's computers are designed to accommodate
interrupts from a large number (say hundreds) of
devices, despite the growing requirements for such
facilities. It is increasingly common to find cases where
a machine's processing power is sufficient to satisfy
a great many concurrent demands, but its interrupt
system is incapable of supporting the corresponding
volume of service requests. This limitation lies not
621
622
Fall Joint Computer Conference, 1970
assures optimum priority response, and reduces supervisory software overhead leaving more processing
power for the users.
The IP is organized around a special unit called a
queued content-addressable memory, which forms its
primary storage and processing facility.
THE QUEUED CONTENT-ADDRESSABLE
l\1EMORY
Figure I-Queued CAM
interrupt schemes is that if an interrupt at some level
is waiting, or is being serviced, or is suspended due to
higher priority requests, subsequent interrrupts at
that same level will be ignored. It is obviously necessary for a system to be designed so that the time required to respond to an interrupt is less than the
average time between occurrences of that interrupt.
But it is also highly desirable that the system not
become saturated by occasional bursts of interrupts
at any level. This tolerance to interrupt asynchronism
greatly eases the problem of compatible priority assignments, and lessens the risk of disrupted communications between the machine and its environment.
These considerations have all been successfully
addressed in the design of a special purpose Interrupt
Processor (IP). The IP functions as an autonomous
element of medium to large scale on-line multiprocessing
systems, and facilitates the computer's interaction
with users, peripherals, and control interfaces. All
of the functions associated with detecting, acknowledging, and scheduling interrupts have been incorporated into the IP hardware, providing centralized
routing of interrupts to all other processors. The
remainder of the task assignment mechanism may be
software in the destination processor3 ,4 or a hardware
extension of the IP ..'i
The IP monitors a large number of interrupt lines
on which signals are automatically identified by source
within software-defined priority levels. When interrupts are received they are organized and stored on
the basis of priority and order of occurrence. This
The concept of a queue is a familiar one to hardware
and software designers alike. As modeled in software,
queues are usually variable length, each new word
being added directly behind the last one. Hardware
queues, on the other hand, are fixed length as exemplified by a special shift register in which every new
entry is inserted at one end from where it moves up
to the forward-most empty position.
Content-addressable memories (CAM's) are also
well-known, but not so widely found, due to technological limitations which are now being overcome.
Queues and CAl\1's are not necessarily disjoint
structures, but can be combined into one entity having
both kinds of characteristics. As shown in Figure .1,
this results in a wordwise 2-dimensional memory consisting of a CAM with a queue behind every word. To
enter a new item into the memory, the fronts of the
queues (i.e., the CAM words) are associatively searched
for a current entry having a key that matches that of
the new item. If there is none, the new word is placed
directly in a vacant CAl\1 slot. If a word with a matching key is found in the front of some queue, the new
item is entered into the rear of that queue and allowed
to ripple forward. To read from the memory, the CAM
is interrogated for a word with the desired key. If
one is present, it appears on the output lines. If an
entry is removed,the remaining words in the corresponding queue all move forward one position, filling
the vacated CAl\1 position.
INTERRUPT PROCESSOR ORGANIZATION
For purposes of discussion, it is assumed that the
IP is part of a 32-bit computer, and that it interfaces
with both the Central Processor (CP) and the main
memory. Only one CP is mentioned, but the IP is
readily adapted to multiple CP's in the fashion described in References 3 and 4, or 5.
The basic Ip· configuration shown here provides for
64 levels of priority with 16 hardware-identified sources
per level, for a total of 1024 interrupts. This may be
Interrupt Processing
expanded in increments of 64 levels to a maximum of
256 levels and 4096 interrupt sources.
A block diagram of the IP is illustrated in Figure 2.
The major components are a priority structure, a
random access scratchpad, and a queued CA1\1.
623
QUEUED
CAM
PRIORITY
LOGIC
Priority logic
A fully nested priority tree monitors the 64 to 256
interrupt lines. This tree determines the order in which
interrupts are accepted and stored for pror.essing, as
contrasted with the program-controlled priority in
which the stored interrupts are serviced by the CPo
The priority logic incorporates a holding register
that frees the device from having to maintain the
interrupt signal. Also included is an arm register with
a bit for each line which may be set and reset both
unitarily and in groups.
The highest priority line which is armed and active
is encoded by the tree into an 8-bit binary number.
This number is transferred to the Scratchpad Address
Register (SAR) , and the corresponding 4-bit source
identification code is stored in part of the queued CAlVI
input data register. A latch is then set to return an
acknowledge signal to the interrupting device. This
latch also removes the interrupt line from the priority
tree untiL the interrupt is reset by the device.
Scratchpad
The scratchpad is a high speed random access
memory which contains one word for each of the 64
to 256 interrupt lines. The words are 25 bits long and
formatted as follows:
I
o
LEVEL
POINTER
8
24
The 8-bit level field indicates the priority assigned to
the associated interrupt line, and can be altered under
program control. l\1ore than one interrupt line can be
placed on the same level if desired, and under certain
conditions the waiting requests from a given line may
have more than one priority.
The 16-bit pointer is used by the CP to form the
address of the appropriate interrupt service routine.
This frees the computer from having fixed interrupt
entry locations in main memory.
The E bit is both a unitary and group enable bit.
Considered as part of a scratchpad word, it can be set
or reset unitarily. However, the scratchpad is also
sideways addressable in its least significant bit posi-
Figure 2-Interrupt processor block diagram
tion. Viewed together as a vertical word, the 64 to 256
E bits are divided into 8-bit groups. Each group may
be set to all ones or reset to all zeros according to the
values of the corresponding bits in a 32-bit word supplied by a CP instruction. Interrupt requests received
on a line which is armed but disabled will be accepted
and queued up, but will not be processed until the line
is enabled.
Scratchpad read requests come from either the
priority logic or the queued CAl\1, with preference given
to the latter in the event of conflict. In all cases, the
scratchpad is addressed byline number.
There are two means of altering the scratchpad's
contents (in addition to the sideways addressabi1ity
of all the E bits). A single word may be replaced, or
any. sequence of contiguous entries may be reloaded
from an image in main memory. In either case, only
one CP instruction execution is required. During block
updates, the boundaries of the affected area are defined by a pair of 8-bit upper (ULR) and lower (LLR)
limit registers. Once a transfer commences, the upper
address remains fixed while the lower address is .incremented as each new word is written. A comparator
not only detects the end of the operation but also monitors the scratchpad address register. All attempts by
the priority logic and queued CAlVi to reference within
the boundaries of the limit registers are subject to
restrictions specified in the CP instruction which initiated the scratchpad modification. The scratchpad
may be copied into main memory without imposing
access restrictions on the priority logic and queued
CAl\1.
Queued CAM
The heart of the IP is a queued CAl\1, as illustrated
in Figure 1. It contains at least eight words of content-
624
Fall Joint Computer Conference, 1970
addressable memory, expandable in increments of
four words to a maximum of 64. Every CAlVI word is
backed up by an 8-word queue, each of which is individually expandable to 32 words in groups of eight.
Each CAl\1 word and its affiliated queue is dedicated
to a particular interrupt level as long as that level is
armed and has an active or waiting interrupt request.
l\1ultiple interrupts on a single level, whether from the
same or different sources, are lined up in the queue for
that level in order of occurrence. Thus, the CAl\1 size
represents the maximum possible number of simultaneously active levels, and the length of a given queue
represents the maximum possible number of simultaneously active sources at that level. The relationships between these figures and the number of
implemented interrupt levels are parameters dependent on the specific system application and performance
requirements.
Each queue entry is 21 bits wide with the following
format:
[
LEVEL
o
I
INTERRUPT PROCESSOR OPERATION
IP operation can be divided into three independent
phases: auxiliary functions such as changing the
scratchpad contents (described earlier) or arming and
enabling interrupts; inputting interrupts to the queued
CAlVI; and outputting service requests to the CPo
LINE
8
16
20
Arming and enabling interrupts
The priority level is obtained from the scratchpad;
the line number and source identification (ID) are
received from the priority logic. The F (Filled) bit is
set if the word contains meaningful data, and is the
mechanism by which entries are automatically shifted
forward in the queue. When a word is accessed in the
CAl\1, it may remain there or it may be deleted by
resetting its F bit.
The CAl\1 entries are 23 bits wide, as follows:
o
to get multiple matches in this situation if the priority
of the specified line has been recently changed. However, the mUltiple matches are 6f no consequence since
they are all simply cleared. When the CAM F bits are
associatively tested to locate a vacant CAM word,
the choice among multiple candidates is made by logic
which selects the responding location having the
highest conventional address.
When the CAl\1 is interrogated on the juxtaposed
E and level fields, what is sought is not an exact match
as in other cases, but rather the word having the largest
numerical value in those fields. This process is accomplished in the fashion described in Reference 6.
2
I
10
LINE
18
22
The R (Running) bit being set signifies that the
service routine for this level has been activated in the
CPo The E (Enable) bit in the CAM is updated as
each new request enters the CAlVI and whenever its
counterpart changes in the scratchpad. The other
fields are the same as in the queue.
Almost all searches in the CAM are conducted on
the level field (or the combined E and level fields),
which eliminates the possibility of multiple-matches
since CAl\1 entries are uniquely allotted on the basis
of priority level. The CAM may be interrogated by
line number in order to clear the waiting interrupt
requests generated by a particular line. It is possible
Interrupts are armed and enabled by line number
rather than level since priority levels are programassigned. Interrupt lines may be armed, disarmed,
enabled, and disabled both unitarily and in groups.
Unitary arming and disarminv, is accomplished with
the arm register in the priority logic. The arm register
bits are individually addressable and may be altered
by transmitting one or more words from main memory.
The arm register can also be controlled in 8-line
groups. Each 8-line group is represented by a single
bit in a 8-bit (for the minimum 64-line configuration)
to 32-bit (for the full 256 lines) control word. This
allows all 32 8-line interrupt groups to be armed and/
or disarmed in any combination with a single CP
instruction execution.
Interrupts are enabled and disabled both unitarily
and in groups through the scratchpad (and indirectly
through the CAlVI). The scratchpad entry for each
line includes an Enable (E) bit, so unitary enabling
and disabling is performed by rewriting scratchpad
words as described earlier.
Since the scratchpad is also sideways addressable
in its LSB position, all 32 8-line interrupt groups can
be enabled and/or disabled in any combination with a
Bingle CP instruction execution.
The Enable (E) bit in the CAM is updated whenever
its counterpart in the scratchpad is altered. If a word
is changed in the scratchpad, its line and level fields
Interrupt Processing
are used to search the CAM for a corresponding entry.
If one is found, its E bit is modified to agree with the
new value of the scratchpad E bit. In the case of a
group operation on the combined scratchpad E bits,
all those levels in the groups affected by the instruction would be subject to inspection.
Since the IP components function autonomously,
facilities are available to provide program control over
the activity of those lines whose parameters are being
altered in. the scratchpad and the arm register. The
modifications (such as enable/disable, arm/disarm,
priority reassignment, or a new pointer) are immediately reflected in any waiting requests. Alternatively
these requests may be cleared, the modification taking
effect only with subsequent new interrupts. The CP
instructions which incur these changes include the
capability to specify the following modes of operation:
a. Normal operation-the queued CAlVI continues to accept and process interrupt requests
on all armed lines as usual.
b. Clear affected entries-each line changed in the
scratchpad or arm register is looked up in the
CAM, and if found the corresponding queue is
completely cleared.
c. Hold all inputs-the queued CAlVI continues
to process the waiting interrupt requests, but
no new requests are accepted on any lines until
all initiated changes have been completed. This
is accomplished by inhibiting the priority logic
response to interrupt signals.
d. Hold affected inputs-the queued CAl\1 continues to process the waiting interrupt requests,
but no new requests are accepted on any lines
for which changes have been initiated but not
completed. A comparator on the scratchpad
address register causes those lines which fall
between the current values of the scratchpad
upper and lower limit registers to be considered
disarmed.
e. Hold all outputs-the queued CAl\1 continues
to accept new interrupt requests, but no further
CP service notifications are made for any lines
until all initiated changes have been completed.
f. Hold affected outputs-the queued CAM continues to accept new interrupt requests, but
further CP service notifications are made for
lines for which changes have been initiated but
not completed. The scratchpad address register
comparator inhibits the IP from signaling. the
CP in response to interrupt requests on those
lines which fall between the current values of
the scratchpad upper and lower limit registers.
625
Any request which is inhibited this way also
blocks all lower priority requests.
These CP instruction options are coded to allow
combinations of input/ output modes. The "hold"
modes are applicable principally to cases where the
scratchpad is being loaded from an image in main
memory, or where a group enable in the scratchpad
causes several CAM updates.
input/output modes. The "hold" modes are applicable
principally to cases where the scratchpad is being
loaded from an image in main memory, or where a
group enable· in the scratchpad causes several CAl\1
updates.
Detecting and acknowledging interrupts
When an interrupt signal is detected, it is loaded
into the appropriate bit of the holding register. If the
line is armed, it is gated to the priority tree where the
highest priority line is encoded into an 8-bit scratchpad
address. The source ID is stored in the queued CAl\{
input data register, an acknowledge signal is returned
to the device, and the line is disconnected from the
priority tree until the interrupt is reset. Since the
scratchpad gives precedence to the queued CAl\{, the
priority logic may have to wait one cycle for service.
When access is granted, the program-assigned priority
level is retrieved and included with the source ID and
line number in the queued CAl\1 input data register.
Storing and scheduling interrupts
The word in the input data register is entered into
the queued CAM by first associatively checking the
level of the new interrupt request against those already
there. If a match is found, this level is already assigned to a word in the CAl\{, and the new request is
loaded into the rear of the corresponding queue. If
there is no match, the request is placed in a vacant
CAM slot. The CAM is then associatively searched
for maximum on the combined E and level fields. If
the entry retrieved is enabled but inactive (i.e., E set
and R reset), the CP is trapped to initiate the new
routine. Otherwise, no further action is necessary.
Any time that data entry is attempted and the CAM
or queue is filled, a high priority executive trap occurs
in the CP. The supervisory software then may arrange
to simulate a portion of the queued CAM in main
memory to handle the overflow at reduced rates, or
it may decide to reduce the I/O traffic to within the
queued CAlVI's hardware capabilities.
626
Fall Joint Computer Conference, 1970
Initiating CP service
There are three conditions under which the IP
notifies the CP to initiate the processing of an interrupt service routine. The first occurs when a new interrupt request being loaded into the CAM is both enabled
and higher priority than the currently· active request.
The second case is when the CP enables a level which
is higher priority than the currently active level and
which has a request pending in the CAlVI. Last is the
completion of a higher priority interrupt routine when
a lower priority request is enabled and waiting.
When one of these events occurs, the relevant line
number from the queued CAlVI is put in the scratchpad
address register. When access is granted, the IP signals
the CP, sending it the priority level, source ID, and
service Toutine pointer. These parameters presume a
software supervisor in the CP, but are rea,dily extended to interface with hardware-resident schedulers. 5
Terminating CP service
When execution of an interrupt service routine is
completed, the CP returns the priority level of that
routine to the IP. The corresponding CAM: entry is
deleted by resetting its F bit, allowing any pending
request in the queue behind it to move into the vacated position. The E bit of the new request is updated
from the scratchpad, and a new associative search for
the highest priority waiting request is then initiated
as described earlier.
Interrupt processor implementation
The IP consists primarily of memories which are
inherently regular and thus readily lend themselves
to economical batch fabrication. Implementation is
entirely feasible with the level of integration available
today in TTL, and will be further facilitated by impending improvements in semiconductor technology.
An lVISI 8-input priority encoder circuit simplifies
the task of detecting and recognizing interrupts. Three
levels of these encoders are cascaded to attain the maximum 256-line fan-in. A high speed multiplexing scheme
could be employed instead of the priority logic since
both approaches establish a somewhat arbitrary order
in which interrupts are accepted and stored. However,
cost/performance tradeoffs favor the hierarchical
technique with the logic functions currently available.
The scratchpad is conveniently constructed from
internally decoded ·64-word by 4-bit random access
memory modules. The associated address, data, and
limit registers, as well as the comparator, are also composed of standard MSI circuits.
A substantial reduction in hardware was achieved
by adapting the CAlVI to take advantage of an existing
associative memory element. Six of these4-word by
4-bit blocks are needed for every 4-word by· 23~bit
CAM increment, plus some auxiliary logic to tie them
together. The auxiliary logic would be included on
the chip if a custom LSI circuit were fabricated for
this application.
The 8-word by 21-bit queue behind each CAlVI position comprises sixteen 10-bit register packages plus
a more general 8-bit register for the F·· bits. Again, the
extra logic needed· could be integrated into a special
queue module.
Control and interface logic constitutes the remainder
of the IP, or about 10 percent of the total hardware.
A maximum 256-line configuration having a 32word CAlVI with 8-word queues consists of under 1500
IC's. Maintaining the same relative sizes of the CAM
and the queues, a minimum 64-line IP would include·
only about 500 IC's. This suggests that even an expanded IP could be purchased for less than the price
of a conventional I/O channel on many computers.
The probable impact of eventual LSI implementation
would be to reduce the chip count by at least an order
of magnitude.
INTERRUPT PROCESSOR PERFORMANCE
There are four criteria commonly used to judge the
performance of an interrupt system: reaction time,
overhead, optimum priority response, and saturation. 2
Reaction time is the time between the occurrence of an
external interrupt signal and the commencement of
the first useful instruction in response to that signal.
(This interrupt is understood to require that the CP
pursue a higher priority task than is presently under
way.) A maximum of 5.0 microseconds elapse in a
256-line IP from the moment an interrupt occurs until
the CP is notified. This period is nominally 2.5 microseconds but the higher figure arises from worst case
synchronization of the .priority logic. Subsequent
interrupts can be accepted by the IP every 1.4 microseconds· and can also be sent to the CP at the same
speed. The remainder of the computer's reactio.n time
will be contributed by status preservation activities
in the CP. A contemporary machine having a multilevel priority structure may be able to alert the CP
this quickly, but it cannot so easily divorce itself from
the CP's participation. When the liabilities of conventional interrupt hardware are compensated for in
Interrupt Processing
the software, the supervisory bookkeeping can far
outweigh the hardware delays.
Similar considerations apply to the interrupt completion procedure which is the second half of the interrupt system overhead. This overhead is defined as the
difference between the time needed to completely
process the incoming request and the execution time
of all useful instructions. No more than 1.4 microseconds transpire when a 256-line IP terminates
an interrupt, for a total IP overhead of 2.8 microseconds
per complete interrupt cycle. Thus the IP can support a
sustained throughput rate of almost 400,000 interrupts per second. Additional overhead factors in the
machine are diminished by the power of the IP, but
will be determined by the integrated hardware and
software design of the CP's executive structure.
The independence of the IP's input and output
functions implies occasional conflicts in accessing
the scratchpad. These are resolved in favor of the
queued CAM but the priority logic will not have to
wait more than one scratchpad cycle since the CAM:
cannot supply consecutive CP service requests at
the scratchpad cycle rate. In the worst case only one
scratchpad cycle time (about 50 nanoseconds) is
added to the IP input time.
The priority logic and queued CAM must also contend with occasional scratchpad updates by the CP.
This is the lowest priority scratchpad function unless
the acting CP instruction specifies one of the hold
modes during updating. However, some interference
may be precipitated by examination/modification of
the CAlVI E bits as a result of scratchpad E bit changes.
This alteration occurs in one CAlVI cycle time (about
100 nanoseconds) per affected entry.
Optimum priority response is a measure of the extent
to which the computer is always executing the most
important task as determined by the environment.
The utilization of an autonomous IP for centralized
control of interrupts assures that the other system
processors are always devoted to the highest priority
jobs without diverting their efforts to evaluate and
manipulate interrupts.
To maintain accuracy in the priority scheduling, it
is necessary that the lines which require very fast
reaction time be attached to higher positions in the
priority tree. Once in the queued CAl\1, all interrupts
627
are served on the basis of their program-assigned
priorities.
Saturation occurs when the system cannot respond
quickly enough to all of the interrupts causing some
of them to be disregarded. Protection against this is
inherently supplied by the queuing that occurs in the
IP.
CONCLUSION
A unique Interrupt Processor has been described which
uses hardware to perform many of the interrupt handling functions heretofore dealt with by software in
large on-line multiuser systems. The operation of this
unit has been described and a brief look at its implementation and performance has been given.
The most significant aspect of the IP is the queued
content-addressable memory which provides an efficient interrupt organization and storage facility. This
queued CAl\1 concept should also prove to be highly
effective in many other hardware solutions to supervisory system problems normally handled by software.
REFERENCES
1 S ROSEN
Hardware design reflecting software requirements
Proc FJCC 1968 pp 1443-1449
2 E R BORGERS
'
Characterics of priority interrupts
Datamation June 1965 pp 31-34
3 R J GOUNTANIS and N L VISS
A method of processor selection for interrupt handling in a
multiprocessor system
Proc IEEE December 1966 pp 1812-1819
4 R J GOUNTANIS and N L VISS
Methods of interrupt routing in a multiprocessor system
IEEE Twin Cities Section November 1967
5 B W LAMPSON
A scheduling philosophy for multiprocessing systems
CACM May 1968 pp 347-360
6 M H LEWIN
Retrieval of ordered lists from a content-addressed memory
RCA Journal June 1962 pp 215-229
7 J G BENNET
Letter
Datamation October 1965 p 13
8 R V BOCK
An interrupt control for the B5000 data processor system
Proc FJCC 1963 pp 229-241
A language-oriented computer design*
by CLAY McFARLAND
First Business Computing Corporation
Dallas, Texas
3. Professional programmers
4. System implementors
INTRODUCTION
Learning to program in a general-purpose, high-level
language is a formidable task for a person who simply
wishes to use the computer to solve his problems. He
must learn how to express his problems in algorithmic
form in the language, the constraints and idiosyncrasies of the language, and the mechanics of running
a program on his computer. If he wishes his programs
to be efficient, he must learn which constructions in the
language use the machine effectively and which do not.
This is complicated by the unpleasant fact that effectiveness in the language may not correspond to effectiveness in the machin~. A concise, well constructed
statement may use much more machine time than an
ungainly structure that does the same thing.
Part of this learning process is quite beneficial; for
example, being forced to state a problem precisely
enough for a computer solution can cause a significant
increase in understanding of the problem. System programmers can ease the user's task by providing a
language whose terminology is close to that of the types
of problems to be solved, or by constructing a simple
job-control language. Difficulties in using computers
are often the result of either poor system design or a
mismatch between the language and the computer
being used. Thus, while it is the user's responsibility to
produce good algorithms for solving his problem, he is
entitled to assume that a good construction in the language he is using will produce an efficient program in
the machine.
Computer users can be roughly divided into four
classes:
Historically, very little has been done to make the
computer usable "by class 1 and class 2 users; questionnaire programs and languages such as JOSS and a subset of APL are changing this to some degree. Computers
and systems have traditionally been more or less
optimized for the class 3 user, although this is probably accidental in most cases. Historically, the only
consistent optimization has been the minimization of
machine hardware.
Unfortunately, on most systems the class 4 user is
forced to design his structures using bits and fields in
machine words, and to design his systems to be written
in assembly language. Special languages such as APL,
LISP and the various compiler-writing languages have
been developed for this user, but these languages have
been designed for a narrow range of information structures and a slightly wider class of problems. The only
general-purpose languages that have met the needs of
the sophisticate~ user are Burroughs extended ALGOL
and PLjI. While it is feasible to write an operating
system in PLjI, there has been a large loss in efficiency;
this loss is justifiable only in a system of the order of
magnitude of MULTICS, which simply could not have
been written in assembly language. Systems written
in extended ALGOL, on the other hand, are among the
most efficient in existence. Table I shows the results
of a comparison between the Burroughs B5500 and
IBM 360j 40 for an ordinary numerical problem. The
test was run by W. M. McKeeman. The reason for this
performance difference is straightforward: the structure
of PLjI does not match the structure of either System
360 or the GE 645, 'while the Burroughs machines
faithfully mirror the structure of extended ALGOL.
This last class of user is often producing systems that
will be used by many other users of all classes. It is
therefore of primary importance to optimize the machine hardware for this user. To do this, the hardware,
1. Non-programmers
2. Occasional users
* A portion of this research was supported by Air Force Avionics
Laboratory Contract F-33615-68-C-1682, at Texas Instruments,
Inc., Dallas, Texas.
629
630
Fall Joint Computer Conference, 1970
TABLE I-Operating System Comparison
Burroughs B5500 vs IBM 360/40
B5500 (ALGOL)
360/40 (PL/I)
Debug
Read
2 days
2 months
< 1 sec.
22 sec.
Memory Cycle
B5500
360/40
6,us
2.5,us
operating system, and primary languages of a system
should be designed as a unit. This implies that machine
hardware should be designed to make it very easy to
produce powerful programming languages, arid to allow
the production of an operating system that presents a
simple, understandable face to the user. The hardwarelanguage-system combination should be designed to
minimize the total cost of production of the application
programs of the class 3 user; this cost includes programming time, machine time, and the cost to a project
to any delays in debugging, etc. As a side effect, a
system designed in this way will provide aid and comfort to the class 1 and class 2 users by reducing the
cost of their answers.
The hardware in a total system design would have
the following characteristics:
1. Information structures used by class 3 and class
4 users would be basic structures accessible to a
machine language; operators normally used on
these structures would be built in as machine
instructions.
2. Control flow and data access methods in the
machine would be the same as in its basic languages and its operating system.
3. The system would perform implicit functions
for users, but would avoid producing unexpected
side effects. Further, any implicit functions could
be overridden by the user. In other words, the
system would appear simple to the casual user,
and as complex as desired to the sophisticated
user.
The remainder of this paper will describe a language
and computer structure designed to lfleet the criteria
discussed above. The programming language for the
system is called simply "the programming language"
(TPL); the comput.er system is named the Hydra.
Compile
3 sec.
180 sec.
Word Length
48 bits
16 bits
Link-Edit
Run
none
69 sec.
7 sec.
22 sec.
Floating Multiply
30,us
80,us
Both the computer and language are experimental and
in a state of continual change. The system is described
as it is conceived at this writing.
TPL
The aim of the TPL design is to produce a language
that will be an aid to the programmer in thinking about
his problem and the processes he is using to solve the
problem. Our purposes are quite similar to those of the
ELF project of Cheatham, Fischer and Jorrand. 3 However, we are not constrained, as they were, by the necessity of producing a language compatible with current
computing systems. Many of the constructs in TPL
are the same as or similar to the corresponding BASEL
(the base language of ELF) construct, but the parts of
the languages that deal with their machine environment
are quite different. The operator structure of TPL is a
generalization and expansion of the Iverson notation
data operators 9 and the control operators of EULER18
and Linear C.ll The data operators are essentially those
in the appendix of A Programming Language, and the
control operators have been extended to all compatible
data structures.
Several departures from the traditional structure of
expression-oriented languages have been made.
1. The go to operator has been eliminated. This
should make programs easier to read and good
programs easier to construct. Without the go to,
labels are unnecessary, and without labels the
syntactic type (statement) is unnecessary.
2. The assignment expression has been restricted.
An assignment can change the value of variables defined in its block at its own level and no
others.
These t.wo changes have many good effects. Their
Language-Oriented Computer Design
only bad effect is making coroutines more difficult to
construct (though possibly easier to understand after
they are constructed). Although programming without
go to's is unnatural when first tried, the resulting programs are invariably superior in both structure and
readability to conventional programs.
631
Program structure
The syntax for TPL is shown in the Appendix. In
TPL, declarations are expressions to be evaluated at
compile-time. A simple declaration, such as
new b,
3. A process is a basic data type, and includes the
concepts of macros, subroutines, and procedures.
Functionally, these structures differ only in
binding their variables to a fixed reference at
compile-time, load-time and run-time, respectively. The differences in binding time can be
explicitly controlled by the programmer. Processes can be called implicitly, i.e.,
establishes the scope of b as starting with the block
containing the declaration; storage for b will be allocated when b is given a value, and freed when the block
is no longer active. If a value or attributes are assigned
to a variable, as
new integer c+-6,
A+-B+C
where B is type real and C is type process, would
cause C to be executed and the value it returns
checked for compatibility with B. If it were
compatible, A would be marked defined, and assigned the value and attributes of the result. If
the value of C werE~ a process, it would be executed, and so on.
4. The operator-operand structure of TPL is quite
regular. Operators are valid only for strictly
compatible data types (i.e., ">" and "<" are
not defined for logical variables, true is not
equivalent to the number 1, etc.), although obvious automatic conversions such as integer to
real, real to complex, etc., are provided. If an
expression is valid, it remains valid if variables
of any structure class are replaced by
A. A process, block, or expression whose value
is a variable of the same type.
B. An implicit process call, if a variable of type
process is not compatible.
C. A variable of a different structure class that
is compatible mathematically with the expreSSlOn.
The strict application of (3) and (4) create some
collisions. For example, suppose we write
a+-begin new c ... end
and we want a to be type process, with the value given
by the program on the right of the assignment. However, the program will be executed and its value assigned
to a. To allow the former option, we have added an
operator, " ... ," which protects its operand from immediate execution. The statement
a+-"begin new c, ... end"
would produce the former result.
storage is allocated for c when it is given a value (in
this case, at compile-time), and freed when the main
program of which c is a part is no longer active.
Expressions that are not part of declarations are
evaluated and replaced by their value as soon as their
variables become fixed in value. If an expression's variables are fixed at compile-time, the expression functions
as a macro. The only explicit transfers of control in
TPL are a repeat operator, which repeats the innermost
block or compound expression in which it is imbedded,
and an exit, which causes execution to resume at the
first instruction past its block or compound statement.
Every expression in TPL has a value, which is placed
on top of a system-value stack. Operators manipulate
the stack implicitly, and the top of the stack (the value
of the last expression) can be referenced explicitly with
the reserved identifier sysval. An expression can be
terminated with a semicolon, colon, or period, which
respectively throwaway, save, and execute the systemvalue.
Figure 1 is an example of an ALGOL-like TPL program, the Euler precedence parse. This is an exact copy
of the Euler algorithm as presented in Part I of (15),
with precedence relations represented correctly as
matrix· entries. The program in Figure 2 improves on
the algorithm by producing a vector of character vectors, eliminating the necessity to scan both forward and
backward for relations. The program in Figure 3 is the
same as in Figure 2, but it uses the implicit TPL value
stack to avoid explicit temporary storage.
Data
Each data item in a TPL program has a value and
several attributes, including data type, structure class,
defined, size, length, etc. The data types currently al-
632
Fall Joint Computer Conference, 1970
4.
5.
6.
7.
begin new vector 5i new integer ii ji ki
(1)
5~P[O]i
(2)
While p[k] "
(i~j~i
i~Oi
+ 1;
k~l;
'.L' do
s[i]~p[k];
while m[s[i]
(3)
k~k
+ Ii
: p[kl]= 3 do
(while m[s[j-l]; s[j]]= 2 do j~j-li
(4)
s[j]~leftpart
(w(i-j+l)/S)i i~j;
end
1.
Initialize string indices
2.
until end symbol (L) increment pointers to
s get next input symbol, increment input index.
3.
Perform the next statement only if sri] ~p[k]
4.
Back up
reset i.
j to last <., reduce resulting string,
Relations in Figures 1,2,3
are coded
<. = 1
~ = 2
to>
Array
Tree
List
Set.
= 3
l\1: athematic ally , there is a lot of redundancy in
this set of structures, but the redundancy mostly
disappears when the machine and operating system
in which the language is imbedded are considered. For
example, a matrix may be sparse or triangular, and the
storage allocation may differ for these special cases.
A set is a collection of elements with no implication
as to ordering or any other relationship between the
members of the set. A set is stored in lexical order to
make set operations more convenient. A tree is stored
in end-order with an index, and storage allocation
methods for a list have special provisions for selfcontaining lists, etc.
Each variable has a definition attribute. A scalar
may be defined or undefined; a variable with more than
one element may also be partially defined. Other attributes are length of each element of a variable in
units appropriate to the variable, size of each dimension .of a variable, and various special attributes for
variables of type process.
Figure l-The EULER parsing algorithm
~
begin
lowed in TPL are:
1.
2.
3.
4.
5.
6.
7.
8.
Logical
Integer
Real
Character
Reference
Process
Pattern
Mixed.
(1)
vector Si integer ii ki Xj
~ parse~"~ x~m[w(l)/s[i-l]:
(2)
i+i + Ii
(3)
s[i-l]+-s[.i-l], sri]
(4)
(s[i-l]+leftpart (s[i-l])j i+i-lj)
s[i]]
j
end
if x = 3 then repeati"
S+P[O]i i+li
k~lj
While k may have any structure of booleans
as a value. The structure of the values of < expression2> and' must be the same as that
of < expression-1 >, (if < expression-1 > is not a
scalar boolean), and the if operator is applied to corresponding elements of the structures.
In the expression
case (index-valued-expression) of (expression-list)
4. x [d], x = (S1, S2, Sa, S4).
The more familiar operators were included for two
reasons. First, the data structures must sometimes be
expressed differently; in (1) band c could be vectors
and u scalar boolean, while in (2) band c would have to
be one-element vectors with vector components to
be compatible with u being scalar boolean. Secondly,
readability of programs is usually better with the control operators written out, and many programmers
will find this notation easier to think in than the more
abstract Iverson forms.
One departure from Iverson that must be allowed
for is the incompatibility of integer and logical variables.
The compatibility of integer and logical causes anomalous results in Iverson, PL/I and other languages.
As Cheatham noted, the PL/I expression
7 <6<5 «/(7,6,5) in Iverson)
has the value true (1 in Iverson), which is certainly
not what one expects. In TPL, 7<6<5 will produce
an error, since (7 <6) is logical and 5 is integer. However, the epxression
then else
< expression-3 >
THE HYDRA COMPUTER
Introduction
ALGOL-like languages have many features in common which are not adequately supported by conventional hardware. Among these features are
1. Run-time binding of variables, including dynamic storage allocation.
Language-Oriented· Computer Design
2. Procedure calls, particularly recursive calls and
procedures which have variable-size arrays as
formal parameters.
3. Block structuring, which requires a subroutine
call for begin and end statements on conventional
machines.
Since TPL allows the type and structure class of a
variable to vary dynamically, it requires even more
run-time checking than ALGOL or PL/I. The class
problems for which TPL would be an effective language
is therefore quite small on a conventional. machine. In
order to make TPL (and other ALGOL-lIke languages)
effective, the host machine must be. designed to provide hardware support for the features described above,
as a minimum.
Run-time binding of variables impiies the need for
descriptor information associated with each variable. A
variable's descriptors should be modified automatically
by the system, and the descriptor information should
be available to the programmer. For maximum efficiency, descriptors should be kept in a fast register
descriptor file while a variable is active. Descriptor
manipulating routines can be hard-wired, as in the Burroughs B6500-7500 machines,2 or microprogrammed, as
in the 360 implementation of Euler.17 Dynamic storage
allocation should be done interpretively; producing the
code in...,line, as is done in some PLjI implementations,
slows down the compiler drastically. Storage allocation
can be done much more efficiently in microcode than
with higher-level machine instructions. It would seem
that a system must have at least its basic allocation
routines microcoded to be really efficient.
Procedure calls can be handled quite easily with a
hardware program stack, as in the Burroughs machines.
The stack maintenance routines must be either hardwired or microcoded ; machine instruction subroutines
will lose most of the speed gained by putting the stack
structure in hard ware.
The necessity for subroutines to implement block
structuring of programs is partially eliminated by the
program stack. The remainder of the block mechanism
is handled by coding each variable reference as a twocomponent address of the form
of
(level, variable number).
The level number is used to get a pointer into a descriptor file from an address table, as shown in Figure 4.
The variable number is then used. as a displacement
from. the pointer.
Several other forms of hardware support for TPL
are desirable. Run-time optimization of programs al-
1
LEVEL 0
DESCRIPTORS
0
I
1
1
2
0
2
"',
-
LEVEL 1
\0.
r
.............
~
A DDRESS
635
TABLE
.
LEVEL 2
(ACTIVE)
LEVEL 2
(INACTIVE)
DESCRIPTOR
FILE
Figure 4-Descriptor addressing
lows programmers to express algorithms in a natural,
readable manner and have them executed in an efficient
manner. The producti()n of code from compilers is
also much easier if run-time optimization is done. A
hardware mechanism to allow user-defined structures
and operators without machine-language subroutines
is also desirable. This would be implemented most
flexibly with a writeable control store, but it is feasible
to consider· hard-wired extensions if an operator or
structure is to be used often in a machine's job load.
Finally, parallel . (or at least partially overlapped)
operation of checking and operand location with normal execution is desirable. This parallelism is particularly desirable since TPL contains many complex
operators which will require long execution times. If
the operations in a program are sufficiently complex,
i,he operand checking and locating features may run
With no overhead at all.
Processor organization
The Hydra computer has been designed to provide all
of the hardware support features described in the last
section. It is felt. that the projected relative costs for
hardware and software during the next few years justify
including all desirable software support features in the
machine hardware. Another design feature is the maximum use of microprogramming in the system. This was
done for two reasons. First, microprogrammed as opposed to hardwired implementation replaces random
logic with more regular memory hardware structures.
It appears that the greatest cost savings available from
MSI and LSI techniques will result from the use of
regular structures, such as memories. The cost and dif-
636
Fall Joint Computer Conference, 1970
Instruction acquisition unit
begin new ai b; a+Oi b+doiti
a+a+xi
end
TPIJ program
ha, b
load a load 0 +
<1
load b
doit + i load a load a load x
Hydra program
Figure 5-Main memory program
ficulty of producing random logic will remain high, even
in LSI. Second, it is quite difficult to determine in advance which operations will limit the speed of a system;
the limiting factors will almost certainly be different depending on job mix. It seems a sensible design procedure
to microprogram everything possible, and produce logic
chips for the critical functions for each application.
The logical structure of the Hydra consists of four
separate functional units operating in parallel. Each instruction is pipelined through the four units. The degree
of parallelism required in any actual implementation
would be a function of the relative time required for a
logic state, a micro-memory access, and a main memory
access. The four units of the Hydra are
1. Instruction Acquisition Unit (IAU)Locates a program and its fixed variables and
reads them into fast temporary storage.
2. Program Stream Unit (PSU)Locates executable instructions and places them
in a queue. It also performs some code optimization.
3. Operand Acquisition Unit (OAU)Fetches the operands for each instruction. It
also does type checking and initiates procedure
calls.
4. Execution Unit (EU)Performs the actual execution of operations, and
stores the results in temporary storage.
A program in main memory has the structure shown
in Figure 5. Instructions and their operands are kept
in a reverse Polish string. Each instruction and pointer
is one byte long (the size of a byte may vary in different
implementations of the Hydra). The program is called
by inserting its descriptor information into a set of
hardware stacks which hold program parameters (the
initial parameters for a program are kept in its descriptor entry), called the Status Stacks. The Instruction
Acquisition Unit (IAU), Figure 6, then uses the Status
Stack information to read the program into a fast
memory for holding active programs, called the Instruction File (IF). The first item read is a pointer to
the static-variable descriptor file entries for the program, which will usually be in main memory. The IAU
uses this pointer to load the Static Variable Descriptor
File entries for the program.
The Hydra is effectively interpreting a TPL program
with microcode. The IAU structure decreases the main
memory bandwidth required for the interpretation
process.
Program stream unit
The Program Stream Unit (PSU) , Figure 7, works
on the IF representation of a program. Its output is a
stream of executable instructions which are passed on
to the Operand Acquisition Unit (OAU) through an
Instruction Queue (IQ).
INSTRUCTION
ACQUISITION
CONTROL
STORE
STATIC
VARIABLE
DESCRIPTOR
FILE
INSTRUCTION
FILE
STATUS
STACKS
FOR FIGURES 6, 7, 8, 11, 12
~ CONTROL PATH
==>
DATA PATH
~ DATA PATH TO MAIN MEMORY
I
We will give a brief description of the construction
and operation of each unit, and its relation to the TPL
language structure.
Figure 6-Instruction acquisition unit
Language-Oriented Computer Design
The first time a program is processed, the PSU will
simply pass all instructions that are not the operands
of a conditional operator into the queue. If a sequence
of instructions is the operand of a conditional, the
sequence is given a Temporary Descriptor File entry,
and a pointer to this entry is placed in the queue. This
scheme allows code that mayor may not be executed
to be bypassed until its conditional is resolved, avoiding
the necessity of stopping instruction lookahead or
guessing the value of the conditional.
The PSU also examines each operator to determine
if the value of its result is fixed during this activation
of the program. If the value after the operation is executed is variable, the operator is placed in a fast memory
which holds the expressions in a program that can
have variable values, called the Dynamic Instruction
File (DIF); if the value is fixed the operator is discarded after being placed in the IQ. If an iteration or
recursion occurs, the reduced program in the DIF will
be executed. This process amounts to a run-time compilation of each program. This allows a better code
optimization than is possible at compile-time, and also
allows programmers to put computations where they
occur logically in a program, without worrying about
introducing inefficiency at run-time.
The PSU provides hardware support for the runtime optimization described previously, and for the
block structuring of TPL.
Operand acquisition unit
The OAU, Figure 8, removes instructions from the
head of the IQ, and prepares them for the Execution
INSTRUCTION
FILE
STATUS
STACKS
637
STATUS
STACKS
DESCRIPTOR
FILES
(STATIC, DYNAMIC,
TEMPORARY)
Figure 8-0perand acquisition unit
Unit (EU). It locates operands, does type checking,
executes procedure calls and load instructions, and
maintains the descriptor files.
Each load instruction is followed in the instruction
stream by a pointer to the descriptor file entry for the
variable to be loaded. A load is processed by placing its
pointer on top of the System-Value Stack, and setting a
code associated with the pointer to indicate which descriptor file the pointer refers to (this is determined by
the kind of load instruction).
An operator causes the OAU to build a vector for
the Operation Unit, as shown in Figure 9. The operator
is placed directly into the operation vector, and the
type and length of the operands are obtained from the
descriptor file entries for the operands. The operand
entries are pointed to by the top n entries in the System-ValueStack for an rz-ary operator. The types of the
operands are checked for compatibility with each other
and with the operation being performed. The result of
the operation will be placed in temporary storage, with
a pointer to a Temporary Descriptor File entry on top
of the stack. The OAU creates the temporary descriptor
entry, pops the operand pointers off the stack, and
places the temporary pointer on the stack. It then
PROGRAM
STREAM
CONTROL
STORE
INSTRUCTION
QUEUE
Figure 7-Program stream control unit
OPERATOR
I
OPERAND
TYPE
LENGTH
21. . .1
NUMBER OF
OPERANDS
OPERAND n
I
OPERAND 1
RESULT
Figure 9-Operation vector
I
638
Fall Joint Computer Conference., 1970
STACK IN
THIS DIRECTION
!
QUEUE IN
THIS DIlU:CTION
ACTIVE
INSTRUCTION
Figure lO-Instruction queue
marks the vector ready for execution (the operation
vector will be queued if necessary).
If an execute jnstruction or an implicit procedure
call appears, the OAU places the procedure's descriptor
entries into the corresponding status stacks, and pushes
the IQ stack. The Instruction Queue is a queue in one
direction and a stack in another, as shown in Figure 10.
Execution of the called procedure begins as soon as the
IQ is pushed. A block end or an exit instruction causes
the OAU to pop the status stacks pushed by the block
(or procedure), and pop the IQ, thus restoring the previous machine conditions.
The OAU implements the self-describing data feature
necessary to support dynamic binding of variables in
TPL.
Execution unit
The EU, Figure 11, requests operands from main and
temporary storage, breaks down complex operators
not actually implemented in the Operation Unit, executes each instruction, allocates a block of temporary
storage for the result and places the result in temporary
storage.
The EU resembles the central processor of a conventional computer, with all functions associated with
operand location and instruction sequencing removed.
The logical separation of the four Hydra units
allows whatever parallel operation is necessary to be
implemented, thus lowering the overhead associated
with .the procedure-call oriented structure of TPL.
This separation also makes extending the language
easier; new structures and operators will require new
microprograms only in the EU, and new codes for descriptor entries used by the OAU.
ownership of a computer, improved hardware technology should· be used to decrease costs other than
hardware. There has been quite a bit of discussion about
implementing software functions in hardware, but very
few concrete proposals have been made on exactly how
this should be done. Outside of specific applications, it
is quite difficult to assign portions of a system to hardware or software. The Hydra has been designed with
the idea of putting operations and structures normally
used in operating systems into the basic machine hardware. This has been done by designing a language with
data structures and operators suitable for writing
operating systems, and then implementing the language
structure as directly as possible in hardware. It should
then be relatively easy to build software functions into
hardware in specific instances.
The Hydra processor design is currently being studied
using a simulator being written in ALGOL-SIMULA
for the Univac 1108. The simulator is necessary to
answer questions such as:
1. Should we add a control store to handle storage
allocation and related activities? If not, how
should these routines be divided among the
present control stores?
2. What are the optimum sizes for each of the
fifteen memory units in terms of both performance and cost effectiveness?
3. Would the activity balance in each unit be improved by relocating some functions (for example, the OAU might handle decomposition of
complex operations instead of the ECU)?
4. How does the Hydra's performance compare
with
a. conventional machines
b. conventional machines with cache memory
EXECUTION
CONTROL
STORE
OPERATION
VECTOR
SUMMARY
It has been recognized for several years that, since
pure hardware cost is a small percentage of the cost of
Figure ll-Executien unit
Language-Oriented Computer Design
c. Hydra-type machines with cache memory instead of memories with assigned functions?
There are reasonably appealing intuitive answers to
all these questions, but the simulation is vital for
authoritative answers. Intuition has not proved very
accurate when applied to very complex systems.
Work is also proceeding on a TPL compiler for the
PDP-lO. It is a reasonable assumption that there exist
programs that require data structures that are sufficiently complex to allow TPL to be efficient on a conventional machine. Th~ PDP-lO rrPL will allow us to
test this assumption and discover any hidden difficulties
in using TPL.
ACKNOWLEDGMENTS
The author would like to credit the designers of the
Burroughs B ~ 5000 machines 2 ,8 for providing several
of the ideas used in this system; the designers of the
EULER,I8 PL/360,I6 Linear C,ll and LISplo languages
and the Iverson notation for many interesting ideas;
and to thank Bill McKeeman, Bob McClure, Tom
Cheatham, Doug McIlroy, Dick Karpinski and Hi
Young for many stimulating discussions which helped
clarify some of the murkier portions of the design; and
Cliff Hemming and Jerry Duval for their work on the
simulation project.
The author would particularly like to thank Session
Figure 12-Hydra processor block diagram
639
Chairman Dick Watson for many suggestions that improved the readability of the paper, and Barbara
IVIcFarland for typing and illustrating the paper.
REFERENCES
1 T R BASHKOW A SASSON A KRONFELD
System design of a FORTRAN machine
IEEE Transactions on Electronic Computers Vol EC-16
No 4 August 1967
2 Burroughs B6500 reference manual
Burroughs Corporation Detroit Michigan September 1969
3 T E CHEATHAM JR A FISCHER P JORRAND
On the basis for ELF-an extensible language facility
Proceedings of the Fall Joint Computer Conference 1968
4 T E CHEATHAM JR
The introduction of definitional facilities into higher level
programming languages
Proceedings of the Fall Joint Computer Conference p 623
1966
5 E W DIJKSTRA
The structure of the "THE" multiprogramming system
Comm ACM 11/5 p 341 May 1968
6 B A GALLER A J PERLIS
Criteria for the design of programming languages
Univ of Michigan Advanced Programming Short Course
1966
7 B A GALLER A J PERLIS
A proposal for definitions in ALGOL
Comm ACM 10/4 p 204 April 1967
8 E A HAUCK B A DENT
Burroughs B6500 / B7500 stack mechanism AFIPS Conference Proceedings Vol 32 1968 SJCC
9 :K ElVERSON
A programming language
Wiley 1962
10 J McCARTHY
Recursive functions of symbolic expressions and their
computation by machine
Comm ACM 3 4 April 1958
11 R M McCLURE
The Linear C language
Unpublished technical memorandum Southern Methodist
University Dallas Texas 1968
12 W M McKEEMAN
Language directed computer design
Proceedings of the Fall Joint Computer Conference 1967
13 W M McKEEMAN
An approach to a computer language design
Stanford University Report C5-48 1965
14G H MEALY
A nother look at data
Proceedings of the Fall Joint Computer Conference p 525
1967
15 R F ROSIN
Co.ntemporary concepts of microprogramming and emulation
Computing Surveys 1/4 Dec 1969
16 C STRACHEY
Comments on "DL's"
Comm ACM 9 3 pp 165-166 March 1966
640
Fall Joint Computer Conference, 1970
17 H WEBER
A microprogrammed implementation of EULER on IBM
System/360 Model 30
Comm ACM 10/9 Sept 1967
18 N WIRTH H WEBER
EULER, a generalization of ALGOL, and its formal
defim:tion
Comm ACM 9/1 pp 13-23 Jan 19669/2 pp 89-99 Feb 1966
19 N WIRTH
PL/360, a programming language for 360 computers
JACM 15/1 p 37 Jan 1968
APPENDIX
Syntaxjor TPL
{program): : = {block)
{block): :. = begin {blockbody) end
{blockbody): : = {dec-list) {exp-list )
{dec-list): : = {declaration) I {dec-list)
{ex-sep) {declaration)
{declaration): : = new {dec-comp) I {declaration)
{ex-sep) {dec-comp)
{dec-comp): : = {attribute-list) {expressIon)
{attribute-list): : = {nUll) I {attribute) I
{attribute-list) {attribute)
{attribute): : = real I integer I logical I
character I reference I process I
scalar I matrix I array I tensor I
tree I list I set
{exp-list):: = {expression) I {exp-list)
{ex-sep) {expression)
{expression):: = {control-expression) I
{n-expression) I {assn-expr)
{n-expression):: = {element) I {expression)
{element) I {expression)
{operator)
{control-expression): : = {if-expr) I {case-expr)
{for-expr) I {while-expr)
{I-0 expr) I repeat I exit
{assgn-expr): : = {expression)~{expression)
{element): : = {variable) I {compound-expr) I
{block) I ( {expression»
{compound-expr): : = begin {exp-list) end
{if-expr):: =if {expression) then
{expression) else {expression)
{case-expr): : = case {expression) of
{case-list»
{case-list): : = ( {expression) I {case-list)
{expression)
{for-expr):: = for {variable)~{expression)
{for-compI) do {expression)
{for-compl): : = {null) Istep {expression)
until {expression)
{while-expr): : = while {expression) do
(expression)
·{null): : =
{variable) is as usual
{operator)::=+ I-I X 1+ Idivlreml
AIVI11=1~1<1>1
~1~liltI61~1
abs I , I / (expression) :
{expression): {expression)/ I
(operator )/[expression] I
{operator) [expression] I
I / {expression): {expression):
(expression) \
I {operator). (operator) I
[ (exp-list )]
{ex-sep):: = ;/:/.
Analog/hybrid-What it was, what it is, what it may be
by ARTHUR 1. RUBIN
Electronic Associates, Inc.
Princeton, New Jersey
THE ZEROTH GENERATION
for granted. Furthermore, an arbitrary function generator was also not shown. Apparently, that device, which
is necessary to make analog computation capable of
solving any problem, was developed later or was
considered an oddball, along with the comparator
(which is really represented by the dry friction element,
provided that the output of the dry· friction element is
Introduction
The history of the analog computer goes back to
antiquity, where tax maps were first reported being used
for assessments and surveying. However, I shall confine
this paper to the analog computer as it evolved from
World War II to the present time. For those interested
in the history of the analog computer, from antiquity to
World War II, I refer the reader to an excellent
introductory article by J. Roedel, Reference 1. The
"Palimpsest" in which Roedel's history of the analog
computing art is included is in itself an excellent history
of analog computers in the early days d~ting from
World War II to about 1954. From page 4 of the
Palimpsest, I would like to show a diagram of computing
devices as visualized by George Philbrick for an article
in Industrial Laboratories in lVlay, 1952. Of interest to
us in this diagram on the analog side, is the separation,
at the bottom, between fast and slow analog which I will
discuss shortly. We will'also note the presence of hybrid
at the very top, and this article was written in 1952! Of
course, l\1r. Philbrick's "hybrid" was reserved for the
use of the analog computer first to obtain a ball-park
idea of a solution, then followed by a separate digital
solution to obtain a more accurate answer to the same
problem. I am certain that very few people thought of
this as being hybrid computation at the time. However,
consider this definition in the light of later work reported
by Mark Connelly (Reference 2) in his use of a
"skeleton" representation of a problem on the analog in
conjunction with a more accurate representation of the
problem on the digital.
It is interesting to observe the basic operations as
defined by Roedel in Reference 1. This is shown in
Figure 2. Note that the early practitioners of the
analog art considered differentiation to be a basic linear
element for the fast speed computers and did not show
potentiometers, since the latter must have been taken
Figure I-Structure of computing devices as visualized in 1952
641
642
Fall Joint Computer Conference, 1970
BASIC LINEAR COMPUTING ELEMENTS
SCHEMATIC DIAGRAM
MATHEMATICAL OPERATION
BLOCK DIAGRAM
Rf
el
eZ
ei
~
~A
el
~Z
RZ
~
..
Rf
Rf
eo. e l - . eZRl
RZ
ADDITION
~
-f
ei
~
..
Rf
eo_-~i
R.
I
SCALE CHANGE
Cf
-i
~
D··
1D ~..
e,
1
e o - -- f i dt
CfR,
INTEGRATION
Rf
e,
~~
e,
de·1
eo.R C · _
f I dt
DIFFERENTIATION
NON-LINEAR OPERATIONS
e.
MULTIPLIER
LIMIT
ez
-sfI
DEAD ZONE
OR Y FRICTION
#-
~
e.
e.
+C,
-A
ABSOLUTE VALUE
I
+C
- C
"
e.
e.
I
I
I
~
=lM
~
---1"
~
-1'
..
..
..
eo· Ke,el
for -C< e i < C.
for
_,<-C, e,>C,
for -C C,
eo· Kei
for
-i>O,
eo·+A
ei
+.
K_,
e o-
e.I
eo
for
e i < 0,
Amplifier
ei
-1"
~
..
Figure 2-Basic linear and nOll-linear analog operation and components
-o--A
e o- Kleil
Analog/Hybrid
643
Figure 3-Pullman-Standard Car Manufacturing Company's
analog computer installation
used to drive a switch or a gate connected to some other
computing element). There was a great deal of emphasis
in those days on the solution of linear differential
equations, obviously because those required the simplest
computing components. Perhaps also, because one could
Figure 5-Boeing analog computer, courtesy of
Boeing Airplane Co.
obtain check solutions to such equations with pencil and
paper, and computers, being relatively new, could not
yet be trusted.
Hardware
Figure 4-Computing equipment in a typical rack assembly
The major manufacturers during this initial period
were the Boeing Company which made the BEAC
computer, the Berkeley Scientific Computing Company
which made the EASE computer (Berkeley subsequently became part of Beckman Instruments), the
Goodyear Aircraft Company which made the GEDA,
the IDA computer with which I am not familiar at all,
the George A. Philbrick Research Company which
made the GAP /R computer, and finally, there was the
Reeves· Instrument Company which made the REAC
computer. Some pictures of these early analog computers
are shown in Figures 3 through 8. Figure 3 shows a
GAP /R installation while Figure 4 shows a close-up of
how those computing components were interconnected.
You will note an absence of a patchboard. Can you
imagine checking this one out today?
Note the telephone jack panels on the Reeves
computer and note also that the Berkeley and the
Goodyear computers are the first ones with patch
panels. These figures date from about '1952 or 1953.
EAI, which was just beginning to build analog computers, does not even show. The typical size of computers
in those days ranged from about 20 amplifiers up to 80
644
Fall Joint Computer Conference, 1970
need for such devices in the design of their own equipment, whether it was airplanes, electronic gear such as
radars, or control systems. Philbrick, on the other hand,
and possibly also the Berkeley Company, concentrated
from the very beginning on the process control
applications.
Applications
Figure 6-Goodyear GEDA computer installation, courtesy of
Goodyear Aircraft Company, Akron, Ohio
amplifiers, which was considered to be fairly large. One
manager, in fact, was proud of the fact that he could
expand his 80 amplifier installation to 160 without
requiring any additional wiring. The accuracy of the
components was of the order of one percent (and that
applied to resistors and capacitors as well as to the
electrical components). Overall solution accuracies on
what was then considered medium size non-linear
problems was of the order of five percent. One final point
of interest is that several of these manufacturers,
mainly Boeing, Goodyear, and Reeves were primarily
aerospace/defense manufacturers who saw the obvious
Figure 7-Berkeley EASE computer, courtesy of J. B. RAE,
Los Angeles
The 2nd page of the table of contents of the
Palimpsest is reproduced here in Figure 9 and shows the
wide variety of applications that were actively investigated in the early 1950's. You will note in parti~ular
the beginnings of an analytical attack on our environmental problems in the papers on the freezing and
thawing of soils as well as flood routing. The analog
equipment, especially that which did not have patch
panels was generally purchased for a particular problem
or problem type. For example, the Pullman Car
Company would buy one for solving their "transportation equipment design" problem. An aircraft manufacturer would buy a computer to study the control
system of a particular airplane. There was an almost
complete lack of user conveniences leading to the
ridiculous situation of being able to obtain a complete,
single solution to a complex set of differential equations
in 5 milliseconds, but having to wait several days, at
least, to change to another problem, due to the lack of a
patch panel and other amenities, such as a readout
system. This type of inaccessibility (to the Hnext"
Figure 8-Reeves computer installation, courtesy Reeves
Instrument Company
Analog/Hybrid
problem) has been at the root core of the ailment in the
analog field and has given the analog computer the
reputation of being "inflexible." This ailment is still
with us, albeit to a much smaller extent, and a cure is
visible on the horizon, as we shaH see later. For further
information on techniques and methods that were
expounded in the early years of analog computation, the
reader is referred to References 3, 4 and 5. This by and
large represents the first generation analog; however,
since I seem to have too many generations, as we shall
see later, I will term this the heroic age, or the zeroth
generation. This generation coexisted with the heroic
age digitals, such as the ENIAC, EDVAC, the
ORDVAC, l\1ANIAC, and the UNIVAC.
645
MODELLING of PHYSICAL PROCESSES............................................................
146
The Electro-Analogue..............................................J. M. L. Janssen and L. Ensing
147
Discontinuous Low.Frequency Del.y Line with Continuously V.ri.ble Delay
......................................................................................................J. M. L. Janssen
162
Bucket·Brigade Time Delay..............................................................G. A. Philbrick
163
Solving Process-Control Problems by Analog Computer..................................... .
............................................................................ R. J. Medkeff and H. Matthews
164
ELECTRONIC ANALOG METHODS in DETAIL..............................................
167
Precision in High.speed Electronic Differenti.1 Analyzers................................... .
..........................................
.............................. H. Bell, Jr., and V. C. Rideout 168
An.log Computer Solution of • Nonlinear Differentiai Equation ....................... .
............................................ .......................... H. G. Markey and V. C. Rideout
177
The Study of Oscill.tor Circuits by Analog Computer Methods......................... .
.................................................. H. Chang. R. C. Lathrop, and V. C. Rideout
184
A Differe~ltial.An.lyzer Study of Certain Nonlinearly Damped Servomechamsms..................................................... R. C. Caldwetl and V. C. Rideout
193
Appf~tiori of .n An.los Computer to Design Problems for Transponation
THE FIRST GENERATION
The next generation, here termed the first, more or
less coincided withthe arrival of EAI on the scene, with
its establishment of the firm need for a patch panel and
an integrated set-up and readout console as part and
parcel of the analog computer. In other words, human
factors entered into the picture, also, this generation saw
the arrival of the .01 percent component, such as resistors
and capacitors, which allowed linear problems to be solved
more accurately than the solutions could be dispJayed
on a strip chart recorder, X - Y plotter, or oscilloscope.
The credit for this shift in emphasis on more accuracy
and more user conveniences must go to the manufacturers who went against the ideas of some of the then
old line users, who kept pointing to the problems that
were being solved and observing that much of the input
data was unknown perhaps even within a factor of two
of the correct value. These old time analysts recognized
that there was no need for obtaining very accurate
solutions to such problems. However, they overlooked
the crutch available to the insecure analyst if he can get
a repeatable, accurate answer even though the model
is not exact. This analyst then has fewer questions from
his management, because when he goes back for reruns,
he gets the same old answer to compare with at the same
time, the solutions for the new set of parameter values.
Thus, he and management both think they understand
the problem.
(Aside-I learned this trick early in the game. In
order to convince my management and customers as to
the validity or correctness of a set-up to a problem, I
always went back to a "standard" solution, if a check
solution was not available. And if the standard or check
didn't repeat, then I would hopefully "tune-up" the
equipment to produce a "replica" of the check solution.
In some cases, I must confess, I may have "de-tuned"
the equipment to produce the so-called "check".)
EqUipment ...................................................... ............................................J. Roedel
199
ANALOG STUDIES of ELECTRIC POWER SYSTEM TRANSiENTS........
216
Surge and Water. Hammer Problems............................................... H. M. Paynter
217
Methods and Results from MIT Studies in Unsteady Flow ........ H. M. Paynter
224
The An.log in Governor Design ...................................................... H. M. Paynter 228
Tie Line Power" Frequency Control........
.................... H. M. Paynter
229
Electronic Computer for Resolution of Steady - St.te Stability Problems and
Panicularly for Automatic Control Studies................................... .I. Obradovic
233
How to Select Governor Parameters with Analog Computers ............................ .
...... ..... .................................... ............ E. C. Koenig and W. C. Shultz 237
COMPUTER TECHNIQUES in HyDROLOGy...................... ...........................
Flood Routing by Admittances...
..................................... H. M. Paynter
239
240
ANALOG SOLUTION of THERMAL PROBLEMS.........................
246
Freezing and Thawing of SOils .................... H. P. Aldrich. Jr., anper.tors, A New Method of
Ana'yzin. tht"' TruncAtion f"o, in the Finit~
Represent.tion Difference of, R. Vichrwveuky ... Mar.
190
'~do· ••ndom Noi~ Genero1tor, A Hybrid
390
229
ANto1,Oi1it.1. R. L T. H.mpron. , ............ Mar.
Tfilnsistors in Curr~t-Arylo. Computinl.
t. P. Kefloot. . ..................... ,..... .. May
Trunation Error in the Finite Itepresentlltion
Difference of P.rtl.' t)iff~ti.1 Oper.tors, A New
Method of Ana'yzinl the. R. Vichnfovets'y ...... . Mi:r.
119
339
190
SIMULATION
Figure ll-Index to Vol. 4 SIMULATION, June, 1965
computers and became fully integrated with the analog
computer instead of being a separate device.
The largest analog computing consoles had upwards
of 200 amplifiers in them. One example is the Applied
Dynamics 256 (Figure 15) which had 256 amplifiers.
There was a movement towards more "committed"
amplifiers such as the class 0 type quarter square
multiplier with many of the largest, most sophisticated
users trending towards the class 0 resolver as well. This
meant the computer was easier to use, but it became
more expensive.
The applications of analog during the period 19601965 are more difficult to characterize since by this time
the well known industry-wide Spring and Fall Joint
Computer Conferences, which are sponsored by AFIPS,
had replaced the old National Simulation Conferences.
To help plug the information on applications gap,
a significant event occurred during the second generation, which was the launching and the publication of the
new journal SIMULATION by Simulation Councils,
Inc., under the editorship of John McLeod. The index
of articles published in Volume 4 (June, 1965) is shown
in Figure 11, as an example of the type of applications
648
Fall Joint Computer Conference, 1970
that were being done on these bigger, better and more
powerful systems. It may be remarked in passing that
even during this second generation period, indeed
throughout the history of the analog, the analog has
been used very much as it was originally used when there
was no patchboard on the analog console. This method of
use consists of committing the analog to a single
problem, of very high priority, and tieing it up full time
doing the same job over and over and over again, as
exemplified by the.typical hardware or man-in-the-Ioop
simulator. Very often when the project that required the
simulator was completed or nowadays we would say
cancelled, there was no further use or need for the analog
computer, since no one else had been able to get at the
machine during the "fat" days. Those analysts who had
short duration, small problems, which can be considered
to be ideal candidates for the analog computer, especially
during the development or the "model" stage of the
problem, were forced to go against their own wishes to
the, by then, widely .available large, fast, digital
computer of the 7090 class. These small, repetitive,
studies went to digital not because the machine was fast,
not because the digital was cheaper, not because it was
better, not because it was more accurate, but simply
because it was available!
THE THIRD GENERATION
The third generation has shown itself to be in
existence from roughly 196,5 to the present time, 1970.
The major hardware characteristic of this generation is
the complete transitorization of the analog computer,
for both the large scale 100 volt machine and the small
scale 10 volt machine. A new scale machine evolved in
between these two extremes, called the medium scale.
A major hardware feature is the integral design of
digital logic as part and parcel of most analog consoles,
~
1962
1964
Typical Computer
231R (EAI)
recorder now compatible with accuracy and re-
continued
peatability of computer.
231RV (EAI
Electronic mode control of integrators, time-
Beckman
More useful bandwidth.
scale selection (6 decades) via push buttons,
more accurate multipliers and sinusoid generators.
Digital logic control capability - for
the first time analog has a full 10KC bandwidth
in all components, Variable breakpoint and polarity, card-programmed function generators.
This allows instant set-up of DFGs (takes only
one hour to turn around a problem). (Mostly
pot set t ings time.)
!!!!:
Typical Computer
1951
ClOO (Reeves)
1966
Ci-5000
ADI-4
analog cOlllputer - all gates (reset, hold, operate,
duction .of removable patchboard.
EAI 8800
are electronic) bandwidth up to and beyond 100 KC,
EAl 680
1954
3lR (EAJ)
20 amplifier computer, expandable to 60; more
l3lR (EAJ)
C400 (Reeves)
reliability e.timated as 60,000 hours KrBF for
_plif1ers vs. 5,000 hours measured on 231R-V.
accurate servo multipliers; integrated slaving
1956
Fully tranSistorized, more accurate, more reliable
20 amplifier computer; servo multipliers intro-
system; .01% capacitors; .01% resistors, both
C_puters can have 300-400 a ..pl1fier. in one
temperature controlled.
console.
Analog directly controllable by .... 11
digHal c_puter.
Integrated readout; human engineered for faster,
hybrid co.putation.
easier programmer use; electronic time division
Easy ... ting with digital for
Self-contained patchboard _
digHal logic (much, IlUch larger than in 23IR-V).
multipliers; mechanical digital voltmeter; tube
Card-set DFGs progr_ble from a standard IBM
diode function generators.
card.
1959
231R (EAJ)
100 amplifier computer; modular concept patchboard;
significant improvements in amplifier bandwidths
providing faster response and switching
ti~es;
compressed time capability (some jobs can be run
~
Typical Computer
1968 to
ADl - Various
Digital pots for microsecond (electronic gate)
Present
EAI - Various
setup - or millisecond (reed relay setup),
as fast as 10:1 real time instead of all at real
large scale use of MDACs in hybrid interface,
time); faster potentiometer readout; electronic
software developed for autaaatic setup and
digital voltmeter; solid state diodes in function
checkout of hybrid analog computers.
Direct
generator; repetitive operation capability.
digital/analog function generator (more accurate
1962
Improved
More accurate 1/4 square multiplier; electronic
than card set diode function generator) com-
231R (EAI)
sinusoidal generator; point storage via trans is-
pletely controllable from digital computer.
tor circuit; card-set function generators; Mark 200
Figure 12-History of analog computer evolution since 1951
Analog/Hybrid
649
Figure 14-Digital expansion system by EAI (allows parallel
patchable digital logic expansion to 10 volt systems, in a
.
self-contained desk top frame
Figure 13-231R computer, courtesy Electronic Associates, Inc.
small and large, which has certainly made pure analog
computation, if we include this digital logic, more
powerful than it has ever been. Another hardware
feature is the complete flexibility of the multi-time scale
integration capability of the analog, wherein one can
have a choice of fast, slow or in-between speeds of
solution as well as the flexibility of using any integrating
capacitor as an integrator gain. The most versatile
machines have. a choice of 6 capacitors, giving the
programmer a five-decade range of integrator gains or
time scales. Examples of this class of computer are the
Applied Dynamics AD/4 (Figure 16), the Electronic
Associates, Inc. 8800 (Figure 17) .and the Comcor
Ci-5000 (Figure 18). Note the two patchboards in each,
one for digital logic, and one for analog components.
This· period also saw a more intimate ·tie-in of the
analog computer with a digital computer due to the
development of such true hybrid devices as the lVIDAC
(multiplying D/A) and the "digital attenuator" or
"digital potentiometer." So widely accepted has the
hybrid aspect of analog computation become that it
appears that close to half of the larger consoles that are
being sold at the present time are going into hybrid
systems. This in turn has led to the need, and the
development of software specifically designed to aid the
hybrid programmer and operator. The large systems
have grown larger and larger and now are truly prodigious, consisting of 300, 400, even 500 amplifiers in a
Figure 15-Applied Dynamics large scale 256 amplifier computer
650
Fall Joint Computer Conference, 1970
Figure 16-Applied Dynamics AD /4 analog computer
single console. At the low end of the scale, the 10 volt
desk-top computers have grown larger and larger until
they are no longer desk-top and now are fully grown
consoles consisting of several hundred amplifiers, as
exemplified by the EAI 680 computer shown in
Figure 19.
The solid state revolution, which only overtook
analog in the third generation has led to the concept of
the class 0 type component or "blackbox" use of the
analog components to help minimize patching and to
make it easier for the more casual user of the machine to
program, patch, and obtain solutions by himself.
Another reason for this trend is that the solid state
amplifiers are obviously less costly and more reliable
than their vacuum tube predecessors. Analog speeds of
solution which could be too fast to be absorbed by
hUrhans, or recorded by devices, even back in the early
50's, are even faster. Present day bandwidth ranges
from a minimum of 100 KHz to over 1 MHz. Some of
the other important equipment improvements are
quarter square multiplier accuracy of close to 0.01
percent and arbitrary function generation performed by
a true hybrid device, the digitally controlled function
generator (DCFG), which eliminates >spurious·· drifts,
non-repeatability;, and difficulty in setup of the old
diode function generator. These, together with the new
digital potentiometer, a good hybrid interface with good
software, and a well integrated system design, make it
theoretically possible to setup and checkout an analog
computer in a few seconcls.
Some persons have been lmown to state the opinion
that an analog computer of today is not much different
than one of 10 years ago. A reading of this paper should
dispel such a notion. To make clear the advances that
have been made in the analog field, from post W orId
War II to the present time, I have summarized in
Figure 12 the major hardware improvements by year
of general availability showing the typical computers
incorporating the named improvements. It is obvious
that these improvements have come at more frequent
intervals than analog computer generations as I have
defined them, and shows that major improvements have
come along in the analog field at an average spacing of
about 23-1 years. This interval of time is, interestingly
enough, approximately equal to the half-life of a
"generation" of analog computers. This fact might lead
to the conclusion that one generation of computers
cannot survive (or absorb) two sets of major hardware
improvements, but that the manufacturers have been
reasonably successful in extending the life of a generation
of their computers through .at least one significant
hardware evolution. Perhaps it is the ability to extend
the life of a "generation" of analog computers, because
of the nature of the organization of analog computers
(parallel building blocks) which has led to the inaccurate
observation that "analog computers of today are not
much differen.t than they were 5 or 10 years ago."
ANALOG/HYBRID TODAY
We have now come to the point in analog/hybrid
developments where not only do we have more raw
computing speed than it is possible to take full advantage of, for solutions, but we also have more speed
in terms of setup and checkout than we have customers
Figure 17-680 lOV computer with display wing
Analog/Hybrid
who understand this type of computation. Or to put it
another way, we've reached the stage in evolution where
we can get a customer on, get his answers for him, and
get him off, far faster than is justifiable based on the fact
that we have a highly serial, slow input, mainly the
input from a single man, to a very fast parallel console.
We have almost reached the stage, as a matter of fact,
where the slow recorders on the outputs from the analog
are one of the limiting output factors. We've reached
the point where we can make many, many solutions in
a very short time. In other words, we are production
oriented in terms of solution speed. At the same time,
we have retained all of our man-machine interactive
capabilities which everyone says is desirable in the
engineering use of computers, but which obviously work
against production. In fact, production capabilities are
so great that I have estimated that for every hour of
production running on our modern hybrid systems, the
amount of post run data reduction of the results by a
large fast, stand alone digital computer operating in a
batch mode would be at least two and possibly as high
as five hours depending on how much analysis is
desired, or more realistically, how much the project can
afford.
The application of hybrid equipment is still heavily
oriented toward the aerospace-defense industry where
most of the large systems are installed. The chemical
process industries have maintained some interest in
these systems over the years, but not at an increasing
rate. The education field has interest in the small and
medium size systems. Nuclear and power technology
have shown signs of increasing awareness of the
':lap ability of hybrid systems for their highly complex
Figure 18-Comcor Ci-5000 analog computer
651
Figure 19-8800 100V transitorized computer with display wing
design, control, and training studies. Other popular
applications are as an on-line testing device, such as
measuring the amount of pollutants in an automobile
engine exhaust (Reference 6); measuring the roundness
of tires
(Reference 7) in acting as an on-line predictor or
/
ad;iptor-controller for a wide variety of processes
(Reference 8), and for helping to control the quality of
s~el (Reference 9).
, So what is the hybrid/analog system of today? It is a
highly efficient fast production device when the user or
man is not allowed to intervene and interfere with its
operation. This is in direct contradiction to its other
main feature, that is, its ease of man-machine communication which almost cries out for man's intervention.
I would say that the analog/hybrid computer exhibits
schizophrenic characteristics which may explain why
not too many people understand it. It is almost
impossible for a device to be responsive to man's
intervention and at the same time to be highly productive. At leaSt not the way the hybrid systems are
configured today. It is this paradox that limits the
expansion of· the analog/hybrid field.
The analog hardware today is far more reliable than
its early beginnings. The MTBF for a transistorized
amplifier is somewhere between 30,000 hours and
60,000 hours. The high quality, chopperless amplifier, a
recent development, brings us back, almost full circle to
the point where we were with the very first analog
amplifiers, that is, a chopperless, unstabilized amplifier
with a virtually instantaneous overload recovery. This
is a feature that all users will appreciate. However, it has
taken 2.5 to 30 years, an electronic revolution, and 3 or 4
generations of computers to eliminate the drift and
652
Fall Joint Computer Conference, 1970
unreliability of the first unstabilized amplifiers, while
retaining the desirable features of simplicity and quick
overload recovery.
The future
The analog/hybrid computer could become more
widespread in its use and acceptance by industry if it
can eliminate its schizophrenia and solve its paradox.
Hardware a;nd software ideas have been mentioned for
doing just this, such as an automatically patched analog
computer (Reference 10), coupled with a high level
language for programming the machine in user oriented
language, such as APSE and APACHE, all of which is
made highly accessible and productive with many
interactive graphics terminals (Reference 11) controlled
and hybridized by one of those next generation, fast,
cheap, can-do-anything digital computers that I keep
hearing about.
At the very least, it will continue to be used in those
on-line experiments, those teaching-learning situations,
those high frequency problems, that saturate large
digitals, and by those specialists who are addicted to
analog, as it has been used in the past.
REFERENCES
1 J ROEDEL
An introduction to analog computers
From A Palimpsest on the Electronic Analog Art ed by
H M Paynter first printed by George A Philbrick
Researchers Inc 1955 pp 27-47
2 M CONNELLY 0 FEDOROFF
A demonstration hybrid computer for real-time flight
simulation
February 1965 Report ESL-FR-218 Contract AF
33(616)-8363 MIT Cambridge 39 Mass
3 Project Cyclone-Symposium I, Reeves Instrument Corp
under contract with the Special Devices Center of the
Department of the Navy March 1951
4 Project Cyclone-Symposium II Reeves Instrument Corp
(Part II) under contract with the Special Devices Center
of the Department of the Navy April 1952
5 Project Typhoon-Symposium III on Simulation and
Computing Techniques Bureau of Aeronautics and US
Naval Air Development Center October 1953
6 J P LANDAUER
Hybrid computer real-time data processing for engine testing
Electronic Associates Inc Market Development Report
17.:.70
7 J T MAGUIRE A J SCHNABOLK
Sorting out the tires
ELECTRONICS March 18 1968
8 P ADAMS A SCHOOLEY
Adaptive-predictive control of a batch reactor
EAI applications Reference Library #6.2.2/a
9 H J HENN J D SCHIMKETS T G JOHN
Development and operation of a refining control system for
stainless steels
ASME Electric Furnace Conference Detroit Mich
December 1969
10 G HANNAUER
Automatic patching for analog and hybrid computers
SIMULATION Vol 12 #5 May 1969 pp 219-232
11 R M HOWE R A MORAN
Time sharing of hybrid computers using electronic patching
Proc of 1970 Summer Computer Sim Conf Vol 1 pp 124-133
12 Proc of Combined Analog/Digital Computer Systems
Symposium sponsored by SCi and General Electric Company
December 1960 Available from SARE
The hologram tablet-A new
graphic input device
by lVIITSUHITO SAKAGUCHI and NOBUO NISHIDA
Nippon Electric Company, Ltd.
Kawasaki, Japan
INTRODUCTION
Immediate generation of encoded binary signal
without complicated electronic means, which is achieved
by use of holography, is the most important merit of
the hologram tablet. This leads to the realization of
high speed, high resolution, compact size and. low
price.
In the prototype device, the tracing speed 104
positions per second and the resolution 2 lines/mm
were obtained.
Graphic data tablets are input devices which digitize
coordinate positions of topological patterns.
The graphic data tablet is a powerful tool with
respect to applications of man-machine communications:
1. Terminal for Computer Aided Instruction. The
graphic data tablet plays a role as a selector of
an item from an array of items which are
displayed on a screen or printed on a paper,
or as a highly versatile programmable keyboard.
2. Terminal for Data Communications requesting
information guidance or information retrieval
by hand-written characters.
3. Input terminal of pictorial informations for a
graphic manipulation such as Computer Aided
Design of integrated circuits.
Principle of the hologram tablet
Holography 3 is a two-step imaging process. One
step is the recording of wavefronts of coherent light
beam spatially modulated by an object in the form
of interference pattern with a reference light beam,
and the other is the reconstructing of the object
image by illuminating the interference pattern (hologram) with a coherent beam. Hologram tablet was
achieved by introducing a new function to hologram
For the sake of applications, the graphic data
tablet should satisfy the following conditions.
1. Simple and easy to handle.
2. Compact size and light weight.
3. Easy to interface or connect to the associated
computers.
4. Low price.
Conventional devices such as the RAND tablet!
and the sylvania data tablet2 do not seem to satisfy
conditions (2) and (4), because they emp16Y different
hardwares for quantizing the coordinates and encoding
the positions.
Hologram tablet, shown in Figure 1, provides a
new graphic input device in which the quantizing
function and the encoding function are carried out in a
single hologram plate which contains a two-dimensional
array of small holograms recording the encoded position
signals.
Figure l-Prototype device of the hologram tablet in operation
653
654
Fall Joint Computer Conference, 1970
HOLOGRAM PLATE
PENCIL OF LASER BEAM
ZERO ORDER DIFFRACTION BEAM
should have an area wide enough always to receive
the reconstructed image beam whose position might
undergo random fluctuation due to that of the incident beam direction and aberrations of hologram
plate. In ideal conditions the photodetector diameter
Dp is given by
where
LENS
Figure 2-Schematic diagram of the hologram tablet
memory4,5 in which small holograms of memory
plane contain arbitrary informations. The location
of a small hologram in the hologram memory is an
area of "temporary residence" recording information.
In a hologram tablet the location of a small hologram expresses the decoded signal of the position
information recorded in the small hologram. The
location of a small hologram and the information
in a small hologram are connected each other by
logical functions. Thus the area of a small hologram
in the hologram tablet is considered to carry out the
quantization or the smoothing of input patterns
drawn by stylus.
Figure 2 shows the principle of hologram tablet.
The hologram tablet consists of a hologram plate
containing small holograms recording the binarycoded position informations, a stylus emitting a pencil
of laser beam and photodetectors to receive the laser
beams diffracted from each of the small holograms.
When the stylus moves on the hologram plate, the
pencil of laser beam illuminates the small hologram
just below the stylus and generates the first order
diffraction beams expressing the binary-coded signals
of coordinates X and Y indicated by the stylus, which
are detected by photodetectors. The output.s from
the photodetectors are fed to computer memories.
Since the zero order diffraction beam traces the
movements of the stylus, it is possible to take a hard
copy 'of the trace of the input pattern on the photosensitive paper behind the hologram plate, or access
simultaneously several hologram plates aligned in
cascade.
If there are 2n X 2m small holograms, then the
position-code consists of (n+m) bits.' Thus (n+m)
photodetectors should be prepared.
Size of hologram plate and that of small hologram
are determined by the dimensions of input patterns
arid the quantization size,' respectively. The diameter
of the pencil of laser beam should be small enough to
smooth the meaningless movement of the stylus such
as tremors in the small hologram. Each photodetector
DH = 2S HW H ,
DH = small hologram diameter,
F = distance from the hologram plate to the
reconstructed image position,
A
= wavelength,
SH = smoothing factor of the small hologram,
SD = safety factor for the photodetector,
W H = beam waist of the pencil of laser beam.
Dp should be greater than 3.2 mmet> for the values
utilized for the prototype device described below, and
WRITING SURFACE
HOLOGRAM
PLATE
MONITOR'
OUTPUT
INTERFACE
Figure 3-System block diagram of the prototype device, "G"
indicates a gate circuit.
The Hologram Tablet
DH = 0.5 mm, F = 200 mm, A = 0.6328 Jotm, SH = 2,
and SD = 5.
Data input rate is restricted only by photodetector
and amplifier response.
I
655
M.n
System description
A prototype hologram tablet was constructed in
order to confirm the expected performance, particularly the accuracy of the code-generation and easy
handling.
The accuracy of the code-generation is determined by
1. Overlap of position-coding masks at the time
of constructing the hologram plate.
2. Uniformity of the reconstructed image intensity
over all of the small holograms in hologram
plate.
3. Fluctuation of the reconstructed image beams
on photodetector surfaces.
Handling of hologram tablet is affected by the
smoothness of· the movement of stylus link and the
flexibility of the optical guide guiding the pencil of
laser beam.
Figure 3 shows the system block diagram of a hologram tablet. The pencil of laser beam emitted from
the light pen should be held normal to the hologram
plate in order to let the reconstructed image beams
fall correctly on the appropriate photodetectors. On
the other hand the stylus combined with a ball-point
pen to take hard copies of input patterns on the writing
surface is required to be movable freely and easily.
The ball-point pen and the light pen were connected
tandem by a pantograph link in order to carry out
the same movement with respect to the coordinates
X and Y. The touch of the ball-point pen onto the
writing surface was detected by a microswitch installed
at the top of the pen point, and the signal from pentouch detection circuit was used for the on-off control
of the brightness of the monitor CRT. The laser
beam with a spot size of 0.25 mme/> was guided from a
compact He-Ne gas laser (size 300 mm x 50 mme/>,
output 2 mW) to the light pen containing an optical
guide.
The bleached hologram plate contained 64 x 64 small
holograms (each small hologram 0.5 x 0.5 mm2) , in
each two pairs· of the Gray code of six bits and one
sign bit were recorded. Each of the Gray codes of six
bits indicated the coordinates X and Y of the small
hologram in hologram plate. Thirteen solar cells
(size 5 x 5 mm2) were placed at each of the reconstructed image positions (intervals 6;2 mm). Twelve
Figure 4-Photodetector and Amplifier circuit
of the solar cells were used to receive the Gray coded
image beams corresponding to the coordinates X
and Y. Inspection of encoding operation was carried
out by detecting the diffraction intensity of the sign
bit by the thirteenth solar cell. Output in the sign bit
controlled also the on-off of the monitor brightness.
After the photo currents from the solar cells were
amplified up to the logic level of DTL by the operational amplifier circuits shown in Figure 4, the Gray
to binary code-conversion was made in parallel. Each
bit of the binary coded signal was compared with
that of the previous signal stored in the register. When
the mismatch of a single bit was found by mIsmatch
detection circuits, the present binary coded signal
was stored into the register and a pulse of 10 JotS width
was generated to brighten the monitor. The operation
was carried out in order to check the exact change
of the Gray code and protect the screen of monitor
CRT. The binary code stored in the register was
changed into analog voltages by D-A converters and
fed to Tektronix type 601 storage CRT in order to
monitor the pen movement. Hologram plate and the
light pen are the essential components of the hologram
tablet.
Hologram plate
We have two methods to form the hologram plate,
viz., serial-recording of each small hologram, and
common-bits-recording in which each of the bits
common to· all of the small holograms is recorded
individually. We employed the latter to form hologram
plate, because the method is similar to that making
integrated circuits, and considerably economizes the
labor to make hologram plate.
A schematic diagram showing how to form hologram plate is given in Figure 5. We have employed
the method of the image hologram. 6 The thirteen
masks for the Gray code were prepared. Each of them
consisted of transparent or opaque patterns expressing
"Il! or "0", corresponding respectively to each of
the bits common to all of the small holograms.
656
Fall Joint Computer Conference, 1970
Figure 5-Schematic diagram forming the hologram plate
An imaging lens was set to form a magnified image
of a mask for the Gray code on a photographic plate.
When a collimated laser beam was used to illuminate
the mask for the Gray code, the spatially modulated
beams emerging from the mask (object beam) were
converged at the rear focal point of the imaging lens
and then imaged on the photographic plate. A plane
wave laser beam (reference beam) was made to illuminate all over the photographic plate and then interfere
with the object beam carrying the mask pattern for
the Gray code. Recordings for different masks were
made in a similar way, provided that the incident
directions of the reference beam were shifted each
time.
The reconstructed images are the replicas of the
object beams and converge on the array of the solar
cells. The distance from hologram plate to the array
of the solar cells is the same as that from the rear
focal point of the imaging lens to photographic plate.
The angular separation between the adjacent reconstructed image beams falling on the solar cells is
equal to the angular shift imposed on the reference
/Jeam at the time of recording.
Figure 6 shows the hologram plate recorded on a
Kodak 649-F plate and the Gray-coded images reconstructed from a small hologram of the hologram plate.
The overlaps of the masks for the Gray code were
achieved with an error less than ±0.05 mm. The
hologram plate of higher resolution will be formed by
utilizing the ability of holography to achieve high bit
densities with a great spatial redundancy and lenslike nature. The transmittivity of the hologram plate
was about 80 percent. The diffraction efficiency better
than 0.1 percent was obtained for each reconstructed
image.
Figure 6-Hologram plate and reconstructed images
lens and a prism. We call it SELFOC light pen. SELFoe is a lens-like optical guide of glass fiber with a
parabolic distribution of refractive indices. SELFOC
has the following advantages as compared with a
clad type optical fiber.
1. Laser beam transmission without band-limitation and waveform distortion.
2. Low-loss transmission and conservation of
polarization plane of incident beam.
LENS
LASER BEAM
Light pen
Figure 7 shows the construction of the light pen. It
consists of a light focusing glass fiber named SELFOC, 7
---r::=:::::::::::~
Figure 7-Construction of the SELFOC light pen
The Hologram Tablet
657
3. Realization of a lens with tiny aperture and
that with an ultrashort focal length.
4. Increased flexibility due to a small diameter.
The refractive index n of the fiber in the radial
direction is given by n = noCl-ar2/2), where no, r,
and a are refractive index on the optic axis, distance
from optic axis, and a constant, respectively.
At present SELFOC optical fibers with diameters
from 50 JLm to a few mm are available. Although a
varies with fiber diameter, the difference between
the refractive index on the optic axis and that at the
periphery can be made O.l.
The SELFOC optical fiber used in the SELFOC
light pen was 50 cm long with a diameter of 0.2 mm.
The coefficient a was 0.5 mm-2, and the transmission
loss was less than 0.3 dB/m. The mode pattern of a
laser beam after passing through the SELFOC light
pen was scarcely deformed as shown in Figure 8. The
SELFOC could be bent with a radius of curvature
less than 10 cm without a noticeable deformation in
pattern. The lens. on an end of the SELFOC light pen
was used to collimate the emerging laser beam to a
spot size of 0.25 mm.
Performance
A paper placed on the writing surface provided hard
copies of input patterns written or drawn by a ballpoint pen. Movements of ball-point pen were followed
by the SELFOC light pen and were instantaneously
encoded as reconstructed images from the hologram
plate. The solar cells adequately covered the fluctuations of the reconstructed image beams caused by
jolting of the SELFOC light pen and aberrations
of the hologram plate. The signal-to-noise ratio of the
Gray-coded images on the solar cells was greater than
Figure 9-Monitored characters drawn by the stylus on the
hologram plate
7 dB, even when the hologram plate was disturbed by
dust and scratches. Since the output voltage of the
amplifiers was higher than 3 volts, it was found possible
to use a laser source with an output less than 2 mW.
Data rate was limited by the frequency response of
the solar cell and the amplifier, and was obtained up
to 104 positions per second.
Figure 9 gives an example of the monitored patterns
displayed on the storage CRT. Deviations between
the input patterns on paper and the displayed patterns
on monitor CRT were within ±0.5 mm. This is considered to be caused only by the essential disadvantage
of the Gray code.
The pantograph link and the SELFOC light pen
could be moved lightly and freely making the handling
of hologram tablet easy. Excellent stability was
confirmed for a long period of operation.
l\1ost part of the cost of a hologram tablet consists
of that of laser source and SELFOC light pen. In
the prototype device, a laser source of three hundred
dollars and a SELFOC light pen constructed at the
expense of one hundred dollars were used. However,
the price would be reduced to half by mass production.
If we consider the possibility that a hologram tablet
with a larger capacity is constructed by using only
hologram plate Cthe number of record of the masks
for the Gray code is made to be equal to the encoded
bit number), the encoded bit number of photo detectors
and amplifiers, the cost will not increase to a great
extent.
CONCLUSION
Figure 8-SELFOC light pen guiding a pencil of laser beam
It has been confirmed that the hologram tablet has
many advantages such as high data rate, high resolution, compact size and low price.
658
Fall Joint Computer Conference, 1970
These advantages have been achieved by utilizing
holographic techniques, and SELFOC. The essential
components of hologram tablet are the hologram
plate containing small holograms, each records the
Gray-coded coordinate X and Y and the SELFOC
light pen. The techniques in the hologram tablet can
be utilized several ways such as the position control
of NC and the feature extraction for pattern recognitions (using the smoothing function of small hologram
in the characterized hologram plates).
Although experiments were carried out with a
prototype hologram tablet having 64 x 64 small
holograms of 0~5 ·mm pitch, hologram tablets with
much larger capacity and higher density could be
constructed without great difficulty. The possibility
that the increase in capacity and density will not
bring a considerable rise in cost is to be found.
Experiment of graphic manipulations with the
hologram tablet connected to a computer system is
in progress.
ACKNOWLEDGMENTS
The authors wish to thank Dr. T. Uchida and Dr.
F. Saito for their helpful suggestions in this work.
REFERENCES
1 M R DAVIS T 0 ELLIS
The rand tablet: A man-machine graphical communication
device
AFIPS Conference Proceedings Fall Joint Computer
Conference Volume 26 pp 325-3311964
2 J F TEIXEIRA R P SALLEN
The sylvania data tablet: A new approach to graphic data
input
AFIPS Conference Proceedings Spring Joint Computer
Conference Volume 30 pp 315-3211968
3 E G RAMBERG'
The hologram-properties and applications
RCA rev Volume 27 pp 467-499 December 1966
4 L K ANDERSON
Holographic optical memory for bulk data storage
Bell Lab Record Volume 46 pp 318-325 November 1968
5 L F SHEW J G BLANCHARD
A binary hologram digital memory
IEEE J of QE Volume QE-5 pp 333-334 June 1969
6 G B BRANDT
Image plane holography
Applied Optics Volume 8 pp 1421-1429 July 1969
7 T UCHIDA M FURUKAWA I KITANO
K KOIZUMI H MATSUMURA
Optical characteristics of a light-jocusing fiber guide
To be published in IEEE J of QE
AMERICAN FEDERATION OF IN,FORMATION PROCESSING
SOCIETIES (AFIPS)
OFFICERS AND BOARD OF DIRECTORS OF AFIPS
V ice President
President
Dr. Richard I. Tanaka
California Computer Products, Inc.
2411 W. LaPalma Avenue
Anaheim, California 92803
Mr. Keith W. Uncapher
The RAND Corporation
1700 IVlain Street
Santa Monica, California 90406
Secretary
Treasurer
Mr. R. G. Canning
Canning Publications, Inc.
134 Escondido Avenue
Vista, California 92083
Dr. Robert W. Rector
Cognitive Systems, Inc.
319 S. Robertson Boulevard
Beverly Hills, California 90211
Executive Director
Executive Secretary
Dr. Bruce Gilchrist
AFIPS Headquarters
210 Summit Avenue
IVlontvaie, New Jersey 07645
]Vlr. H. G. Asmus
AFIPS Headquarters
210 Summit Avenue
lVlontvale, New Jersey 07645
ACM Directors
Dr. Ward Sangren
521 University Hall
2200 University Avenue
Berkeley, California
l\1r. Walter Carlson
IBl\1 Corporation
Armonk,. New York
l\1r. Donn B. Parker
Stanford Research Institute
333 Ravenswood Avenue
l\1enlo Park, California 94025
IEEE Directors
l\1r. L. C. Hobbs
Hobbs Associates, Inc.
P.O. Box 686
Corona del l\1ar, California 92625
Dr. Robert A. Kudlich
Wayland Laboratory
Raytheon Company
Boston Post Road
Wayland, l\1assachusetts 01778
Dr. Edward J. McCluskey
Department of Electrical Engineering
Stanford University
Palo Alto, California 94305
Simulation Councils Director
American Society for Information Director
l\1r. James E. Wolle
General Electric Company
l\1issile & Space Division
P.O. Box 8555
Philadelphia, Pennsylvania 19101
Mr. Herbert Koller
ASIS
2011 Eye Street, N.W.
Washington, D.C. 20006
Association for Computation Linguistics Director
Special Libraries Association Director
Dr. Donald E. Walker
Head, Language and Text Processing
The Mitre Corporation
Bedford, Massachusetts 01730
Mr. Burton E. Lamkin
Office of Education
7th and D Streets, S.W.
Washington, D.C. 20202
Society for Information Display Director
Society for Industrial and Applied Mathematics Director
Mr. William Bethke
RADC-(EME, W. Bethke)
Griffis Air Force Base
New York, New York 13440
Dr. D. L. Thomsen, Jr.
IBl\1 Corporation
Armonk, New York 10504
A merican Institute of CPA's Director
American Statistical Association Direc;tor
Mr. Noel Zakin
l\1anager, Computer Technical Services
AICPA
666 Fifth Avenue
New York, New York 10019
Dr. l\1artin Schatzoff
Manager, Operations Research
IBM Cambridge Scientific Center
545 Technology Square
Cambridge, Massachusetts 02139
American Institute of Aeronautics and Astronautics Director
Instrument Society of A merica Director
Dr. Eugene Levin
Culler-Harrison Company
745 Ward Drive
Santa Barbara, California 93105
l\1r. Theodore J. Williams
Purdue Laboratory for Applied Industrial Control
Purdue University
Lafayette, Indiana 47907
JOINT COMPUTER CONFERENCE BOARD
Dr. Richard 1. Tanaka-President
California Computer Products, Inc.
2411 W. LaPalma Avenue
Anaheim, California 92803
l\1r. Richard B. Blue Sr.-ACl\1
1320 Victoria Avenue
Los Angeles, California
l\1r. Keith W. Uncapher-Vice President
The RAND Corporation
1700 Main Street
Santa l\1onica, California 90406
l\1r. John E. Sherman-SCI
Lockheed l\1issiles and Space Company
Org. 19-30, Building 102
P.O. Box 504
Sunnyvale, California
Dr. Robert W. Rector-Treasurer
Cognitive Systems Inc.
319 S. Robertson Blvd.
Beverly Hills, California 90211
Dr. Robert A. Kudlich-IEEE
Raytheon Co. Equipment Division
Wayland Laboratory
Boston Post Road
Wayland, l\1assachusetts 01778
JOINT COl\1PUTER CONFERENCE COlVIl\1ITTEE
Dr. A. S. Hoagland, Chairman
IBM Research Center
P.O. Box 218
Yorktown Heights, New York 10598
JOINT COl\1PUTER CONFERENCE TECHNICAL PROGRAl\1 COl\1l\/IITTEE
Mr. David Brown
Stanford Research Institute
333 Ravenswood Avenue
1\1enlo Park, California 94025
FUTURE JCC GENERAL CHAIRlV[EN
1971 SJCC
1971 FJCC
l\1r. Jack l\10shrnan
RAl\1SCO
6400 Goldboro Road
Bethesda, l\1aryland 20034
l\1r. Ralph R. Wheeler
Lockheed l\1issiles and Space Co.
Dept. 19-31, Bldg. 151
P.O. Box 504
Sunnyvale, California 94088 .
1970 FJeC STEERING COMMITTEE
General Chairman
Robert A. Sibley, Jr.
University of Houston
Vice Chairman
Eugene H. Brock
NASA-MSC
Technical Program
Larry E. Axsom-Chairman
IBM Scientific Center
Eugene Davis-Vice Chairman
NASA-MSC
Special Activities
Joe B. Wyatt-Chairman
University of Houston
R. A. Westerhouse-Vice Chairman
Computer Complex
Registration
Ed Mulvaney-Chairman
Control Data Corporation
Larry Byrne-Vice Chairman
l\1ilchem, Inc.
Publications
Treasurer
Geary Eppley
Agency Records Control, Inc.
Don L. Carmichael-Assistant
Peat, Marwick, Mitchell & Co.
Secretary
Irma J. Morgan
Phil co Ford Corporation
Local Arrangements
James N. Gay-Chairman
Hybrid Systems, Inc.
E. H. Hartung-Vice Chairman
Gulf Oil Corporation
R. S. Woodruff-Chairman
Lockheed Electronics Co.
Jury Lewisky-Vice Chairman
Lockheed Electronics Co.
Exhibits
F. J. Kirkpatrick-Chairman
Infotronics, Inc.
Robert J. Mobilia-eVice Chairman
Honeywell Computer Control
SCi Representative
J ames Van Artsdalen
NASA-MSC
Local A rrangements Coordinator
Howard E. Reddy
Pace l\1anagement Corporation
A CM Representative
l\IL Stuart Lynn
IBl\1 Scientific Center
Public Relations
John Wilson-Chairman
The Phillips Agency
Larry Goldman-Vice Chairman
Thomas J. Tierney and Associates
IEEE Representative
Curt F. Fey
Xerox Data Systems
SESSION CHAIRMAN, PANELISTS AND REVIEWERS
SESSION CHAIRMEN
Ed Battiste
J. D. Baum
Willard Bouricius
Marc Connelly
James R. Deline
Dan Drew
E. A. Feustel
Karl Heinrichs
R. A. Kaenel
A.!, Katz
Billy V. Koen
Robert Korfhage
Lenord Litman
Michael A. Melkanoff
Rudolph Motard
R. R. l\l[untz
Dick Nance
C. V. Ramamoorthy
James L. Raney
S. Rosen
Art 1. Rubin
Sally Sedelow
C. Ray Wallace
Richard Watson
REVIEWERS
R. P. Abbott
C. T. Abraham
R. M. Aiken
G. Albers
R. M. Alden
R. P. Allen
P. Altherton
E. B. Altman
L. K. Anderson
T. C. Anderson
F. Anzelmo
A. Arakawa
1\1. Arbab
P. Armer
G. N. Arnovick
W. L. Ash
M. M. Astrahan
D. C. Augustin
J. D. Aron
H. L. Babin
G. F. Badger, Jr.
J. A. Baker
D. L. Ball
N. A. Ball
1\/[. Ballot
A. E. Barlmv
B. B. Barnes
B. H. Barnes
R. M. Barnett
1\1. N. Bartakke
.T. Bartlett
F. Bates
R. V. Bayles
.T. A. Bayless
G. A. Bekey
1\/[. J. Beniston
R. Bennett
P. T. Berning
1\1. I. Bernstein
W. P. Bethke
D. Bjorner
D. V. Black
J. A. Bloomfield
D. Bobrow
G. Boer
1V1. .T. Bodoia
G. R. Bolton
H. Borko
G. H. Born
E. Bosch
H. Bratman
B. Brawn
R. L. Brening
R. D. Brennan
N. D. Brewer
J. D. Brooks
B. W. Brown
D. C. Brown
J. R. Brmvn, Jr.
K. Brown
G. E. Bryan
C. A. Caceres
M. A. Calhoun
E. D. Callender
T. W. Calvert
A. V. Campi
R. H. Canaday
D. G. Cantor
D. W. Cardwell
R. B. Carlson
R. L. Carmichael
C. C. Carroll
W. C. Carter
L. J. Chaitin
J. 1\1. Chambers
R. C. Cheek
.T. Chernak
B. F. Cheyoleur
C. K. Chow
W. F. Chow
W.Chu
E. H. Clamons
D. Climenson
L. J. Clingman
A. Clymer
E. G. Coffman
D. Cohen
W. L. Colby
L. S. Coles
A. J. CoIl meyer
S. Condon
M. M. Conners
R. L. Constable
R. Constant
A. E. Corduan
W. A. Cornell
1. W. Cotton
R. Crandall
D. E. Crawford
B. Creasy
A. J. Critchlow
H. A. Crosby
J. D. Crunkleton
N. Cserhalmi
C. Csuri
A. G. Dale
J. A. Daly
D. A. Darms
C. M. Davis
R. J. P. DeFigueredo
P. De Jong
P. B. Denes
P. J. Denning
J. E. Dennis, Jr.
H. Denslow
E. Desautels
J. Dierman
H. Dinter
D. L. Dittberner
G. G. Dodd
T. L. Drake
R. C. Dubes
J. C. Duffendack
M. A. Duggan
A. I. Durney
T. J. Dylewski
L. D. Earnest
L. B. Edwin
H. S. Ed Tsou
R. F. Elfant
W. J. Erikson
E. R. Estes
S. E. Estes
C. C. Farrington
G. A. Fedde
E. A .. Feustel
F. Field
M. SJ Field
R. T. Filep
O. Firschein
R. V. Fitzgerald
J. L. Flanagan
J. E. Foster
F. H. Fowler, Jr.
1V1. R. Fox
C. V. Freiman
P. J. Friedl
J. Friedman
L. M: Fulton
A. Futterweit
R. L. Gamblin
R. M. Gardner
G. E. Gareis
1V1. M. Gold
D. G. Gordon
D. F. Gorman
J. A. Gosden
M. H. Gotterer
E. M. Greenawalt
H. D. Greif
D. Gries
D. W. Grissinger
A. Guzman
T. G. Hagan
1\1. J. Haims
J. E. S. Hale
W. J. Hale
M. Halpern
M. H. Halstead
C. Hammer
M. Hanan
F. M. Haney
A. G. Hanlon
D. R. Haring
J. O. Harrison, Jr.
R. D. Hartwick
A. Hassitt
K. E. Haughton
J. F. Heafner
M. F. Heilweil
W. A. Helbig
P. J. Hermann
B. Herzog
G. E. Heyliger
J. H. Hiestand
A. N. Higgins
R. H. Hill
J. H. Hinrichs
A. D. C. Holden
G. L. Hollander
D. W. Holmes
R. L. Hooper
J. A. Howard
D. K. Hsiao
B. Huberman
T. A. Humphrey
E. Hunt
P. J. Hurley
M. R. Irwin
R. A. Ito
L. Jacobs
E. A. Jacoby
L. F. Jarzomb
R. E. Jeffries
B. Johnson
W. L. Johnson
E. R. Jones
N. D. Jones
E. C. Joseph
J. R. Jump
P. Kadakia
R. Y. Kain
V. A. Kaiser
M. J. Kaitz
J. F. Kalbach
E. Katell
S. M. Keathley
C. H. Kellogg
D. S. Kerr
R. E. King
E. S. Kinney
L. Kleinrock
A. Klinger
K. E. Knight
P. Knowlton
M. Kochen
H. R. Koen
E. C. Koenig
J. S. Koford
A. Kolk, Jr.
H. G. Kolsky
J. Kopf
P. R. Kosinski
L. D. Kovach
J. H. Kuney
J. Kurtzberg
A. Kusahara
K. C. Kwan
D. Laiti
B. W. Lampson
R. C. Larkin
D. J. Lasser
E. G. Lean
R. C. T. Lee
W. T. Lee
M. Lehman
J. Lennie
A. S. Lett
J. M. Lewallen
W. E. Lewis
W. W. Lichtenberger
H. P. Lie
C. R. Lindholm
R. Linebarger
T. P. Linville
H. Lipton
H. Liu
K. M. Lochner, Jr.
E. S. Loebenstein
R. D. Lohman
H. A. Long
R. G. Loomis
D. L. Magill
W. Main
C. M. Malone
R. L. Mandell
1\1. Marcotty
I. Marshall
W. L. Martin
R. L. Mattison
R. Mattson
H. E. Maurer
L. H. Maxson
C. H. Mays
M. E. McCoy
R. McDowell
F. W. McFarlan
J. L. McKenney
P. T. McKiernan
R. S. 1\1cKnight
J. McLeod
M. W. McMurran
L. P. McNamee
M. Meicler
1\1. A. 1\1elkanoff
H. W. l\1ergler
J. C. 1\1ichener
B. J. 1\1ichielsen
W. F. 1\1iller
H. D. l\1ills
J. ),Iinker
B. A. lHitchell
E. E. L. 1\1itchell
B. l\1ittman
J. O. l\10hn
1\1. l\10ntalbano
1\1. F. l\tloon
C. G. 1\100re
D. W. 1\100re
R. Ie 1\100re
R. A. Moran
H. L. Morgan
L. W. 1\10rrison
l\1. S. S. 1\10rton
G. J. 1\10shos
J. H. Munson
J. K. l\1unson
A. W. 1\1uoio
,J. J. l\,lurphy
D. M. 1\1urray
F. W. 1\1urray
R. P. Myers
J. A. Narud
N. W. Naugle
G. W. Nelson
R. A. Nesbit
P. G. Neumann
F. Newman
W. M. Newman
C. B. Newport
R. V. Niedrauer
R. N. Nilsen
N. J. Nilsson
N. Nisenoff
J. D. Noe
D. L. Noles
W. A. Notz
J. A. O'Brien
P. L. Odell
K. O'Flaherty
W. J. B. Oldham, Jr.
1\1. J. O'Malley
J. T. O'Neil, Jr.
L. S. Onyshkevych
C.Opaskar
G. Oppenheimer
R. H. Orenstein
D. J. Orser
E. E. Osborne
J. T. Owens
D. R. Paden
C. V. Page
J. J. Pariser
J. Pearl
T. F. Penderghast
L. H. Peterson
J. K. Picciano
M. W. Pirtle
W. J. Plath
A. V. Pohm
J. H. Pomevene
J. A. Postley
A. W. Potts
R. C. Prather
R. J. Preiss
J. P. Pritchard, Jr.
J. S. Raby
M. S. Radwin
G. A. Rahe
C. V. Ramamoorthy
L. C. Ray
1. Remson
W. T. Rhodes
P. A. Richmond
F. C. Rieman
E. J. Roberts
R. M. Rojko
J. Roseman
C. A. Rosen
J. L. Rosenfeld
R. R. Rosin
D. L. Ross
P. M. Rubin
M. Rubinoff
F. Ruffino
R. L. Russo
J. D. Sable
J. M. Salzer
P. 1. Sampath
J. L. Sanborn
W. B. Sander
L. Sashkin
P. Savage
D. Savitt
D. B. Saylors
M. W. Schellhase
W. E. Schiesser
A. J. Schneider
V. B. Schneider
J. E. Schwenker
S. Y. Sedelon
W. A. Sedelon
T. K. Seehuus
W. D. Seider
A. B. Shafritz
E. B. Shapiro
J. E. Shemer
P. C. Sherertz
J. Shih
J. S. Shipman
D. L. Shirley
S. Shohara
G. E. Short
R. L. Shuey
G. T. Shuster, Jr.
1. Shy
E. H. Sibley
L. C. Silvern
R. F. Simmons
R. M. Simons
Q. W. Sinkins
P. G. Skelly
D. R. Slutz
T. A. Smay
B. L. Smith
L. M. Spandorfer
C. F. Spitzer
F. W. Springe
T. B. Steel, Jr.
H. H. Steenbergen
J. K. Stephens
D. H. Stewart
W. A. Sturm
R. K. Summit
A. Svoboda
P. A. Szego
R. S. Taylor
R. W. Taylor
A. Tephtz
L. G. Tesler
R. E. Thoman
E. M. Thomas
M. D. Thompson
E. N. Timmreck
A. A. Toda
F. M. Tonge
G. R. Trimble, Jr.
G. H. Turner, Jr.
G. T. Uber
L. Uhr
W. R. Uttal
W. Utz
R. L. Van Tilburg
V. Vemuri
S. J. Viglione
R. Von Buelow
A. H. Vorhaus
S. Waaben
R. A. Wagner
S. E. Wahlstrom
J. V. Wait
P. D.Walker
C. J. Walter
C. Walton
G. Y. Wang
H. R. Warner
K. Wasserman
1\1:. C. Watson
C. W. Watt
A. L. Weihrer
B. Weinberg
M. N. Weindling
L. H. Weiner
C. Weissman
R. R. Wheeler
G. Wiederhold
R. L. 'Wigington
R. C. Wilborn
L. C. Wilcox
M. Wild mann
D. A. Willard
T. G. Williams
T. J. Williams
A. N. Wilson
C. A. Wilson
D. E. Winer
H. Wishner
R. P. Wishner
E. W. Wolf
J. E. Wolle
R. C. Wood
F. Worth
J. H. Worthington
J. H. Wright
K. R. Wright
S. L. Wright
R. E. Wyllys
J. C. Wyman
J. W. Young
L. S. Young
D. C. Zatyko
N. S. Zinbel
A. S. Zukin
PANELISTS
D. Beach
U. N. Bhat
C. R. Blair
Jack Brooks
T. E. Cheatham, Jr.
S. Crocker
P. J. Denning
D. S. Diamond
A. Frederickson
B. A. Galler
N. Gorchow
H. R. J. Grosch
F. E. Heart
R. Howe
H. R. Koller
G. Korn
R. Lawrence
W. A. Leby
A. E. Lewis
S. Levine
J. Mauceri
J. Minker
H. S.McDonald
C. B. Newport
J. W. O'Byrne
J. F. Ossanna
T. C. O'Sullivan
G. Salton
J. H. Saltzer
J. E. Sammet
L. L. Selwyn
J. E. She mer
T. B. Steel, Jr.
F. N. Trapnell
D. H. Vanderbilt
V. N. Vaughan
P. Wegner
FJCC 1970 PRELIMINARY LIST OF EXHIBITORS
Addison-Wesley Publishing Company
Addmaster Corporation
Addressograph Multigraph Corporation
Advance Research, Inc.
Advanced Information Systems, Inc.
Advanced Memory Systems, Inc.
Advanced Space Age Products, Inc.
Advanced Terminals, Inc.
AFIPS Press
Airoyal lVUg. Co.
Allen-Babcock Computing, Inc.
Allied Computer Technology, Inc.
American Data Systems
American Elsevier Publishing Co., Inc.
American Regitel
American Telephone and Telegraph Co.
AJVIP Incorporated
Ampex Corp.
Anderson Jacobson, Inc.
Applied Computer Systems, Inc.
Applied Digital Data Systems, Inc.
Applied l\,fagnetics Corporation
Association for Computing Machinery
Atlantic Technology Corp.
Atron Corp.
Audio Devices, Inc.
Auerbach Info., Inc.
Auricord Div.--Scoville l\Hg., Co.
Automata Corp.
Auto-Trol Corp.
Beehive l\,fedical Electronics Inc.
The Bendix Corporation
BIT, Inc.
Boeing Computer Services
Boole & Babbage, Inc.
Bridge Data Products, Inc.
Brogan Associates, Inc.
Bryant Computer Products
Bucode, Inc.
The Bunker-Ramo Corporation
Business Press International, Inc. (Information Week)
California Computer Products, Inc.
Call-A-Computer, Inc.
Cambridge l\'Iemories, Inc.
Canadian Government Exhibition Commission
Centronics Data Computer Corp.
Century Data Systems, Inc.
Cincinnati l\1ilacron, Inc.
Clare-Pendar Company
Codex Corp.
Cogar Corp.
Collins Radio Company
Colorado Instruments Inc.
ComData Corporation
Communitype Corporation
Compat Corp.
CompuCord, Inc.
Computek, Inc.
Computer Automation, Inc.
Computer Communications, Inc.
Computer Complex, Inc.
Computer Design Publishing Corp.
Computer Devices, Inc.
Computer Micro-Image Systems, Inc.
Computer Sciences Corporation
Computer Synetics, Inc.
Computer Terminal Corporation
Computer Terminals of Minnesota
Computer Transmission Corporation
Computerworld
Comress
Consultants Associated, Inc.
Control Data Corporation
Control Devices, Inc.
Courier Terminal Systems, Inc.
CSPI (Computer Signal Processors, Inc.)
Daedalus Computer Products, Inc.
Data 100 Corporation
Data Card Corporation
Data Computer Systems, Inc.
Data General Corp.
Dataline Inc.
Datamate Computer Systems, Inc.
Datamation
Datapac Incorporat~d
Data Printer Corp.
Data Processing Magazine (North American Pub. Co.)
Data Product News
Data Products Corporation
Dataram Corporation
Data Systems News/Newstape
Datatype Corp.
Datawest Corporation
Datotek, Inc.
Delta Data Systems Corporation
Diablo Systems, Incorporated
A. B. Dick Company
DID, Data Input Devices, Inc.
Digi-Data Corporation
Digital Equipment Corporation
Digital Information Devices, Inc.
Digital Information Systems Corp.
Digital Resources Corp. Hybrid Systems Div.
Digital Scientific Corporation
Digitronics Corporation
Dresser Systems, Inc.
Dylaflo Business Machines Corp.
Eastman Kodak
EDP News Service
Edutronics Systems, International Inc.
Eldorado Electrodata Corp.
Electronic Arrays, Inc. (Systems Div)
Electronic Arrays, Inc. (Components Div)
Electronic Laboratries, Inc.
Electronic Memories & Magnetics
Electronic News-Fairchild Pubs.
Engineered Data Peripherals Corp.
Fabri-Tek, Inc. (Memory Products Div)
Facit-Odhner, Inc.
Ford Industries, Inc.
Four-Phase Systems, Inc.
General Electric Company (Bull Corp)
General Electric Company (Scotia)
General Instrument Corporation
General Kinetics Incorporated
Genisco Technology Corporation
The Gerber Scientific Instrument Co.
Gould Inc., Graphics Div.
GRI Computer Corp.
Hayden Publishing Company, Inc.
Hazeltine Corp.
Hetra, Inc.
Hewlett-Packard
Hitachi America, Ltd.
Hi-Tek Corp. (Electronics Div)
Honeywell Computer Control Div.
Honeywell-EDP
Houston Instrument
Howard Industries
IBM Corporation
IDAK Corporation
IEEE Computer Group
IER Corp.
Image Systems, Inc.
Incoterm Corporation
Inforex, Inc.
Information Data Systems, Inc.
Information Displays, Inc.
Information International, Inc.
Information Storage Systems, Inc.
Infotronics Corp.
Interactive Info Systems, Inc.
Interdata
International Computer Products, Inc.
International Computers Ltd.
International Data Corp.
Kennedy Company
Keymatic Data Systems Corp.
Kongsberg Systems, Inc.
Kybe Corporation
Lenkurt Electric
Licon Div. Illinois Tool Works, Inc ..
Lipps., Inc.
OEM Products, Automated Business Systems Div.
Litton Industries
Litton DATALOG Div.
Lockheed Electronics, Data Products Div.
Logicon, Inc.
Lundy Electronics & Systems, Inc.
M&M Computer Industries, Inc.
The Macmillan Company
Magnusonic Devices, Inc.
MAl Equipment Corp.
Marshall Data Systems, Div. of Marshall Ind.
MCI
Memorex
Memory Systems, Inc.
Memory Technology, Inc.
Microform Data Systems, Inc.
Micro Systems, Inc., A Microdata Subsidiary
Milgo Electronic Corp., Int'l. Communications Corp.
Mobark Instruments Corp.
Modern Data
Mohawk Data Sciences Corp.
R. A. Morgan
MSI Data
NCR
Nemonic Data Systems, Inc.
Noller Control Systems
N ortec Computer Devices, Inc.
Nortronics Company, Inc.
Novar
Nuclear Data,! Inc.
Numeridex Tape Systems, Inc.
Odec Computer Systems, Inc.
Omega-t Systems, Inc.
Omnitec Corp.
On Line Computer Corp.
Optical Memory Systems
Optel Corporation
Path Computer Equipment, Inc.
Penril Data Communications, Inc;
Peripheral Equipment Corp.
Peripheral Technology, Inc.
Periphonics Corp.
Photophysics, Inc.
Plessey Electronics Corp.
Prentice Electronics Corp.
Prentice Hall, Inc.
Princeton Electronic Products, Inc.
Quantum Science Corp.
Raytheon Computer
RCA Memory Products Div.
Realist Microform Products Div.
Recortec, Inc.
Redcor Corp.
Remex Electronics, A Div. of Ex-CelI-O Corp.
Research/Development l\1agazine
RFL Industries, Inc.
Royco Instruments, Inc.
Sagetic Corporation
Sangamo Electric Company
Science Accessories Corporation
Scientific Control Corporation
Singer Company, Friden Div.
Singer-Librascope
Singer Micrographic Systems
Singer Telesignal
S.I.N.T.R.A.
Sonex, Inc.-IjOnex Division
Spartan Books
Standard l\1emories, Inc.
Storage Technology Corporation
Sykes Datatronics
Sylvania
Syner-Data Inc.
SYS Computer Corporation
Stromberg Datagraphix, Inc.
Tally Corporation
TDK Electronics Corp.
Technical Concepts, Inc.
Tektronix, Inc.
Teletype Corporation
Telex Computer Products
Tel-Tech Corp.
Tennecomp Systems, Inc.
Texas Instruments
Timeplex, Inc.
Time Share Peripherals Corp.
Time-Zero Corporation
Tops On-Line Services, Inc.
Tracor Data Systems
Treck PhotoGraphic Inc.
Trio Laboratories, Inc.
Typagraph Corporation
Ultronic Systems Corp.
United Business Communications, Inc.
United Telecontrol
Univac, Div. of Sperry Rand Corp.
Universal Data Acquisition Co.
Universal Graphics, Inc.
Vanguard Data Systems, Inc.
Varian Data Machines
Varisystems Corporation
Vermont ReEearch Corporation
Versatec
Viatron
Video Systems Corporation
Wabash Computer Corp., PI Div.
Wang Computer Products, Inc.
Wang Laboratories, Inc.
Warner Electric
Western Union
Westinghouse Electric Corp.
John Wiley & Sons, Inc.
Xerox Corporation
Xerox Data Systems
Zeta Research, Inc.
AUTHOR INDEX
Abell, V. A., 89
Abramson, N., 281
Afifi, A. A., 609
Allan, J. J., 257
Allen, C. A., 53
Alston-Garnjost, M., 45
Andersen, S. R., 53
Barton, M. E., 1
Bavly, D. A., 417
Beckermeyer, R. L., 315
Beizer, B., 519
Berge, T. D., 377
Bjorner, D., 477
Blizard, R. B., 503
Bossen, D. C., 63
Brooks, F. P., Jr., 599
Brown, N. K., 399
Bryant, P., 287
Bussell, B., 525
Carey, B., 387
Carroll, J. M., 223
Chen, C., 69
Clancy, G. J., Jr., 581
Collmeyer, A. J., 201
Connor, C. L., 135
Copp, D. H., 287
Crawford, P. B., 515
Crockett, E. D., 287
Day, K. S., 129
Dean, A. L., Jr., 169
Dickinson, R. V., 181
Dickinson, W. E., 287
Dickson, G. W., 569
Disparte, C. P., 79
Dodds, W. R., 363
Doherty, W. J., 97
Down, N. J., 345
Elshoff, J. L., 369
Erbeck, D. H., 589
Erwin, J. D., 621
Farmer, D. E., 493
Fink, R., 45
Frandeen, J. W., 287
Freed, R. N., 143
Gates, H. M., 503
Glantz, R. S., 535
Granger, R. L., 407
Heyliger, G. E., 275
Howe, R. M., 377
Hulina, P. T., 369
Hurst, R. C., 297
Irwin, M. R., 269
Isberg, C. A., 287
Jensen, E. D., 621
Jorrand, P., 9
Koga, Y., 69
Koster, R. A., 525
Lagowski, J. J., 257
Larkin, D. C., 113
Lee, C. E., 425
Ling, H., 211
Lum, V. Y., 211
Lund, D., 53
McDonald, J. W., 119
McCuskey, W. A., 187
McFarland, C., 629
McLelland, P. M., 223
Malia, T. C., 569
Mallary, R., 451
Mann, R. P., 555
Markel, J. D., 387
Martin, D. C., 241
Meade, R. M., 33
Mirabito, M. R., 345
Moore, C. G., 555
Moran, R. A., 377
Morgan, M. G., 345
Muller, M. T., 257
N aemura, K., 69
Newton, R. H., 325
Nishida, N., 653
O'Neill, L. A., 471
Orr, W. K., 181
Ossanna, J. F., 355
Ostapko, D. L., 63
Paige, M. R., 287
Palley, N. A., 589, 609
Patel, A. M., 63
Penny, S. J., 45
Peskin, A. M., 615
Pitts, G. N., 515
Prokop, J. S., 599
Roberts, R., 547
Robinson, G. S., 417
Rosen, S., 89
Rosenstein, A. B., 297
Rubin, A. I., 641
Sacks, S. T., 609
Sakaguchi, M., 653
Saltzer, J. H., 355
Scherr, A. L., 113
Schuman, S. A., 9
Sedgewick, R., 119
Senko, M. E., 211
Shemer, J. E., 201
Shivaram, M., 231
Shubin, H., 609
Siklossy, L., 251
Spencer, R. G., 563
Stevens, M. E., 159
Stone, R., 119
Storm, E. F., 21
Stuehler, J. E., 461
Tossman, B. E., 399
Trautwein, W., 135
Trimble, G. R., Jr., 417
Trotter, J. A., Jr., 589
Tu, G. K., 53
Van Tassel, D., 445
Vaughan, R. H., 21
Vierling, J. S., 231
Vonhof, P. W., 325
Wagner, R. E., 89
Walker, R. S., 425
Wasserman, A. 1.,433
Williams, C. E., 399
Womack, B. F., 425
Woodfill, M. C., 333
Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.3 Linearized : No XMP Toolkit : Adobe XMP Core 4.2.1-c041 52.342996, 2008/05/07-21:37:19 Producer : Adobe Acrobat 9.0 Paper Capture Plug-in Modify Date : 2008:11:18 06:26:22-08:00 Create Date : 2008:11:18 06:26:22-08:00 Metadata Date : 2008:11:18 06:26:22-08:00 Format : application/pdf Document ID : uuid:64f59d0f-2cc0-4097-936a-015ad78273db Instance ID : uuid:fde18921-c5d5-4ada-b426-17ce7e3cabcf Page Layout : SinglePage Page Mode : UseOutlines Page Count : 683EXIF Metadata provided by EXIF.tools