T H E U N I V E E S I T Y C F M I C d I G A N Memorandum 24 i AMP Architecture in a Utility Calculator System David L. Mills CONCCMP: ResEarch in Conversational lUse of Computers E. H. westervelt, Prcject Director CiA Eroject 07449 supported by: ALVANCED RLSEARCH PfiCJECTS AGENCY DEPAiTMENI OfE LEENSE wASHINGTON, D.C. CG5~IACI NO. LA-49-063 oSA-3050 ASP A ORDki NO. 716 administered througa: OFF'iCE OF iESEAHCH ADMINISI2ATiON ANN ARSiBOa May 1969

,iAMP Architecture in a Utility Calculator System AiSTRACT This Leport describcs an experimental multi-user utility calculator system similar tc PIL, BASIC and FOCAL, DUt impielaenteu as a subsystem in dAMP, a multiprogramming system described elsewhere. The teatures ot this system include text editing, statement interpretation and oexpression evaluation as in the other systems citec. in additioln, this system provides the capability of multitasking at the source language level. Thus each user can specity a program structure ccnsisting or a number of asynchronous tasks whlciC interact with each other in interesting ways. L L Lti

This report was prepared using FORMAT, a computer program in MTS, the Michigan Terminal System. This program is described in: Berns, G.M., _Descrition of FORMA.-__a_TextProcessin4 _Progra_ Comm. ACM, 12, 3 (March 1969), pp. 141-146. The text was entered to this program partly in punched-card torm and partly directly trom a typewriter terminal and was printed on an IEM 1403 printer equipped with a TN print train.

RAMP Architecture in d Utility Calculator System TABLE OF CO IEN1S 1. Ilntroduction.........................................., 1 2. Sy stem Architect ure..................4.................. 3 3. Languay e Specitications..............................7 3. 1 Ex press ions......................... 7 3.2 Statemen ts..............................* 10 4. Operating Conventicus........................... * 1 4 5. Rete ences.-...*...... a... a.. a....... *4*-*..... 1 6 Appendix A.;;r L cr Diagniostic Dictionary................ 17 Appendix S. A Recursive Program to Calculate Factorials.18 Appendix C. A Number-Cruncher to Calculate Transmission lline Characterist ics a............................... * 19

RAMP Architecture in a Utility Calculator System 1 1. INTiODUCTICN As an experiment not only in an application of the techniques aiscussed in the various RAMP reports (see references at the end of this repcrt) but in the utility of carrying the multiprcgramming operations to the statement level in an algebraic poygramming system, a utility calculator similar to PI, EASIC and FOCAL has been implemented around the basic RAMP supervisor. Besides being capable ot sustaining several users simultaneously, the system allows each user to define and execute a number of asynchronous tasks which can interact with each other in interesting real-time fashions. The system is written toL an 8K PDP-8 with an additionai teletypewriter interface. This provides a twouser system which can be expanded without reprogramming by adding more teletypewriter intertaces to serve as many users as reasonanle ~ithiil memory-size and response-time limitations. In the current implementation a memory space of about 7000 characters is available tor storage of user programs ana data. This space, shared among all users, is useu tor the lines of the user's stored programs, for the data structures created by the various tasks, and for miscellaneous butfers and control blocks which are allocated and deallocated as multiprogramming operations proceed. The facilities available to each user include the usual drithmetic-expression interLprLtation common in other similar languages. Variables are stLuctured as scalars or arrays of any dimensionality. The SET statement is used to assign the value or an expression to a variatle and the TYPE statement is used to print the value of an expression. Conditional Dranching among the lines of a storeu program can be specilied with the GO aria IF statements and the branch line numbers of these statements can bE computed. Most of the common unary and binary o peratiolis and transcendental functions of one variable are i mpleamented, as well as a complete set ot 1/0 formattir.g and conversion functions. The most significant auearture trom convention in this system is its multiprogramming capability. In the language in which tile user writes his programs, a subroutine call (DO statement) is actually a task invocation. In addition, tasks may be invcked to list a user-decined stored program or to prillt tile values assigned the currently allocated variables. The invoking task may be specified to proceed in parallel with the invoked task OL may De specified to wait tor it. Thus, it is possib e to secit y a number ot "simultanieous" tasks whicn perform various functions and interact with each other' in 1Interesting ways. 1. intodiuctiori

2 RAMP Architecture in a Utility Calculator System Statements entered to the system via the teletypewriter Keyboard are interpreted immediately in the order entered, while statements entered via the stored program are interpreted sequentially in the order ot increasing line numbers, as modified by conditicnal branching statements. Each statement entered in either ot these ways is treated as an independent task-scheduling operation, so that each user can be assured some processing even if another user hangs 4is stored program in a do-nothing lcop. Input/output queueing and line-editing operations are integral to this system in the same fashion as cther RAMP systems and special device sulpport can be added in the fashion popular with these systems. In particular, highspeed tape ana data transmission equipment and display devices can te supported easily with only minimal reprogramming. 1. Introduction

