^B! m ill' !t IsRliiiilllili: ^HWW^? "L I B RAR.Y OF THL UN IVLR.S'"ITY Of ILLINOIS ■'.r/'i': The person charging this material is re- sponsible for its return on or before the Latest Date stamped below. Theft, mutilation and underlining of books are reasons for disciplinary action and may result in dismissal from the University. UNIVERSITY OF ILLINOIS LIBRARY AT URBANA-CHAMPAIGN i 1982 1982 L161— O-1096 •xo-y- 5r REPORT NO. I96 MATHEMATICS COO-IU69-OOI3 AN INTERACTIVE, TIME SHARE SYSTEM FOR A SMALL COMPUTER by Melvin E. Haas February 1, I966 DEPARTMENT OF COMPUTER SCIENCE • UNIVERSITY OF ILLINOIS - URBANA, ILLINOIS rliarpine this material is re- Iprir-ortsTJ^^n^ tUt Dote stamped below^,^.„,. ore reasons for d.sc.p J University, result in dismissal from__the_^^^^^_^^^ Report No. I96 M INTERACTIVE, TIME SHARE SYSTEM FOR A SMALL COMPUTER-><- Melvin E. Haas February 1, I966 Department of Computer Science University of Illinois Urbana, Illinois 618OI This work supported in part by Contract No. US AEC AT(11-1)1^69, under the direction of Professor C. ¥. Gear, and was submitted in partial fulfillment for the degree of Master of Science in Aeronautical and Astronautical Engineering, January, I966. ACKNOWLEDGMENT The author would like to express his appreciation for the guidance provided by Professor Harry H. Hilton and Professor Gemot Metze. The tech- nical counsel given by Professor Metze is particularly appreciated. Thanks are also due Professor C. W. Gear and the Department of Computer Science for supporting this work. ■ii 111 TABLE OF CONTENTS 1. INTRODUCTION 1 2. THE LANGUAGE k 3. SYSTEM OPERATION 9 k. IMPLEMENTATION li+ 5. CONCLUSION 29 6. BIBLIOGRAPHY 35 APPENDIX I 36 APPENDIX II 38 APPENDIX III i+8 APPMDIX IV 5U ] I 4 r < i »i It IV 1. INTRODUCTION The motivation for an interactive computer system is to obtain fast response for program generation^ debugging^ and running. The human user retains control of the computing process, and can modify program j change parameters, and correct errors as required during solution of the problem. An interactive system contains a man-computer interface as a distinguishing characteristic. This interface is not present in the more common, batch process, computer sys- tems . The requirements and characteristics of the human user are the major design factors for an interactive system. The human engineering of the system determines the efficiency of computer use. A system that is overly complicated, irrational^ or slow reacting will waste problem solving time. An ideal inter- active computer system has the following attributes" 1, short, simple, nonambiguous control language, 2. fast response to user commands, 3o complete human control of computer actions, k. routine labor supplied by the computer,, An interactive computer system involves real-time communication with a human, at a speed very much slower than the computer speed, allowing one computer to simultaneously handle several users, v/ith the computing of one user overlapped with the communications of the others „ Conflicts between users are handled by sharing the computer time, with each user getting sma.l.I segments of the available time on a rotating basis. Time -sharing allows an interactive sys- tem to make economic use of the computer. Interactive, time share computer systems have been in existence for several years. Most of these require the use of a powerful computer with huge "Several of these systems are described in references 1, 3, ^^ 9) H; s^d l4. -2- memory capacity. Small computers usually have systems designed to maximize the computational power available, and are rarely interactive or time-sharing. By limiting the computing power offered, an interactive, time share system can be put on a small computer. The work detailed in this paper is the design of such a system. The motivation for an interactive system for a small computer is to obtain fast response for program generation, debugging, and running. The com- promises made to compensate for the limitations of the computer affect only the size of the program and the extent of the computations allowed. The prob- lems of system design, other than human engineering, reduce to choosing features that allow reasonable computer power, with minimum demands on the computer. For the purpose of this design, a small computer will be defined as having the following minimum capacities: 1. the ability to perform floating point arithmetic by subroutine or hardware, 2. the ability to communicate with as many keyboard/teleprinters as there are to be simultaneous users, 3. a minimum of 75,000 bits of core memory, plus at least 5,000 2 additional bits for each user. Additional computer features may be incorporated, but are not essential to the system design. Initial implementation of the system is to be made on a PDP-7 computer,"^ with teletype consoles for up to 5 users. Techniques developed in this report are illustrated by, but not restricted to this one implementation. A more powerful computer may use the same system with more users, and conversely. The numbers given here are only estimates, and are not substantiated. 3 The PDP-7 is a small, general purpose computer manufactured by the Digital Equipment Corporation, Maynard, Massachusetts. See reference 5. -3- The design of the computer system is presented in three sections. The first section presents the language, LTLTRAN, by which each user communi- cates with the computer. The second section develops the time share aspects of the system; the features that keeps each user from adversely affecting the others. The third section details the computer realization of the system, with particular emphasis on methods of organization and planning. THE LANGUAGE It is not necessary to restrict a time share computer system to one input language. Several such systems allow the user to define or use a number of different computer languages. In multiple language systems, there is very little control over the human-computer interface, hut restricting a system to 2 one language allows the system to be optimized for human communication. The disadvantage of the single language system is that the computational power offered to the user is restricted to that allowed by the language. This res- triction may be used to advantage in the design of a system for a small com- puter, since the power of the language may be tailored to fit the capabilities of the computer. Thus a sin'^le ],3n.euar^e syr.tcrn fi.lJowr, the syr.tem design to be both human engineered and matched to the computer capabilities. A single language system has the additional advantage of allowing system programs, such as the language processor, to be shared by all users. This represents a significant storage space savings within the small computer. The computations most suitable for performance on a small computer fall in the area of arithmetic problem solving, rather than in the area of data processing since the limited memory capacity of a small computer does not allow a large amount of data to be handled. The most widely used arithmetic problem solving computer language is F0RTRAN,-^ LTLTRAN, the language designed for a small computer system is a subset of F0RTRAN. This decision was based on the assumption that the human user would likely be familiar with FORTRAN, and would therefore make fewer errors and require less training in the use of LTLTRAN, To eliminate a source of user confusion, the features of LTLTRAN are similar to the corresponding Project MAC and SDS/Berteley systems are examples. See references 3 and. 11. 2 BASIC and QUIKTRAN are examples. See references h and 9, o ■^F0RTRAN is described in references 7, 8, and lU, -h- features in FORTRAN, wherever possible „ The formal, complete syntax and semantics of LTLTRAN are contained in Appendix I and Appendix II of this report. The remainder of this section presents the design "basis of the language. The major design feature of LTLTRAN is the limit placed on the number of variables allowed. The use of 26 variables, addressed by single letters of the alphabet, sets the limit on the computational power of the language. This addressing scheme is simple for the human user, as it corresponds to typical algebraic usage, and is free of tricky restraints. Use of computer storage is minimized, because no name-to-storage mapping tables need be maintained. The remaining features of LTLTRAN are those needed to allow reasonable use of the 26 variables. All variables and constants are handled in floating point notation (exponent and fraction) to simplify the programming of both the user's program and the system. This is not a restriction, because fixed point notation (integer only) is a logical subset of floating point notation. The only com- plication caused by this decision arises in the semantics of LTLTRAN exponen- tiation, as will be discussed. The LTLTRAN conventions of arithmetic operations and function use are exactly those of F0RTRAN except for exponentiation. F0RTRAN exponentian conventions are determined by the notation mode of the exponent, as follows: h argument A. fixed point B. fixed point C. floating point D. floating point exponent fixed point floating point fixed point floating point result fixed point with correct sign not allowed floating point with correct sign floating point absolute value k FORTRAN conventions are described in reference 8. LTLTRAN does not distinguish "between fixed and floating point exponents and therefore cannot follow F0RTRAN conventions. On the assumption that a common use of LTLTRAE would be to evaluate polynomial expressions^ convention C above has been chosen for LTLTRAN. The exponent is assumed to be an integer in a LTLTRAN expression. If at program execution time, an exponent is found to contain a fractional part, an error stop will occur. Convention D above may be programmed in LTLTRAN by use of the ABS, L0G, and EXP functions. Examples: A = -2 ** 3 would produce A = -8 A = -2 ** 3" 2 would produce an error stop A = EXP (L0G (ABS (-2)) * 3-2) would produce A = 9.I8959 The basic unit of the LTLTRAN input is the statement (input line). All program transfers are to the beginning of a statement. To provide for full control by the human user, a double labeling scheme is provided. One label, the line number, is provided by the computer for every statement. The other label, the statement number, may be supplied by the user where desired. Either label may be used in any control statement. To prevent confusion bet- ween labels, the statement number is limited to 2 digits, and the 3 digit line number is in the form of a decimal fraction. LTLTRAN control statements allow any extent of branching and loop- ing. The functions of all F0RTRAN transfer operations may be programmed in LTLTRAN by use of the IF and G^ T0 statements. LTLTRAN subroutines are defined by the label on the first statement in the routine. Transfer to a subroutine by a CALL statement is an extension of the G^ T0 statement actions. The sub- routine RETURN statement serves as the depository of the return label, thus retaining consistency with F0RTRAN subroutine conventions. LTLTRAN subroutine calls may be nested to any depth. The line number label serves to keep the user informed of the actions of the computer. The numerical order of the line numbers indicates the order -7- of computation (in the absence of control statements). Replacement lines and insert lines are put in proper position as indicated by the line number. Upon program execution of input and output statements, the line number of the statement is typed to help the user identify the program action being executed. At all error stops, the line number of the statement that caused the error is typed, along with a code indicating the error cause. Each LTLTRAN input statement is checked for format errors imme- diately. If an error is found, a standard error stop occurs, and the user may then type in a corrected statement. Thus the user may correct this type of error locally, while his thoughts are still on the particular statement. The LTLTRAN convention of one statement per line, and the terseness of the statements minimizes the amount of typing required to correct an error. At the execution of a READ statement, the computer types the letters of the variables wanted, thus reducing confusion and the chance of error on input. As an additional convenience, a plus sign, +, may be typed instead of an input value to indicate no change in the value of the variable. The command (immediate execution), mode of LTLTRAN operation (indi- cated by a preceding number sign, #) allows "desk calculator" type use of the console. This mode of operation may also be used to set values of variables before, or during, the run of a program. A transfer command may be used to initiate execution at any statement. A command PRINT statement may be used to obtain the current value of any variables. To facilitate user control of computer operation, the user may in- terrupt program execution at any time by typing any printing character. Con- ditions are saved at interruption, so that execution may be resumed by use of the G0 ^N command. Nonprinting console characters are ignored at all times. The user may format the printed page at will, by use of tab , line feed , and space . -8- Comments may be included, and errors logically erased, by use of the per cent, °Jo, line deletion convention. Single letter errors may be corrected by use of the backspace. The user has to supply only the minimum input information to specify the actions desired. No unnecessary typing is called for from the user, and output typing from the computer is held to a minimum. The teletype console types at a maximum rate of one character every .1 second. A human reaction rate is of the same order. Any excess typing after the information content has been sensed by the human is a waste of time, and may be very annoying to the user. Human reaction times to light and sound stimulus fall between .050 and .400 seconds typically. (reference 15) 3 . SYSTEM OPERATION The system operation should be transparent to the user. That is, the user should only be concerned with his own LTLTRAN program, and should not be affected by the actions of the system or other users. The purpose of the system control is to present each user with the appearance of an in- dependent version of LTLTRAN. The major design problems in the system control fall in the areas of response time and fail safe operation. Response time is the time it takes the computer to respond to the user's request for action. To the LTLTRAN user, there are three types of request for computer response: 1. inputting of a character, 2. finishing a line of input, 3. initiating execution of a program. Each of these requests has a different maximum acceptable response time. Character input from the consoles requires the shortest response time. It is unthinkable for the system to require the user to type slowly, because the system is not able to read the characters at fast typing speed. To the user, the system must give "instantaneous" service for each character 2 at all times and at all typing speeds. With typical teletype equipment, there is a 0.018 second interval during which a character may be read after it has been received at the computer. This interval (or "window") sets the maximum execution time of any system routine on computers without hardware interrupt. On a computer with interrupt features, the character window sets the maximum time for continuous interrupt disallowed operation. Section ^ will discuss character handling in detail. « If It "LJser intervention during execution is handled in the same manner as an input line. 2 Teletype handling requirements are detailed in references 6 and 10. -9- -10- When the user finishes an input line (by typing the end of line character, SO), he expects the computer to decode the line, check for errors, and return with the line heading for the next line. The system control should be designed to give very fast service to input lines because computer caused delays in the input process are most annoying to the human. If the response comes from the computer in less than a human reaction time (.05 sec. to .h sec), the user will not be aware of any delay. Response time greater than 2 seconds may distract the user from the problem at hand. The system control has little effect on the running time of a user's program. The running speed of a program is a function of the type of program and the power of the computer. The execution response time to the LTLTRAN user is a function of the running speed of his program, and the number of computer actions required by other users. With a long program, several other users, and a slow computer, the response time for execution might be on the order of minutes. The major task of the system control in program execution is to assure that each user gets a fair share of the available computing time. The system control should be able to stop exe- cution of a user's program, and later resume execution at the same point. The point of execution stop should always occur at a program point corres- ponding to the transition between input LTLTRAN statements. If the system never stops during the execution of a LTLTRMJ statement, no changes that the user makes to the program can cause a system failure. This point will be discussed later under the topic fail safe operation. The execution stopping process includes: recognizing the tran- sition point between LTLTRAN input statements; saving all the program variables required to restart; and transferring to the next action to be performed. Upon receipt of an end of line character from a console, the program in execution must be stopped and saved, and the input line decoded. -11- The response time for processing an input statement is the total computer time required to: recognize the end of line character^ finish execution of the program code produced by one LTLTRAN statement^ save the execution variables, and decode the input statement. After the input line is decoded and the line heading for the next line is sent to the console, execution for some user may resume. If several users have LTLTRAN programs in execution, the available computer time must be shared. On computers with hardware clocks, a time in- terval may be allocated for execution. The program being executed will be stopped at the statement transition following a clock produced timing sig- nal. A simpler method, useful on computers with no clock, is to keep a count of the number of program statements executed. When a count limit is reached, the program is stopped and another user's program execution resumed. In the system being discussed, the time required to switch from one user's program to another's is small compared to the program execution time. A simple 3 "round robin" scheduling scheme is adequate for this situation. Each user in execution is allocated an equal time (or statement count) interval, and execution proceeds from one user to another in waiting order. The computer should send a null character, occasionally, to con- soles of users in execution. The null character rattles the console and lets the user know that the computer is still working on the program. This placebo is an important feedback communication to the user, A transmission interval of 1 to 5 seconds is adequate to prevent the deadly lack of action, disturbing to the human user. Fail safe operation of the system assures that no user's program will be affected by the actions of any other user. The language, LTLTRAN, 3 Scheduling problems and definitions are discussed in reference 13. 1? *, h it " '1 -12- eases the system design in this area. LTLTRAN allows only limited access to the computer storage. Each user has direct control of only his own 26 variable storage locations. Thus memory protection is not a required fea- ture of system. The LTLTRAN error handling^ where only a 3 letter n-inemonic and current line number need be supplied, allows all errors in any routine to transfer to a common control point. Thus no unforeseen combination of errors can cause a system failure. The choice of an input LTLTRAN line (statement) as the smallest unit for partial execution or decoding by the system allows independent action by the user for each line. After a line is input or executed, the user may, by use of the intervention features of LTLTRAN, change that line without confusion to the system. The pointers and execution variables, saved for each user, describe a condition between statements, not within a statement . With limited storage available for user's program, it is not de- sirable to assign a fraction of the storage to each user. Rather, the available storage should be allocated as needed on a first-come first-served basis. This scheme makes the maximum use of the storage, and allows any user to have a larger program. At any one time it is assumed that a few of the users would have only small programs. When the available storage is all in use, the program building consoles would get an error stop, and would have to wait until some user releases storage by giving the #CLEAR command. A situation exists where a user may leave the console without giving the #CLEAR command. This display of bad manners may tie up some computer storage, and if the program is in execution, may also be using computer time. To prevent waste from this situation, the system will give an automatic #CLEAR after a suitable time interval from the last character -13- received from a console. The console "bell character should be sent several times at intervals, as a warning, before the automatic clearing takes place. The user can prolong execution by typing any nonprinting character at the bell ring. The time interval before the first bell ring (approximately 5 minutes or an equivalent statement count) should allow for any normal user distraction. k . IMPLEMENTATION The previous sections present the design features of an inter- active, time share system. This section develops details of the imple- mentation of the system. The implementation is not totally divorced from the design of the system. Many of the design features are included as aids to the user, only because they are inexpensive to implement. Details of the system are shown for an implementation on a PDP-7 computer. Other computers would require different details, but the basic methods should apply. The computer storage sections are shown schematically in Figure 1. Control Atomizer Compiler Interpreter Buffers User' s Programs Figure 1 User's Programs The user's programs are formed as list structures in the space allocated. Each user program is a single, forward linked list. Each list element contains the program information plus a linking address of the next -Ik- -15- element in the list. The free space (locations not taken by user's programs) is also linked as a list structure. All elements in all lists are the same lengths. Thus list elements may be attached, inserted, or withdrawn from a list by manipulation of the linking addresses. No consideration need be made of contiguous storage locations, or absolute storage addressing within a list. The list structuring of the program storage allows the basic fea- tures of the system to be easily implemented. LTLTRAN statements are repre- sented by segments of linked elements within the program list. Changing a statement involves replacement of one list segment with another, and has no effect on the storage representation of the rest of the program. During program execution, a LTLTRAN statement transition is recognized by the appearance of a line number (or flag) within a list element. The list segments are linked in line number order, and transfers are executed as a forward search of the list for the label desired. The list elements are long enough to contain the information re- lative to the simplest LTLTRA.N statement. Complicated input statements map into more than one list element. Figures 2 and 3 present the bit assign- ments chosen for the PDP-7 implementation. The choice of element size is somewhat arbitrary. For ease of programming, an integral number of storage words per element is required. The number of words per element should be chosen to minimize the number of elements for the types of programs repre- sented. The PDP-7^ 3 word element was chosen on the assumption that a larger proportion of the input LTLTMN statements will be short and not re- quire multiple elements. If the input programs consist of many long, com- plicated arithmetic statements, a longer element would be justified. A shorter element is not economical, because every input statement would require more than one element, and the ratio of link bits to information -l6- LTLTRAL ( [ Elem( Legenc word 5nt Bit i in Fig Assignment jure 3) 1 1 2 1 3 4 5 6 7 8 9 [10 II 12 13 14 15- /6 17 Arithmetic 1 -■1 T^p Link 2 31 Line Statement 3 0^ 1 O2 ^1 ^ov PRINT or READ 1 L± Top 1 Link 2 Sj_ 1 Line Statement 3 0^ Og oi A N G0 Tj^ or CALL 1 1 Top Link 2 Si Line Statement LS /////// Line or Statement RETURN or G^) fm 1 1 Tot. Link 2 Si Line Statement 3 o\//////A Line END or RUN 1 l| Top Link 2 Si Line Statement 3 ////////////////// IF 1 Top Link 2 LS LS / 01 L or S - Line or Statement 3 WA Or L or S + Line or Statement Constant I Top Link 2 Exponent 1 Fraction 3 right Fraction F igure J 2 -17- LTLTMN Element Bit Assignment Legend Li Link Line N X LS Line Number Flag Si - Statement Number Fla^ Address of first work of next element Line Number Statement - Statement Number Number of l/0 Operands Operand Code V / A ' Unused Bits Line (o) or Statement (l) Transfer Flag Type Operation Code (Top) - End of Program 1 - READ 2 - PRINT 3 - G^ T0 h ~ CALL 5 - RETURN 6 " END 7 - IF 10 - Constant 11 - Arithmetic 12 - End of Command . 13 - G0 0N Operand Assignment (O ) ' ' Jr\. - Constant (in next elements) 1 to 32 - Variables A to Z 33 to 37 - Accumulators 1 to 5 Arithmetic Operation Code (A ) - function up °l"^2^^°3^ 1 - assignment °2^3 2 - unary minus °r-°3 3 - addition °1^2^°3 k - subtraction °1^2-°3 5 - multiplication °1^2*°3 6 - division ^1^2/03 7 - exponentiation °l"^2**°3 Function Assignment Code in OF - SIN 1 - C0S 2 - SQRT 3 - ATAN k - L0G 5 - EXP 6 - ABS 7 - INT ^ ;1 If Figure 3 -18- bits would be too high. The actual bit assignment within an element is a coding detail best left to the programmer. Constants are carried as part of the program list. Thus no storage buffers need be assigned for them. This will be inefficient for programs that use the same constant many times, where a single storage for the constant would suffice. However, incorporating the constants into the program list simplifies the system programming, allows the user to have as many constants as he wants, and in the normal case, make more efficient use of storage space. Buffers Buffers (reserved storage areas) are required: for the 26 vari- able values allotted to each user, for the incoming or outgoing characters in console communications, and for the pointers used by the system to de- termine the status of each user. The total length of this buffer storage area is the only design variable directly determined by the maximum number of simultaneous users allowed. It is conceivable that the unused portion of this area could be attached to the free space list when less than the maximum number of users are signed on. Interpreter The interpreter is a system program to execute the list elements of the user's LTLTRAN program. This is not a true interpreter in the stric- test sense, in that the input string of console characters is not decoded at execution time. The interpreter contains all the system routines to perform floating point arithmetic, change and store variable values, and to search and transfer within the list structure of the LTLTRAN program. -19- Arithmetic operations are represented in 3-ad.dress Polish notation. In this notation, simple arithmetic operations, such as A = B + C or F = C0S (g), are represented by a single element „ Code optimi- zation is not a feature of this system, and a floating point store opera- tion is required for each arithmetic task performed. This seeming ineffi- ciency is not too harmful with most small computers, because floating point numbers are not usually held in a hardware register, and thus must be stored in memory in any case. A 5 tit operand code allows up to 5 intermediate result accumulators to be used in evaluating complicated arithmetic expres- sions. Figure 3 shows the operation and operand codes to be used in the PDP-7 implementation of the system. Compiler The compiler is a system program to produce the list elements of the user's LTLTRAN program. This is not a true compiler by strict defini- tion, in that actual machine code is not produced. The use of a system that is part compiling, part interpreting, gives all the flexibility of a true interpretor plus some of the execution speed of a compiled program. The compiler contains routines to construct and link all the types of list ele- ments, and stack manipulating routines to arrange arithmetic elements in proper order for execution. Input to the compiler is an atomized image of the input LTLTRAN statement. The atomizing program of the system maps the console charac- ters into atoms. Each atom is a code indicating the function (type) of the input character (or characters) and the value (token) of the item. The atom bit patterns chosen for the PDP-7 implementation of the compiler is shown in Figure U. 1. Polish notation is described in reference 1^. -20- LTLTRAN Atom Bit Assignment (for compiler) 1 1 2 I 3 I ^ I ^ i 6 . 7 I 8 I 9 |10 1 11 1 12 113 1 1^ , 1^ 1 16 )17 Priority Code Type ^•-—'Assignment bit (Set to 1 for =) Type - not used 1 - operand 2 - operator 3 - not used Operator Code - function 1 - assignment 2 - unary minus 3 - addition k - subtraction 5 - multiplication 6 - division 7 - exponentiation k - not used 5 - left . parentheses 6 - right par entheses 7 - not used Priority Symbol 6 © 1 = 5 ~ 2 + 2 - 3 # 3 / k f Operand Code - constant and dummy operand (d) 1 thru 32 - variable letters A thru Z 33 thru 37 accumulators ACC^ thru ACC^ 1 5 Constant temporary storage is addressed by the priority number, Figure h -21- It is the function of the atomizer to encode words, and to convert input numbers and constants „ Because of the simplicity of the LTLTRAN language, the atomizer is straight-forward multi-hranch programming, proceeding from left to right in one pass through the input character buffer. A dummy operand, (d), is inserted before each unary minus, and a dummy operator, (f) ^ is inserted "between each function operand and its argument's left parenthesis. These dummy atoms facilitate the compiling process. The compiler uses a 3-stack procedure to generate list elements from the atoms of arithmetic expressions. Atoms are withdrawn from the input line buffer, one at a time, in an order corresponding to left to right in the input LTLTRAN line. Operand atoms are pushed into the operand stack. Operators are assigned a hierarchy order as follows: 1 assignment, 2 addition and subtraction, 3 multiplication and division, k exponentiation, 5 unary minus, 6 function. The handling of the operator atom depends on its hierarchy number according to the following: 1. If the operator stack is empty or has a left parenthesis atom on top, the operator atom is pushed into the operator stack regardless of its hierarchy; 2. If rule 1 does not apply and the operator stack has an atom on top of lower hierarchy, the operator atom is pushed into the operator stack; t -22- 3. If rules 1 and 2 do not apply, each atom of equal or higher hierarchy is popped from the operator stack until rule 1 or rule 2 applies. As each operator atom is popped from the operator stack, two operand atoms and one accumulator atom are popped from the operand stack and accumulator stack respectively. These h atoms are used to make up the list elements in the order of execution. Additionally, the accumulator atom is pushed into the operand stacko Each accumulator atom popped from the operand stack is used to form the list element, and is pushed back into the accumulator stack. Left parenthesis atoms are pushed into the operator stack. Right parenthesis atoms cause all operator atoms to be popped from the operator stack, until a canceling left parenthesis atom is popped from the stack. When the in- put atom buffer is empty, all operator atoms are popped from the operand stack. The assignment operation is a modification to the last list element formed, and does not form a. list element itself. The assignment operation causes the last result accumulator atom to be replaced by the last operand atom in the operand stack. The arithmetic compiling process is illustrated schematically and by example in the following figures. ]\bnarithmetic list elements are generated by standard subroutines within the compiler and atomizer. Commands are processed in exactly the same manner as regular programs except that a program flag is set for future re- ference, and the command list elements are left in the free space list and not appended to the user's program list. Control The most important, and hardest to design, portion of the system im- plementation, is the system control program. The task of the system control is -23- LTLTRAN Compiler Schematic input atom buffer operand atoms accumulator stack operand stack r M ■- Element Assembler V List Elements operator stack r ' f i Figure 5 LTLTRM Compiler Example LTLT RAN Inp ut Line A = B * C - H * - SIN (d + E) Atomized Line A = B * C ~ H ^<- @ - (sLn) (D f E) Compiler Output Atoms AGO, AGO, B D ACC ^11^ AGG H ACC. AG( AGG, AGG, Order of Output AGC^ AGC_^ ACC. ACC. A, op List Element s_ Produced © C E AGG, c ACC AGG, c AGG, 2 B D H AGG. ACC ACC (Sim AGu fd^ ACC, AGG, Order of Execution A Figure 6 =25- not uniquely determined by a set of inputs and outputs as are other sections of the system. All possible combinations of user actions, for all users, must be allowed for, and the requirements for response time and fail safe operation must be met. Standard flow charting techniques fail to show interrupt and time dependent program actions. These actions are most important to system control program planning, therefore a new charting scheme was devised to graphically present these program actions and their interrelation. The charting scheme is specifically designed and illustrated for use on the subject system, but it may be extended in scope to cover larger, more complex systems . For charting purposes all system routines are classified into three types: phantom, tyrant, and interruptable. The phantom program is specifically identifiable as the program that handles the character-by-character communication with the user's consoles. On computers with hardware interrupt feature, this program is entered at every in- terrupt. On computers without hardware interrupt, this program is a subroutine called at periodic intervals by all other system routines. For purposes of this report, each entry, by whatever means, to the phantom program will be called an interrupt. A characteristic of the phantom program is that it saves all computer hardware conditions at interrupt, and restores them before returning to exactly the same control point from which interrupt occurred. Thus execution within the phantom program has no effect on the program being executed at the time of interrupt, or vice versa. Program control flags in the phantom program define independent character handling sequences for each con- sole. In effect, each console has its own phantom program running in short spurts at each character interrupt. The phantom program runs in the ID (interrupts Disallowed) mode so that an interi'upt for a character for one console cannot occur during the processing of a character for another console. 11 I ' •■ it -26. A tyrant program is characterized "by a programmed change from lA (interrupts Allowed) mode to ID (interrupts Disallowed) mode. A tyrant pro- gram is used to reset actions in the phantom program. No interrupts can be allowed during running of a tyrant program because of possible ambiguities in control while flags are being set,. A tyrant program ends with a change back to lA mode. Interruptable program runs in the lA (interrupts Allowed) mode, and includes all program that is not phantom or tyrant. Interruptable program and the phan'com program in effect run concurrently with no interaction. Any sequence of the phantom program for a console can be running overlapped with the interruptable program of any other console. A tyrant program runs alone and is not overlapped with any other program. The essence of the charting method is to classify all system program segments (blocks), and display them in a manner that allows their interre- lation to be seen. Each major control path for the system for any one console is shown on a chart. Each chart has the lA (interrupts Allowed) program blocks shown to the left; ID (interrupts Disallowed) program blocks shown to the right; all in time order from top to bottom. Tyrant program is indicated on both right and left sides, with the left side block hashed. Every entry and exit from each block is indicated by a labeled arrow. Flag actions are given in the left margin. Timing information, where important, is given in the right margin. The complete set of charts for the interactive, time share system on a small computer is given in Appendix IV. The phantom program is controlled by a set of status words, one for each console. Each status word can contain a sequence of action codes to be brought into effect in turn upon receipt of the console end of line charac- ter. The action code in effect at a particular instant determines the mode of ■27- the console c The mode of the console is indicated on the planning chart "both atove and below each set of ID blocks. A single memory word, called the swap flag, is used to indicate when an executing LTLTRAN program is to be stopped. The swap flag is reset when execution is initiated, and is checked at the execution transition between LTLTRAN statements. > > -28- LTLTRAN Console Status Word Assignment ignore one interrupt only, and continue error flag not used error code not used not used not used 2nd waiting console action 1st waiting console action current console action code 1 2 3 k 5 6 7 1 2 3 Action Code ignore all interrupts receive transmit transmit and echo check intervention^ set SWAP upon receipt of printing character receive, set SWAP at SO transmit, set SWAP at SO transmit and echo check, set SWAP at SO Error Code intervention receiver buffer full echo check failure new console sign-on Figure 7 i 5 . CONCLUSION The small computer system developed in this paper permits a general class of arithmetic solutions to he programmed^ debugged, and run on the com- puter in minimum real-time. The human user of the system interacts intimately with the computer to arrive at the problem solution. In the problem solving process, the computer supplies all the routine, preprogrammed labor; the human user supplies input data, and the direction and control intelligence. Since the human user is the controlling factor in the efficiency of the overall process, the system is designed from a human engineering viewpoint, rather than the classical one of computational efficiency. The basic inefficiency of having a slow human be a part of the computing process is compensated by time-sharing several simultaneous users on the computer. Time-sharing does not prevent the computing service to any one user from being degraded by the actions of the other users, however the degradation is spread equitably among all users. The computer language, LTLTRAN, presented in this paper permits a full range of arithmetic operations on constants and up to 26 variables. The operations may be performed immediately in a "desk calculator" mode, or may be made a part of a computer program for future execution. Program control statements in the language permit unrestricted looping, subroutine calling and nesting, and conditional branching. Additional control conventions allow the human user to make program changes at any point in the program generation, debugging, or running process. Particular care has been taken in the design of the system to match response time to the requirements of the human user. The major effect of this matching has been to compromise program running performance to gain speed in communications with the user. Another design philosophy permeating the system -29- '•■ i -30- is the miniinization of console typing. The typing to and from the user is limited to the required information content. However, this philosophy is not carried to the extreme of requiring an extensive artificial vocabulary of abbreviations. Methods of implementing the system discussed in this report stress the use of list structures for program storage. List structuring permits the flexible control offered the user. Input LTLTRAN lines are mapped into iden- tifiable and maneuverable units in storage. Dynamic allocation of storage allows any user to construct a larger program than would be possible with statiC;, equitable reservation. Interrupt planning of the system was expedited by the development of a charting system to show program interrelationships. Use of the charting scheme is restricted in this report to the subject system, but the basic details of the scheme should find application in larger, more complex system design. The resulting charts do not replace conventional program flow charts; rather they present information not clearly shown conventionally. Three plan- ning items shown, that are most important are: 1. sequence actions required for the interrupt handling routines, 2. flag actions required to communicate between program segments, 3. overlap opportunities and restrictions. Evaluation of the system should incorporate examination of features not included. A few of these will be presented here. Probably the major inadequacy of the system is the inability to handle more than 26 variable values at any one time. This places a direct limit on the scope of problems that may be solved, A user would have to have extraordinary programming ability to use LTLTRAN to solve a set of 5 simultaneous equations (30 input variables, 5 output variables). A simi- lar, related deficiency of the system is the inability to handle variable -31- arrays, or subscripted variables. The system does not provide some of the user conveniences common to FORTRAN, Chief of these is the automatic program loop, or D^ statement. The function of the D0 statement may be programmed in LTLTRAN, but not con- veniently. FORTRAN features of computed G^ T^, and subroutine local vari- ables may not be much missed in the unsophisticated programming allowed. User defined functions would be a very desirable feature, and may be worth adding later. The system does not give the user control of the format of the printed output. In particular, messages or headings cannot be printed under program control. Thus LTLTRAN run programs are not self -documenting. Fur- ther, it is not possible to obtain a clean print-out of the program. It may be a tedious chore to backtrack a console listing to reconstruct from addi- tions and substitutions a document of the program. A related fault, is the inability to save a program once it is formed. When the #CLEAR command is given, the program is destroyed. To reuse a program, it must be retyped in. Retyping of often used programs may be done automatically from consoles equipped with paper tape readers, but the paper tape must be punched off-line from the computer. Some of the features of the system presented should be compared with similar features of other systems. The author is most familiar with the systems in the following table, and contrasting details will be drawn from these. System CTSS QUIKTRAN BASIC SDS/Berkeley -32- Sponsor Project MA.C;, MIT^ Cambridge, Massachusetts IBM, New York, New York GE, Phoenix, Arizona University of California, Berkeley, California No attempt will be made here to describe these systems, except to note that they all are larger and more extensive than the subject system, A controversial design point is the handling of the input line, LTLTRAN has the computer supply the input line number as does QUIKTRAN and the CTSS's INPUT program. It is a matter of opinion whether the ease of making changes (the strong point of BASIC and SDS/Berkeley) outweighs the time and trouble savings of the computer supplied labor for normal input. An addi- tional factor in this decision for LTLTRAN, was that the computer supplied ordering of the input would aid the user to produce an orderly, readable listing of the program. This same argument is used to justify the require- ment that replacement and insert lines be supplied with a standard heading. It would be very difficult to backtrack on a listing if changed line numbers were buried in the statement text. Another controversy centers on the end of line character assign- ment. Some users prefer to use the RETURN key (as in BASIC and SDS/Berkeley) as a "natural" carry over from electric typewriter use. This eliminates a very useful indication of when the computer is ready for a new line of input, as the carriage return provides a clear, audible, and visible portion of the J new line heading. The ALT M^DE key is an easy to use end of line key, but is not installed on many teletype consoles, SO, the standard ASCII line ter- minator, is a combination of the C^'NTR0L key and the X key, and is not easy to remember or use (similar to the QUIKTRAN E0B character). LTLTRAN side- The systems are described in references 3^ ^, ^^ and 11, -33- steps the controversy by allowing any of the above end of line characters and also the printing character semicolon, ; . None of the comparison systems have the LTLTRAN double labeling 2 scheme o CTSS and QUIKTRAN allows a class of commands and program control statements to refer to one: the line number or the statement number, but not to either interchangeably. BASIC allows only a line number, with the attendent difficulties of forward reference. Of the dedicated (single language) systems, QUIKTRAN and BASIC, only QUIKTRAN is interactive, and that only for programs with no subroutines. BASIC programs may be interrupted during execution, but no access to program- generated variables may be gained, and execution cannot be resumed. From a human engineering viewpoint, the QUIKTRAN and SDS/Berkeley systems offer experience upon which response time decisions can be made. SDS/Berkeley does not offer "immediate" response to each character, but rather delays printing until ,2+ seconds after each key is pressed. This has the effect of slowing the typing of even experienced users. QUIKTRAN accepts characters as fast as they may be typed, but does not process input lines rapidly. The user must wait 2 to 10+ seconds between input lines. This delay encourages the user to try to fit complicated expressions on one line with the attendent waste typing in case of error. QUIKTRAN (a rather slow, fully interpretive system) does nothing to the console during program execution. This leaves the user with the nagging question, "Has the system died, or is it Just running slow?" Future work on the interactive, time share system, beyond the scope of this report, should includes lo implementation of the design on a real computer. 2 A few of the QUIKTRAN commands may refer to either label, but the scheme is not consistently applied, and only statement numbers may be used in program. -3U- 2. investigation of additional features that may be desirable, 3. extension of the design to larger, more powerful computers. Study of the system under actual operation should show up the most desirable additional features, as well as prove the usefullness of this design. 6 . BIBLIOGRAPHY [I] Eric Burgess, et al, On-Line Computing Systems, American Data Processing, Inc., Detroit, Michigan, 1965- [2] R, S. Burington, Handbook of Mathematical Tables and Formulas , McGraw- Hill Book Company, New York, N, Y, , I965. [3] F. J, Corbato, et al. The Compatible Time-Sharing System: A Programmer's Guide , 1st ed. , M.I.T. Press, Cambridge, Massachusetts, I963. [k] Dartmouth, BASIC , Dartmouth College Computation Center, Hanover, New Hampshire, 196^, [5] DEC, Reference Manual PDP-7 ^ F-75> Digital Equipment Corporation, Maynard, Massachusetts, I965. [6] DEC, 630 Data Communication System, F-O3 (63OA), Digital Equipment Corporation, Maynard, Massachusetts, 196^. [7] W. Po Heising, "History and Summary of FORTRAN Standardization Development for the ASA," Comm. ACM, 7, October, 196^, [8] IBM, FORTRAN II, General Information Manual , GENL-25, IBM Corporation, New York, N, Y. , I961" [9] IBM, IBM 7040/7044 QUIKTRAN User's Guide , IBM Corporation, New York, N. Y.7~1965o ^ [10] IBT, Bell System Services, ASCII Code, 33 and 33 Teletypewriters , Illinois Bell Telephone Company, Chicago, Illinois, I96U. [II] W„ Wo Lichtenberger and M„ W. Pirtle, "A Facility for Experimentation in Man-Machine Interaction," AFIPS Conference Proceedings, Vol. 27, Part 1, Spartan Books, Washington, D. C. , 19^5 . P. Naur, et al, "Revised Report on the Algorithmic Language ALGOL 60," Comm, ACM, 6, January, I963, A„ Lo Scherr, A n Analysis of Time-Shared Computer Systems , MAC-TR-I8 (Thesis), MIT, Cambridge, Massachusetts, I965. New York, N. Y, , I96I+" [12] [13] [1^] peter Wegner, et al. Introduction to System Programming , Academic Press, [15] W, E. Woodson, Human Engineering Guide for Equipment Designers , Uniirersity of California Press, Berkeley, California, I956. •35' APPENDIX I SYNTAX OF LTLTRAN The syntactic definition of LTLTRAN is given in Backus notation. The metalanguage brackets, < >, delimit the objects of the nonterminal vocabu- lary. The metalanguage separator, [, may be read as "or".