RAMP Architecture in a Utility calculator System 3 2. SYSTEMt A'CHIkICTURE The supervisory sections of this system include the buffer management, storage allocation, task scheduling, aevice interface, i/O utilities and initialization segments ot the basic HA1MP system (see reterence ). The operator's console teletypewriter service routines are scaled down somewhat, since ccome o~ the features are unnecessary in this system. The command language interFreter is restructured so that commands (oL statement lines as they are called in this system) can be entered either directly trom the keyboard or indirectly from the stored program. The stored program is implemented as an internal file indexed by line number. It is maintained in packed tormat, two characters per PDP-8 word, and can be edited by line number in the conventional fashion as in other similar systems. Figure 1 shows the structure of a line of the stored program. +._ _ _- _ __- _r ___ _ __._ _ _ _ _ _ _ _ + I LiNGTh OF THIS LINE i + --- _ __ __._____ + I LINE NUML'BER + __- _ _ _ _ _ _ _ _ _ _ + LINK TO iXT LINE I TEXT (PACKED TIO j + CHARAC'r'~RS PER + i wODii) I +.- _._ _ __ ___ __ _ _ __ ___ _ I _ + Figure 1. Stored Program Structure A command task, called the real-time tasK, is associated with each teletypewriteLr console at system initialization. The parameters tc this task include device table pcinters for the command source and sink devices, control switches and dictionary iointers for tne stored prograi r an d Uata s t ructure a associa ted with this task. Conlmmands entered via a cormmana source Jaevice can start other command tasKs, called stored-program tasks, which take input irom thl stored program. Sucn tasks can De specifiea either to process the statements or to simply list the lines of the projram togiether with their line nlumbers. The parameters to tthese tasks s-ecify dict ionaLy pointers for the data structures the task has created and the current line number. A rioating-point interpreter was couea specially for this systeIn, since the DEC-supIied version was: a) too slow, L) too iarge, c) too inaccurate, i) could not operate 2. System Architecture

4 RAMP Architecture in a Utility Calculator System in an extended-memory environment. The current implementation includes recoued versions ot the DEC transcendental tunctions and input-output conversion functions. The formats of floating-point instructions and operands are compatible with those of the DEC'imp lemen tation. The basic RAMP I/O. input formatting utilities were modified for use in this system to provide interfaces to the floating-point input conversion and expression-scanner routines. The ccmmon intertace to these routines provides a single subroutine call, with the exits providing information as to whether the input string was a constant, a letter string, or a special character. Constants are converted by this subroutine from the external character-string representation to the internal floating-point representation. Only the first and last letter in letter strings are retained and the resulting two-letter name may represent a command name, d variable or array name, or the name or an arithmetic functions An internal dictionary is associated with names in each ot these classes and the entries in each class are assumed unique. The variable names created by each stored-program task in the system may eitner be associated with a dictionary unique to that task or may be associated witl the dictionary belonging to the real-time task. Tfie namRes or statements and arithmetic runctions and the interpretation of special characters are associated with lixed dictionaries shared by all tasks (and theretore all users) in the system. Variables anu arrays are stored in this system as a data structure in tne form of a downward-oranching binary tree. At the apex of this tree and along the leftwardbranchlng thread are the modes associated with the variable names and their current values currently allocated to tae task. A rightward-branching link to a node inaicates a slngiy-subscripted reterence (a vector), and the leftwardbranching thread originating at that node contains the collection of all sing ily-suDscripted elements currently defined together with their values. At each of these nodes in turn a rightwaid-branching link to a node indicates a doubly subscripted reference (a two-dimensional array) and tne leftward-branching thread originating at the node contains the ccllection of all dcubly subscripted elements, the first subscript ot which is identitied by the originating node. in this fashion a data-structure representing a collection ot variable names each designating a scalar, vector, or array or indefinite dimeasionality can be represented. A typical structure is diagrammed in Figure 2. Note that the subscripted elements of one dimension are disjoint trom those of another, since they lie in dif ferent leitward-branching tnreads. Thus, no mapping function can 2. System Architecture

RAMP Architecture in a Utility Calculator System 5 exist between, say, linear subscripts of one dimension and those ot a higher dimension. Alsc note that a creation of an element of dimensionality n implies a creation of an element of all dimensionalities less than n. I VAR NAME/SUBSCEIIT I I LINK TO NEXT'bTRY I J LINK TO CCMPONENTS I + ___ __ ____ _ __ __......... + I I I VALUE (TihLrg WGCEDS) 1 + + I 1 +... _ _ _.. __ _ _._.._. _... _ _ _ + figure 2. Data Structure Integral to this system is an expression scanner modeled after tbhat implemented in tile MAD/1 ccmpiler, as described in reference 3. This system uses a similar algorithm, but with the addition of several contextdependent transformations which provide machinery to parse exceptional syntactic cases. Unlike the MAD algorithm this version interprets the parse in real-time; that is, each atomic expression consisting ot a single arithmetic oFerator and its operands is interpreted as it is identitied in the left-to-riynt scan. Each call to the expressicn scanner causes the stack to be allocated (but not using the comparatively slow system storage-allocation facilities) and the value of the expression to be computed. These operations proceed to completion without involving a taskswitching operation. The basic statement scanner calls on the expression scanner to parse phrases of the form: var(exp,exp,...) =ex,xpp,,... in such caseo the expression scanner is called one or more times to evaluate tne subscript expressions indicated between the parens, and the indicated aata structure is allocated and assigned to the particular task interpreting tne phrase. Then the expressions atter the equal sign are scanned each in turn and their values assigned to the structure at the indicated suDscript element and to each 2. System Architecture

6 RAMP Architecture in a Utility Calculator System succeeding element (formed by incrementing the last subscriFt expression by one) in turn. All operations involving program and data-structure storage make use of the system storage-allocation facilities. Storage is allocated to an element of a data structure only wnen necessary to store a value. Storage assigned a data structure element is deallocated when the allocating task terminates or by an explicit statement. Storage allocated the lines of the program is allocated and deallocated as line-editing operaticns require, but may be completely deallocated at any time by an explicit statement. 2. System Architecture

RAMP Architecture in a Utility Calculator System 7 3. LANGUAGE SPECIkICATIONS Following is a rudimentary "user's guide" to the language specifications and operation of the system. Although the facilities offered in this implementation are certainly adequate for the purposes here, namely to explore the multiprogramming utility, a more "userized" system would include several additional Delis and histles. 3.1 Exressions A variaile_ name is represented by a single letter followed optionally by either a letter or a digit. More than one letter or digit may follow the initial letter but in such cases only the last ct these is significant. Variables are used in arithmetic, line number, and subscript expressions, and as task variables (see below). A variable is represented internally as a floating-point number with a value between about 10617 and 10-61? to a precision of about seven digits. An array naame consists of a variable name tollowed by a list of subscrj_ exEp_ essions separated by commas and enclosed in parentheses Tihe interpretation of variables and arrays ccrrespcnds to the usual MAD or FORTHAN interpretation. Note that, however, no explicit mappings between multi-dimensional notations are implied. That is, the elements at A (i) (i=1,2,...) and A(i,j) (i,j=1,2,...) are always disjoint and no mapping function can be defined between them. The dienLsion of an array name is the number of such expressions and no bound is placed on the number. A constant is represented in conventional ilcatingpoint format and may take on values trom 10-617 to 1061t7, The external representation of tte constant may contain any number of digits befcre or after the decimaL joint and the exponent may be of any value. However, the value of the constant, when converted to its internal representation, must lie within the specified limits and will be retained to only about seven digits in precision. Constants are used in arithmetic, line number, ana sutscript expressions, and the same conversion algorithm is applied in all cases. An expression is represented in the usual manner as a list of variables, constants, operators, and punctuation marks. IlTe permissibl;e binary operators include "+" (addition), "-* (subtraction), (*1 (multiplication), I/l (division), and "~'" (exponentiation). The unary "+" (nooperation), and "-" (neyation) oFerators are differLentiated from their binary counterparts in context. Certain special and transcendental functions of one variable are also incuclueu.'These are summarized as follows: 3. Language Specifications

8 RAMP Architecture in a Utility Calculator System Name Fung Notation ABS absolute value lxI ATN arctan gent tan- (x) COS cosine cos (x) x EXP exponential (base e) e ITR extract integral part entier(x) LOG logarithm (base e) la(x) NEG negation -IxI Si~G extract sign fart sign (x) SIN sine sin (x) SQT square root Operator-precedence techniques (see references) are used in tne parsing of the expression; and, in fact, the parser algorithm itself is a scaled-down version of that used in MAD/I (see references) and the EDP-8 assembler resident in MTS. In this version, however, cnly a sinyle precedence function is used, rather than two as in the other systems, so the parser really has more of the characteristics oi the MAD compiler tor the 7090). Tlhe precedence of the various operators is as follows: unary + 6 functicns: ABS, etc. 5 + 4 unary - 3 $~~~~~ / 2 binary + - 1 punctuation: (, ) etc. 0 Error recovery is facilitated by ccmpariny the class codes assigned each identifier in context, a procedure used extensively by the MAD/1 compiler. It is easily shown that these eLror checks are exhaustive. 3. Language Specifications

dAMP Architecture in a Utility Calculator System 9 The validity of all arithmetic operations is checked at each ste-p tor overflows and underflows and, in addition, tne tollowing special tests are performled: 1. In division a divisor of zero is an error. 2. In the LUG function an argument less than or equal to zero is an error. 3. In the EXP function an argument greater than about 100 is an error. 4. In the SQT function an argument less than zero is an errcr. 5. Tile exponentiation operation " " involves calls on both the LOG and EXP functions using the identity A B = EXP(B*LOG(A)), so that operand errors may be found in these functions. 6. In several functions a conversion from tlcatingpoint to integer representation is required. In such conversions an integer representation greater than 223 is an error. Tne syntax of each expressiion is checked for errors at several points. These checks insure that the expression is well-tormed, that the various symbols are detined, and that any array structures relerenceu in tact exist. In addition, certain types of expressions are checked tor validity within certain statements such as whether the expression is valid when used in real-time, as against stored-program, mode. 1i either an arithmetic or syntax error is tound in a statement, interpretation of that statement is immediately terminated and a diagnostic message is printed on the operating console. This uiessage takes one of the following forms: xxxx FLOAITIG-POINT TEAP xxxx xiNVALI SYiNTAX xxxx INVALIL STATt4hNT xxxx INSUFFICELNT S~OhAGL where xxxx is a rouL-octal-digit Inumber identitying the location iil the system at which tihe error was tound. It interpretation was from a stored program, then the line number in wnicn the error was round is printed, If an error is found, iln te L pretation ima mediate l y stops and, if in 3. Language Specifications

10 RAMP Architecture in a Utility Calculator System stored-program mode, the task is terminated. A list of errors and their current error codes can be found in Appendix A. Expressions may be of three types, depending upon context; arithmetic, line number, and subscript. An arithmetic expression, representing a value of type real in the usual sense, is used wherever a reference to a program variable is intended and may take on positive and negative values of magnitudes from about 10-617 to 106 1 to a precision of about seven decimal digits. A line number expression, representing a value used as a line number in the stored program, is used as an operand of the IF, GO, and other statements, and may take cn positive integral values from zero to 4095. A subscript expression, representing a value of a subscript in an array name, is used in the construction of array names and may take on positive integral values from zero to 4095. Unless used as the first operand (left side of the assignment symbol "=") of a SET, DO, or LIST statement, all symbols and variable names in any expression of any type must be predetined; that is, must have occurred on the lett side ot a previous SET, DO, or LIST statement. 3.2 Statements A _pLram is a se.uence of statements identified by line number. Each statement type is identified by name (see below) and consists of a sequence of arithmetic and line number expressions. Each line number is a positive integer of value less than 4096. Additions and deletions of statements in a Program are done on a line-by-line basis at any time, whether tasks are running or not, and can be initiated either directly from the operating console or by the program itself. Statements are provided for these purposes as well as those to list portions of the Fprogram and to interpret such portions as commands. A task is explicitly initiated by the interpretation of the appropriate statement and is terminated under one of several conditions. The program itself is unique to each user in the system and is not affected by the initiation and termination ot the various tasks. At all times in which the user's operating console is active a real-timetask is operable in the system. This task operates with the console keyboard as its input. No line number is associated with this operation, so that the GO and If' statements are invalia when interpreted by the real-time task. Dependent tasks created by the real-time task are called stored- r oqram tasKs and these operate with the Frogram itself as input. By convention, tasks initiated by the real-time task are presumed to operate simultaneously, so that real-time 3. Language Specifications

RAMP Architecture in a Utility Calculator System 11 interaction is possible among them. On the other hand, a task initiated by a stored Frogram task is presumed to continue until completion before the invoking task is resumed. In this sense the stored-program invocation is really a simple recursive subroutine call. Each task invocation specifies a line number cf the program at which interpretation is to begin, following which the program is executed by the task line-by-line as specified. Associated with each task is a variable name which is assigned a value equal to the current line number of the active task. The value ot this task variable can be cnanged either by the task itself by means ot the branca statements (GO and IF) or by other tasks. Thus the task variable assigned each task represents a Kind ot instruction location counter in a peculiar "central-processing-unit," and can De accessed and modified by ct-her tasks running in the multiprogramming mode. By convention, if the value of the task variable exceeds tuat ot the highest line number currently assigned in the program, execution of the task ceases. In all cther cases, a branch to a program at any line number will cause the task to begin execution at the line number with a value at least that of tne branch number. At any place in a program in which a line number is expected, the vaiue can be ceenerated Dy a variable, constant, or expression, So that brancai points can be computed. Each line of the program, each task and each of its allocated variables requires storage space in the machine and this space is harea among all users or the system (currently two). In order to conserve storage space on one hand anl yet allow a reasonably unrestricted use of the availaDle space on the otier, the tollowing algorithm is used: 1. Variables are associated with the task that created them and are released when tnat task terminates or by an explicit statement. 2. The program itself is ccmmon to all tasks and can be erased at any time by any task. 3. A daughter task may access the variables of its anotner task, those of the mother ot its mother, aInd so forth. 4. Except ror (3) dbove, a task has access to no vdriables which Lit has nct createa. These conventions imply some rather interesting recovery procedures iln;atholcoicai cases, as might De expected. 3. Language Speciticatrons

12 RAMP Architecture in a Utility Calculator System There are some logically consistent situations which can occur when a task bombs (i.e., goes into a loop or traps) in which the only recovery possible is to erase the program. For instance, consider the case where task A calls task B which in turn calls task C using a task variable I for C which is not known to A. If task C bombs, then it cannot be stopped or restarted from A, since its task variable is not known to A. In general, then, it seems to be good programming form to use task variables which are known by the real-time task and therefore to all the daughter tasks invoked by the user. The following statements are recognized in the current implementation: TYPE expl,exp2,...,expn Type in floating-point format the values of expl,exp2,...eexpn. A character string enclosed in quotation marks (") may be used in place of a comma, in which case the string is printed at the indicated place. SET var=expl,exp2,...,expn Evaluate the subscript expressions (if a ny) ot var. Then evaluate each of the expressions expl,exp2,...,expn in turn and substitute their values for the components of var in turn, starting with the indicated subscript of var. See text tor variants ot the SET statement. GO exp Branch to the statement number given as the value of exp. IF exp,expl,exp2,exp3 Evaluate exi and perform a three-way conditional branch as follows: it the value ct exp is less than zero, equal to zeroc, or greater than zero, then branch to the statements whose line numbers are the vaiues of expl, exp2 cr exp3 respectively. DO var=exp Evaluate the subscript expressions for var and assign this component of var as a task variable. Then assign the initial value or the task variable as the value of exp and begin interpretation at the corresponding line number. 3. Lanjuage Specirlcations

RAMP Architecture in a Utility Calculator System 13 END Stop interpretation and return to the invoking task. FOUMAT expl,exp2 Set format constants used il t loati n g-point output conversion. The value otf expl beccmes the tabstop value; each iloating point output conversion is tabbed so -that its first character is at a line position which is a multiple of this value. The value ot exp2 becomes the number of significant (ncnlzero) digits retained during the output conversion process. (The full precision is retained during all inteLnal operations however.) ERASE Erase all lines of the stored program. LIST var=exp Evaluate the subscript expressicns for var and assign this component as a task variable. Then assign the initial value of the task variable as the value oz exp and begin listing ot the stored program at the corresponding line number. DiELETE varl,var2,..,varn Deallocate the variable s tructures indicated by vr 1, var2,..., arn. 3. LangJuage Specitications

14 RAMP Architecture in a Utility Calculator System 4. OPERATING CCNVENTIONS The console operating protocol and line-editing conventions are identical with those of the Data Concentrator and other related RAMP systems. In summary, the following characters are interpreted as line-editing runctions: Character Function BETURN end of line RUL30UT line delete Control-H (CAN) character delete (backspace) Control-E (ENQ) attention Control-Shift-P (NUL) leader-trailer (ignored) NAil 63 USASCII printing graphics available on the Teletype Models 33/35/37/3b except "i)" are available to the system; all other characters are ignored. In the case of Model 37/38 the lower-case alphabetic characters are mapped into their upper-case equivalents. (This machine requires, of course, a ditrerent interface clocK.) All characters typed at the console keyboard are return-Echoed tc the console printer, but it is possible to enter lines to the system while the console printer is typing some other information. In such cases the returnecho line is delayed until the end of the current output line, and then is output to the printer. If the keyboard or echo buffers overflow, the return-echo process is suspended. if the keyboard buffer overtlows (always due to an input line which is tco long), then either a character-delete or a line-delete operation will ciear the condition. It the echo buffer overflows, then simply waiting tor current printer activity to cease will clear the condition. Statements may be entered to the system in two modes: The real-time mode, in which statements are interpreted as entered trom the keyboard, and the stored-program mode, in which statements are interpreted in sequence trom the internal stored program. Since the real-time task is always active, statements can be entered to the system at any time, whether output is being produced on the console printer or not and regardless of the configuration of the operating tasks and their attached vart iables. Statements are entered to the system rrom the stored program by creating a task using the DO statement. A task 4. Operatinj Conventions

RAMP Architecture in a Utility Calculator System 15 created by either the DO or LIST statements can be stopped at any time by changing the task variable (using the SET statement) to a number higher than the highest line number currently assigned in tile stored program. Statements in the two operating modes are structured alike except that the GO and IF statements are semantically invalid it entered in the real-time mode. The stored program itself is created and modified using conventional procedures. A line to be entered to the stored program is prefixed by a line number in the range from zero to 4095 and a single blank and followed by the end-of-line (RETURN) code. A line ot the stored program can be erased by entering the line number tollowed immediately by the endof-line (RETUtN) code. Lines may be entered to the stored program which, when themselves interpreted, will cause other iines to be moditied by using the following rule- during interpretation, tirst the line number and one space is stripped from the interpreted line. Next the line-update operation is done, preserving any residual leading blanks. Finaily the resultant line is treated as if it came from the real-time task. The entire stored program can be erased at any time and by any task using the ERASE statement. A variable structure is created by the DC, LIST, SET, LOCAL and GLOBAL statements. When created by the LOCAL statement the variable is attached to the creating task, w ilether in real-time or stored-piogram mode. Thus the variable is known to all daughnters ot tne creating task but none of its ancestral mother tasks. When created by the OLObAL statement the variable is attached to the real-time tasK and is known to all tasks in the system. When created by the ShT, DO or LIST statements, a search is made in the dictionary defining variables which belong to the creating task, then the mcther ot that task, then its mother, and so forth to the real-time task. if the variable name already exists in one of tnese dictionaries, then the reference in the SET, DO, or LIS'~ statement is assumei to be to that instance, otherwise the variable is attached to the creating task. The structure of the variabie dictionaries in this fashion provides a Earameterizaticn facility in rather an interesting fashion and allows Lrcursively structured stored programs with in terccimmunicatiting tasks as illustrated in Appendix B. 4. Operatin Conventions

b1 RAMP Architecture in a Utility Calculator System 5. R EFR ENCE S 1. Milis, D.L., AMP- A _Multio am Sstemfor__RealTime Device Contr oll Concomp Project Memorandum 5, University ot Michigan, May 1967. 2. Mills, D.L., I/O Extensions to BAMP__ Concomp Eroject Memorandum 11, University ot Michigan, October 1967. 3. Mills, D.I., Thte Sntactic Structure of MAD_/ Concomp Project Technical Report 7, University of Michigan, May 1968. Also in Procedings of International Seminar on Advanced Programming Systems, Hebrew University, Jerusalem, August 1968. 4. Mills, D.L., The__ Data_ Cncentl ator Concoimp Project Technical Report 8, University of Michigan, May 1968. Also in Procedings of University ot Wisconsin Engineering Institute, December 1'368, pp. 1-113. 5. Mills, D.L., MultiRroInam iMn in a Small-Systems Environtmen tL Concomp Project Technical Heport 19, University of Michigan, May 19b9. Also in Procedings of University ot Michigan Engineering Summer Conterence, June 1969. 6. Powers, V.M., Mills, D.L., and Laurance, N., An Assembly __Lanue S em or DEC Mini-Comput__tersL Concomp Project Memorandum 20, University of nichigan, May 1969. 7. )u FOCAL frogramming Manual, Form DEC-08-AJAC-D__ Dl~r CuLy e _oj. e _ _May~nat LtLarss.j 1 938. 8. iu PuittsburqhInteIr&petive Languaqe_ {ILLL. -in MTS - Micga a __Termina. SL stem U-niversity of Michigan Computing Center, 1968. 9. Mills, D.L., and Powers, V.M., PDP-8 Eoqram Relocation: Concepts anu Faciiities, Conccmp Froject Memorandum 17, University ct Michigan February, 1968. 5. Heferences

RAMP Architecture in a Utility Calculator System 17 APPENDIX A. ERROR DIAGNCSTIC DICTIONARY PDP-8 dAMP CONTROL SYSTEM (VERSICN 58) 05-17-69 ASSEMBLY LISi'iNG (ALL NUMBERS ARE OCTAL) PHINT ON,SH OiiT,NOR E 4017 XXXU01 ERR001 iNVALID VARIABLE ASSIGNMENT STATEMENT 5311 XXX018 EiRU18 INIEGER OVERFLCG 5b03 X XX002 ERRO02 )IVIDE CHECK 612'7 XXXO003 ERREO3 f"SQT" ARGUMENT LESS THAN ZERO 0204 XXX004 ERR004 "LOG" ARGUMENT LESS THAN OR EQUAL TO ZERO b337 XXXO05 ERROOS "EXF" ARGUMENT TOO LARGE 5234 XXXOU6 iER006 FLOATING-POINT UNDERFLOW 5243 XXX007 ERR007 FLOATING-IOINT CVEEFLOW 4473 XXXOO8 ERROU8 INVALID OPERAND CONTEXT 4530 XXXOO9 ERRO09 UNDEFiNED S'YMBGL 4517 XXOl10'RiO 10 INVALID BINARY OPERATOR CONTEXT 4561 XXXO11 ERR011 INVALID UNARY CEEhATOR OR "(" CONTEXT 4'3 7 XXXO 12 ERRO 12 ILL-OREMED EXPRESSION 47.27 XXX1O 3 EaRO 13 STACK OVEAiFLOW 3747 XXX017 ERR0 17 INVALID ERANCH STATEMENT IN REAL-TIME TAS 4456 XXX0114 ERR014 UNDEFINED SUBSCRIET 3501 XXX021 EdiR021 MESS ERROR. IGNORL THIS COMMENT 3614 XXXO24 ERRO24 UNDEFINED STATIMENT TYPE 4140 XXX022 ERR022 VARIABLE LICTIONARY OVERFLOw 5333 XXXO2O RRhO2O0 INVAL.ID LINE-NUM8IE- OR SUBSCRIPT EXPRESSI 36-/2 XXX019 ERiOl19 LINE DICTiONARY OVYEiFLOW 4133 XXX015 ERR015 UNLE'INED SUBSCRE1T 3bb663 XAXO16b ERRi016 INVALID LINE-NUMBER DELIMITER 4073 X XXV23 EiR 023 M SiNG SU BSCR IPT EXPRESJION D EINITION 44446 XXXO2L) ERROi5 MISSING SUBSCRIPT EX.PRES.S ION 4567 XXX0(26 ERRO 26 MISSING OPERAN OCR tXPRESSICN Appendix A

18 RAMP Architecture in a Utility Calculator System APPENDIX B. A RECURSIVE PiOGRAM IO CALCULATE FACTCRIALS Following is a listing and a sample run of a program to calculate the factorial of d positive integer using the algorithm: F(N)=1; if N=1 F(N)=N*F(N-1); if N>1 Program: 100 iF N,,,130 110 GLOBAL E=1 1IO END 130 LOCAL X=N 140 LOCAL N=X-1 150 DO X=10C i60 GLOBAL E=F*(N+1) b1l TYPE N+1,F 170 END Sample run: FORMAT 4,6 SET N=10 DO X=O 1 1 2 2 3 6 4 24 5 120 b 720 7 5040 8 40320 9 362880 10.362 650 0 Appendix B

RAMP Architecture in a Utility Calculator System 19 APPENDIX C. A NUMBER-CRUNCHER IC CALCULATE TRANSMISSION LINE CHARACTERISTICS The following pro9ram computes a summary oi the electrical characteristics o.t loaded and nonloaded telephone cables of the type typically used in exchange loops. Calculations usIng this program have been made yielding data usetui tor the design of leased-line connected remote job entry equipment. The theory on which these methods are based can be found in the reterences following this appendix. * COGPUTE LINE PA~iAMEiFSS 100 SET S=D*$ST (F) 105 iF.2718'*- 1,,, 114 110 SET E= 1 112 GO 140 114 IF S-11.083,,,130 115 SET E=1+.08* (.2718*S-1)t 2 120 GO 140 130 SET E=.096*S+.2b 140 SET H-=R0*E 150 SET L=LO/E 160 SET G=GiO*(F/100)0)4 1.3 170 SET C=CO 180 IF QQ,190,,190 182 TYP~ f,D*SQT(F),R,L,G*1E6E,C*1E6, QT ({L*C)*1E3 16ii4 END * CO UTE CHA{dACTERiSTiC IMPEDANCE AND PEOPAGATION CO ASTANT 190 SET i=2*'. 141593*F 220 SET' T 1 = i *R+ W*L*W*L 2 30 SE -'2 T2=G*G+ *C*W*C 240 SEr T3=ATN (W*L/R) 250 SEX T4-=A'N (W*C/G) 260 SET Z=SQI (SQT (T1/i2)) 270 SET Z1=(73-T4)/2 280 SET H=S1 (SQ (i 1 *T2)) 290 SET H1= ('13+T4)/2 292 SET A=ti*C0IOS H1) 294 SiL' Di=H*SIN (H 1) 296 IF QQ-3,,496,496 3OU IF QQ-1,310,,310 302 TY E F, 2*COS(Z1), L* IN (l 1),8.6 bb6*A,B, B/W* 1I 3 304 END * CCIPU It TbANSMISSiCN CiIAPRACTh-RIST I CS 310 SET T1=-N*B 330 SET T2=EXP(-N*A) 340 SET iJ3=i2COS (T1+ Z1) Appendix C

20 9AMP Architecture in a Utility Calculator System 350 SET T4=T2*SIN (T1+Zl) 360 SET T5=12*COS(T1) 370 SET T6=T2*SIN(T1) 380 SET U11=BL* (1+15) +Z* (COS (Z1)-T3) 390 SET U2=EL*T6+Z* (SIN (Z1)-14) 400 SET U3=RL*(1-T5)+Z* (COS(Z1)+T3) 410 SET U4=-RL*T6+Z* (SIN(Z1) +T4) 460 SET E=2*RL*Z*I12/SQT ((U1*U1+U2*U2)*{U3*U3+U4*U4)) 470 SET E1=Z1+T1-ATN(U2/U1)-ATN(U4/U3) 480 IF QQ-4,,492 490 IF QQ-2,496,,496 492 TYPE F,8.686*LOG (E),El/W*1E3 494 END * COMPUTE EQUIVALeNT-TEE PARAMETERS 496 SEt A=K*A 498 SET B=K+B 500 SET T1=EXP(-A) 510 SET T2=1-TI*CCS (B) 520 SET T3=1'TI*COS(B) 530 SET T4=T1*SIN (B) 540 SET Mi=Z*SQT ( (T2*T2+T4*'i4)/ (13*T3+T4*T4)) 550 SET L1=Z1+ATN(T4/T2) +ATN(T4/T3) 560 SET T2=EXP (-2*A) 562 SET T3= 1-T2*COS (2*B) 564 SET 14=12*SIN (2*B) 570 SET A2=2*Z*T1/QT (T3*T3+14*T4) 580 SET L2=Z1-B-ATN (T4/T3) 600 SET T1=1X/2+M1*COS (L1) 610 SET T2=W*LX/2+M1*SIN(L1) 620 SET 11=SQT'T (T1*T1+T2*T2) 630 SET L1=ATN(T2/T1) * CCOMPUTE TEE IMPEDANCE AND PECPAGATION CONSTANT 650 SET T1=2*M2/M1 660 SET T2=L2-L1 670 SET T3=1+T1*CCS(T2) b80 SET T4:11*SIN(T2) 690 SET T5-=SQT'(SQ1 (T3*T'13+T4*4)) 700 SET Tb=A'N (T4/T3)/2 710 SET T6-=t6+SIG (T3) * ( 1-2*SIG (T4) ) 3. 1415923/2 740 SET U1=T5*COS(T6)+1 750 SET U2=T5*COS (T6) -- 1 770 SET' U3=T5*SIN (T6) 772 SET Z=M1*T5 774 SE: Z 1-L1+T6 780 SET A=LOG (SQT ( (U 1*U 1+U3*U3) / (U2*U2 UJ*U3 ) ) 790 SET b=A N (U 3/U1) - ATN (U3/U2) 800 SET b-=B+(SIG(U1)-sIG (U2))*(1 -2*SiG (U3))*3. 1415923 810 IF 2Q-3,302,302,310 * MAI i PRCOGbAM Appendix C

RAMP Architecture in a Utility Calculator System 21 1JOO30 SET K=1 1010 SEI D=.03589 1012 SET RO=. 1095/ (D*D) 1014 SET L0=.001 1020 SET G0=1E-6 1030 SET CO=.061E-b 1032 SET N=1 1040 SEI RL=600 1042 SET RX=7.6 1044 SE~ LX=.088 104o FOkHMAT 10,4 1047 TYPE K,D,L0,GO,CO 1048 TYPE N,RL,RX,LX 1050 SET P (1) =50,100,200,500, k13, 2E3,5E3,7E3, 1E4, 1.5E4 1052 TPiE "'IRAANSMISSION-LINE CHARACTERISTICS" 1054 SET i,=0 1056 IF'-5,, 1150 1058 T0YP "SET "QC 1060 SEI 1=1 1070 E I- 1-10,,, 1 120 10b0 SET F=P(I) 1090 DO X=100 1100 SET I=1+1 1110 GO 107C 1120 SEI I =-T+ 1 1140 GO 1056 1150 END AppeIndix C

22 RAMP Architecture in a Utility Calculator System REFERENCES FOR AEEENDIX C 1. H inderliter, R. G, Tra nsmission_C haracterist ics ot Bell Systeim Subscriber _Loo_ pPiant A.I.E.E. Trans. On Communications and Electronics, (September 1963), p. 464. 2. Johnson, W.C.', "Tr ansmission Lines and Networks," McGraw-Hill, New York, 1950, 361 pp. 3. "'Reference Eata for iadio Engineers,l Westman, H P. (Ed.), International Telephone and Telegraph Corp., 1959, 1121 pp. 4. Shaw, I., Th _Evolution of Inductive Loading__r_ Bell Stem TeleeoneFaciities BS 30, 1951, p. 149. Appendix C

-23T NCASSIFI1ED Security Classification OCUME CONROL DATA - R & P (SOcuritv clasifiration of title. body od.t: t, n i:,o,n.dew;:/-4'o.',,'o,:r - r,':::;..::. i; ov-erall reporr is Classif;Uid' TE 6 fUNIVERSITY iOF MICHIGAN. ^T 2b. 2GROUP CONCOMP PROJECT 3. REPORT TITLE RAMP Architecture in a Utility Calculator system.. DESCRIPTIVE NOTES (T'pe of report and inclusive dates) Memorandum 24 5. AUTHOR(S) (First name, middle initial, last name) David L. Mills 6. REPORT DATE 7a. TOTA NO OF PAGES *?_. S 7. OF REFS May 1969 4 s8. CONTRACT OR GFANT NO. O Sa ORIGINATOR'S REPORT NUMBER(S) DA-49-083 OSA 3050 Memorandum 24. b. PROJECT NO. 9b. OTHER REPORT NO(S) (Any other numbers that may be assigned this report) d. _....... 10. DISTRIBUTION STATEMENT Qualified requesters may obtain copies of this report from DDC. 1. S! D' EMrT-"-RY -~G TES.'2. SPONSORING MILITARY ACTIV:TY Advanced Research Projects Agency 13. ABSTRACT This report describes an experimental multi-user utility calculator system similar to PIL, BASIC, and FOCAL, but implemented as a subsystem an RAMP, a multiprogramming system described elsewhere. The features of this system include text editing, statement interpretation, and expression evaluation as in other systems cited. In addition, this system provides the capability of multitasking at the source language level. Thus each user can specify a program structure consisting of a number of asynchronous tasks which interact with each other in interesting ways. DD 1473 UNCLASSIFIED

UNCLASSIFIED 1.24 -Security Classification. _ LINK A LINK B LINK C KEY WORDS ROLE WT ROLE WT ROL L multiprogramming operator-precedence language text editor floating-point interpreter PDP-8 T..... IC,, TFTF.n Security Classification