UNIVERSITY OF, ILLINOIS LIBRARY At URBANA-CHAMPAIGN The person charging this material is re- sponsible for its return to the library from which it was withdrawn 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. To renew call Telephone Center, 333-8400 UNIVERSITY OF ILLINOIS LIBRARY AT URBANA-CHAMPAIGN Z ? 13 Digitized by the Internet Archive in 2013 http://archive.org/details/runtimesupportfo868jone > /u. yr UIUCDCS-R-77-868 JjU'ttr UILU-ENG 77 1719 RUN TIME SUPPORT FOR THE TUTOR LANGUAGE ON A SMALL COMPUTER SYSTEM By DOUGLAS WARREN JONES May, 1977 orary of DEPARTMENT OF COMPUTER SCIENCE UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN URBANA, ILLINOIS UIUCDCS-R-77-868 RUN TIME SUPPORT FOR THE TUTOR LANGUAGE ON A SMALL COMPUTER SYSTEM BY DOUGLAS WARREN JONES Revised May 1977 Department of Computer Science University of Illinois at Urbana-Champaign Urbana, Illinois 61801 This work was supported in part by the Department of Computer Science and the School of Basic Medical Sciences, and was submitted in partial ful- fillment of the requirements for the degree of Master of Science in Computer Science, 1976 1 1 1 ACKNOWLEDGFI^fnts Professor Thomas T. Ch-n deserv es special credit for providinq the initial impetus behind this project and tor hie r ♦ • K JUI dnu 'or rn$ continued support and encouragement without which this project would never h.--v» been ,o.pl.t.d. I would also like to thank „. B. Paskin and Tho»„s si.lyo, for the P ar, they played in the implementation phase of tris project. IV TABLE OF CONTENTS INTRODUCTION 1.1. 1.2. 1.3. APPLICATIONS FOR A THI- POSSIBILITY OF PROJECT GOALS SMALL TUTOR SYSTEM OTHER LANGUAGES . 2. BASIC DfSIGN CONSTRAINTS 2 2 2 2 2, 2. 2. 2. 1. ftOMA TNS OVER WHICH TUTOR 1.1. PROGRAM SPACE 1.2. EXECUTION IS DEHNFD 1.3. 1,4. 1.5. 2. STUDENT OR USE* VAPIABLFS rOMtfON OP COMMUNICATION VARIABLES* STORAGE OR EXTFNDED USER VARIABLES VARIABLE SFGMENTING PROGRAM REPRESENTATION 3. DATA REPRESENTATION 3. JUDfUNT OR INPUT MANIPULATION 3.1. 3.2. 3.2.1. 3.2.2. 3.2.3. 3. 2. A. 3.3. RAM STRUCTURE Thi RESPONSE JUDGING MECHANISM i-FFFCTS OF JUDGING ON PRO THf TUTOR JUDGING PlOCK CONDITIONS FOR RESPONSE EVALUATION rXFCOTION OF BLOCKS CONDITIONAL ON JUD JUDGING AND SUBROUTINE CALLS INTERPRETER MECHANISMS AND THE COMPILER* A- UNITS OR UNIVERSAL PROGRAM SEGMENTS 4.1. 4.1.1 1.2 1.3 1 .4, 2. 3. 3.1. 3.2. T l F DIFFERENT USFS OF UNITS AS MAIN PROGRAM SEGf^ENT r AS SUBROUTINES . /S INTERRUPT PROCESSING ROI'TINe's AS CONTINUATIONS OF PARAMETERS TC UNITS INTERPRETER OTHER UNITS MECHANISMS AND THE COMPILER PROGRAM STATUS INFORMATION STANDARD CALLING AND EN RECEIVING SEQUENClS PAGE 1 1 2 2 4 5 6 8 9 10 10 12 lb 15 16 17 U 1V 20 21 23 23 23 24 25 27 21 2V 2V 30 5. TUTOR (ONDITIONAL AND LOOPING COMMANDS 32 5.1. CONDITIONAL COMMANDS 32 5.2. LOOPING COMMANDS 33 5.3. LOCAL CONTROL STRUCTURES 34 5.4. INTERPRETER MECHANISMS AND THE COMPILER ... 35 6. TERMINAL INPUT AND OUTPUT 36 6.1. T E FLATO IV TERMINAL 37 6.2. TUTOR SUPPORT OF THE TERMINAL 37 6.2.1. OUTPUT CAPABILITY 37 6.2.2. SIMGLF KEYSTROKE INPUT 39 6.2.3. TEXT INPUT FOR JUDGING 40 6.2.4. RESPONSE TIME 41 6.3. UNIFORM INTERNAL CHARACTER CODE POSSIBILITIES . 42 6.4. POSSIBILITIES OF SUPPORTING OTHER TERMINALS . . 43 6.5. DIVISION OF INPUT/OUTPUT RE SPONS I P I L I T I b S . . 43 6.5.1. THf INTERPRETER 44 6.5.2. TH[ VIRTUAL DEVICE FANDLER 44 7. CONCLUSION 46 7.1. IMPLEMENTATION RESULTS .... 46 7.2. INCOMPATIBILITIES WITH PLATO 4t< 7.3. EPILOGUE 49 LIST OF REFERENCES 50 APPENDIX A APPENDIX P APPENDIX C APPENDIX D APPENDIX E SUMMARY OF THE EXECUTION OF TUTOR .... 53 SPECIFICATIONS FOR THE INTERPRETER ... 5? INTERMEDIATE CODE COMPILATION EXAMPLES . . 66 COMPILATION OF UNITS AND JUDGING SEQUENCES . 70 TERMINAL TRANSMISSION COTES AND BUFFERS . . H1 Page 1 1. INTRODUCTION Possibly the laroest single collection of computer based instructional material in the world is written in the TUTOR proaramminq Unouage C11#19] fully supported only by the PLATO system [13 developed by the Computer-based Education Reasearch Laboratories (CFRL) of the University of Illinois. The PLATO system and associated TUTOR language have evolved together over the last 10 years/ and combine a number of interesting and powerful features that are not widely available in other systems. Thouch intended primarily for the structuring of instructional material tor computer presentation* the TUT 1 . R language has been used for information system develorment [243* simulation of physician-patient interaction 113,14], and a host of other applications. Subsets of TUTOR have previously been implemented by others, most notably in the 1ULTTTUT0R- HYPERTEXT system at Northwestern University [17,1fcD. This paper deals with the design and implementation of a run ime support system for TUTOR in <; small machine environment. The ntire system is described elsewhere [?,.?, 7,*, 2?, 253. .1. APPLICATIONS FOR A SMALL TUT0l< SYSTEM T h * PL^TO system uses a larqe dual [.rocessor machine with two Ulion words of 60 bit fxtended Core Storage and o complex jltiplexor system to drive to up to ITOU terminals. Startup costs )r such a system are quite hioh, as are communication costs if the ';er community is geoo raph i ca I I y dispersed. In aodition, the size Page 2 o* the user community on such a system can raise serious managerial and security problems. fecause of this* there may be many applications for an alternative in the form of an inexpensive system of 2f) to 30 terminals with the capability to tie into networks with similar systems. The feasibility of such a system has previously been i nves t i oat er with favorable results C6]/ although TUTOR has since evolved/ invalidating some of the design decisions of this earlier wori . 1.2; THT POSSIBILITY OF OTHER LANGUAGES Currently the PLATO system supports only the TUTOR language for the development of interactive programs* and there is no commitment to support other lanmjaoes for any but background or batch processing. alternatives to TUTOR need to be explored/ particularly in the «ire;. of control structures. At least one such language has teen developed and implemented on PLATO by translation to TUTOR L 1 U _ It is hoped that the interpretation technique described in this paper will considerably simplify such experiments. 1.3 PROJECT f.OALS T h ^ principal goal addressed here is the demonstration that TUT'R can be supported for a sinale user on a small to medium scale machine in a manner compatible with extension to multiple users. This involves an analysis of the different features of TUTOR showing either that they are compatible with such an environment/ or if not/ Page 3 that the cost of incompatibility is reasonable. An interpreter and compiler have been implemented based on the ideas presented here* and a limited number of TUTOR programs have teen transferred from PLATO. Because of the speed at which TUTOR on PLATO is evolving* an important subgoal is to design the implementation with maximum flexibility so that changes can be incorporated with a minimal amount of new work. The notation and terminology used here are largely adopted from the PLATO project; for instance/ command names are enclosed in dashes (-dot-)* and names of special characters are capitalized (FONT). However* TUTOR lessons are referreo to as programs and students as users in order to emphasize that TUTOR is a general puroi se Language and is in no way limited to instructional applications. The following chapter discusses the general nature of a TUTOR program and the different constraints on how it may be represented and interpreted on a small machine. The remaining chapters deal Similarly with the special areas where TUTOR is most different from conventional programmino languages* specifically the areas of input analysis or judging* program seomentin-. or units* «no i nput /out put . This should not be considered as a complete description of an implementation of TUTOR* as many conventional facilities of the language are only briefly covered* if at all. Page ?. BASIC DTSICN CONSTRAINTS The constraints aovernino the way TUTOR is implemented fall into three Large classes: Those introduced by the target hardware/ those introduced by thr TUTOR languaoe/ and these introduced by the imp I ement or for other reasons. In this last class is the desire to eventually support other programmino languages* as well as the desire to support user terminals other than the present PLATO IV terminal . One of the greatest barriers to implementing TUTOR in any new environment is that TUTOR is defined in terms of the hardware on which it is implemented at CERL/ with little or no attention to the possibility of machine i ndependen ce . For this reason* part of the problem of implementing TUTOR on . small machine lies in deciding which aspects of the original machine require emulation/ and which are nonessential to the definition of TUTOR. 2.1. DOMAINS OVER WHICH TUTOR EXECUTION IS DEFINED It is convenient to discuss the design constraints imposed by the TUTOR Ian uage in terms of the resources that must be brought together for a program to be run. In this context/ the current PLATO implementation/ as well as the available implementation alternatives/ can be meaningfully discussed and related to the pre lems of a small to medium scale machine environment. Page 5 2.1 .1 . PROGRAM SPACE The program to be executed may be shared by many different users/ all executing different parts of it in a time-shared manner. On PLATO/ the programs are stored in Extended Core Storage (ECS)/ and when a user wishes to execute a portion of a pro cram/ logical segments of that prooram are brought into central memory for execution. These segments/ called 'units' on PLATO/ provide a virtual memory mechanism tnat allows full use of two million words of ECS by a central processor with a relatively small memory of its own . An alternative way of segmenting TUTOR programs that involves link e d i t i n q of unit clusters has been proposed C6J. This scheme relies on the assumption that all units celled from any unit are known at compile time; thus/ it should te possible to build clusters pf units such that inter-cluster linkage is minimized. This scheme may be attractive in env i ronrrent s where large seqment sizes are acceptable/ hut constructs such as -imain- Csection A. 1.1] may invalidate the obove assumption. The TUTOR units on PLATO are compiled into two components: The instruction part of a unit is a list of 60 bit entries containing encodings of the command names and parameters or pointers to other information. The second part of each unit holes the additional information reouired by the commands in the first part. The consecutive list of commands in the first part of the unit simplifies the linear search for certain commands used by the judging mechanism [appendix AD. Paqe 6 Pecause many TUTOR commands invoke complex system functions at run time/ or amount to complex service subroutine calls* TUTOR programs will always consist largely ol the computation of parameters to system subroutines. Directly compilinq TUTOR code to machine code could consume unreasonable amounts of time and space because of the expense of conventional calling sequences- On the other hand/ qiven the paged virtual memory capabilities that are becoming common on medium scale machines* some de -emphasi zat i on of the TUTOR unit would be desirable. If T U T < R is to be supporter 1 in a demand paging environment/ it would be useful to merge the two components of each unit in order to improve program locality. The MULTITUTOR i mp lement ot ion [17/183 has achieved this meroer by including in the 6f bit code for each command a pointer to the next command/ allowing the continued interpretation of judging semantics in terms of a scan of the (linked) command list. In fact/ the run time scan can be fully eliminated from the interpretation process [chapter 33. i I 2.1.2. STUDENT OR USER VARIABLES Each user of a TUTOR program has a unique array ot 150 words that may bf used for user dependent computation. These user variables retain their values when a user chanues programs/ and they are saved when a user is not on the system; tnus/ they may be used for inter-prooram parameters and user related historic data so lona as all prowrams involved agree on the use of each location. There is no automatic storage allocation mechanism/ nor is there any Page 7 dynamic storage management system for user data* though it is hoped that some form of both will be introduced in the future. One of the basic assumptions inherent in the design of TUTOR is that all data types will fit in one machine word. As a consequence/ TUTOR aoes not need or have any data type enforcement or checking; instead/ the dcta type must be provined with each iremory reference. For example/ 'n1' refers to the first available location as an integer/ 'v1' refers to it as a tloating point number/ and alphanumeric data must be stored packed in integers. This assumption is acceptable in the CERL implementation where the machine word size is 6 bits/ but on the majority of available machines in the small to medium size range/ the common 16 or 32 bit word size could pose a problem. The word length must be comparable to 60 bits in order to allow simple program interchange with PLATO; on smaller machines/ representing a TUTOR word as 6 4 bits is reasonable as has been previously proposed C6D. f'any available machines in the target class have standard hardware available to do 64 bit floating point arithmetic/ but the integer representation poses some problems as 3 2 tit inteoer arithmetic is the largest commonly available on such machines. Representing integers by the 3? most significant bits has been propose i elsewhere [ 6 D but could introduce many problems in program conversion because of the amount ot explicit bit manipulation that TUTOR encourages. For the Same reason/ the sign bit must be the most significant lit/ so integers may be represented either by the Page 8 least siqnificant 32 bits of a word with sign extension/ or by the full 6 A bits using software simulation. Both of these alternatives would add greatly to th' size of programs compiled into machine code and significantly increase execution times in any implementation. Thus again/ some form of interpretation seems preferable. P.1.3. COMMON OR COMMUNICATION VARIABLES An important capability of multiple user on-line computer systems that is frequently not well supported is inter-user or inter-pronram communication. Many timesharine systems allow user tasks to communicate only by shared disk files or other slow and inelegant means. The UNIX syste n L16J provides a special type of logical file called a 'pipe' which may be read from by one task after beinq written on by another. TUTOR provides common variables as a solution to this problem. If i. program uses common variables/ all users of that program will share the same copy of them (as oppose d to user variables which are unique to each user). In addition/ common variables are also preserved when no users are attacheo/ so they may be used by the prooram to record historic information and constant data. Critical section manc-qement for access to common data is provided by the -reserve- and -release- commands which operate on semaphores associated with each named common block. On PLATO/ common variables are stored in ECS/ to use them a m^ppinc must be established between the ECS copy and a 1500 word central memory buffer accessable by the user prooram. This mapping Page V is implicit if the size of the common is less than 1500 60 bit words/ but must be explicitly stated for larger commons/ and may be changed at run time. Given paged virtual memory hardware instead of word addressable ECS/ these arbitrary mappings n\py be quite difficult to support. Fortunately* only about one fourth of all existing TUTOR programs use common variables at all/ and of these only a fraction use more than the 1500 word limit; thus/ the translation costs imposed by incompatibility in the support of large common regions should not be objectionable. * ■ < 2.1.4. ST0RAGT OR EXTENDED USER VARIABLES The 150 word limit on the number of user variables poses a severe restriction on the utility of TOTiR for solving many classes of problems. Because the 15 user variables retain their values between sessions for any oiven user/ it was not considered practical to expand this limit on PLATO/ instead a new oata space called "storaoe" was introduced. Storaoe is statically allocated for each program/ hut the system must allocate it dynamically to handle transfers of control from one program to another. I'nlike common or user variables/ storage is always deallocated when the user leaves the system. Storaoe is allocated on PLA10 in ECS/ and the same mapping mechanism is used to <',ain access to it oS is used for common variables. Cn PLATO/ all disk input output must take place to ECS (storaop or common). Because of this/ the most frequent use of storaoe on PL'TO is for disk buffering; incompatibilities in the support of this will probably be tolerable. I aoe 1(1 2.1 .' W-e I AHLb SFGMb I 1 IN;, As was previously mentioned/ the TUTuR language relies on the assumption that any machinF word may hold any data type, f ven on a was provided by special commands that manipulate character strings oackeu 10 six bit codes per 6 r J bit word. This partial solution prove ' indoequdte* and a eneral solution was provided in the ability to sec; went blocks of physical words into arrays of smaller logical words. It is the intent of TUTOR that a reference to an element of a serj'ented array should be equivalent to a reference to a machine war ; in all contexts. F-ecause of the basic desiqn of the PLATO implementation* this intent is not yet fully supported/ but Given the forekno*ledqe that it should be/ any new implementation shoula no so from the beginning. i ?.?. PR0C-.F''* FEPRESFNTATTOM Pecause access to s^omented variables and integer arithmetic must both be subroutines on a 3? or V> bit machine* ana because almost all of the TUT^R commands are sub r out i no -I i k e with many parameters and complex side effects* tht time overhead of intermedial code interpretation as compared to direct machine code execution should not be too excessive. Page 11 Execution by source interpretation would be prohibitive because of the cost of lexical analysis rnd run time symbol table maintenance (TUTOR mrtkes no variable print n me restrictions analooous to those of BASIC). Given that source compression is required* compilation of expressions to postfix form* with interpretation by means of a virtual stack machine provides an obvious choice. The stack in such a scheme can also te useo for action routine argument passing ano for user procedure linkage* as well as for temporary storaoe when needed by any of the action rout i nes . On the toroet class of machines* an right bit instruction syllable is reasonable* with 16 bit branch and data address fields. Because of the existence of user* common* storage* and segmenteo variables* oata address fields must also contain an indication of which data space or subspace is to be addressed* as well as the word size and characteristics of that space. The use of 16 bit branch addresses limits the program size to 65536 bytes* comparable to the 8000 60 bit word limit that used to exist on PLATO. l*ost oi the information about each of the many address spaces and segmented subspaces can be storeo in a table of space characteristics. with this scheme* e o c h memory address must contain an index (< bits) into this seqment table* *s well as the 16 bit offset into the desired addressino space. It shoulo not be difficult to extend this scheme to rnulti-dimensional arrays as has recently been done on PLATu. This scheme should te contrasted with the hardware data descriptor schemes of some machines [15]. Page 12 The assionment of values to entries in the segment table would le the responsibility of the compiler if the PL £ TO definition of TUT R is retained; however/ it is a simple extension to allow run tinu redefinition of table entries. Ihus/ this nemory addressing mech-nism can easily be extended to support dynamic allocation of temporary variables on the stack. Interpretation of an intermediate code similar to that outlined above can be quite f3St. The code accomplishing the action specified by any particular instruction can be prefixed to code that fetches the next byte from the instruction stream, increments the program counter/ and branches through a jump table indexed with the byte fetched to the next action routine IAD. As mentioned earlier/ all parameters to TUT OK commands can be passed on the interpreter stack. ' iven an alternative to the run time scan of the command list that some commands require/ the various commands may then be represented in the intermediate code by a trefix byte followed by an h bit command code. This allows the definition of 2 5 e> commands per available prefix. Parital specifications for such an interpreter are presented in appendix E i examrles of commands compiled into this code are presented in appendix C. 2.3. DATA PfcPPESENTATION The alternative representations tor inteqers have already been discussed [section 2.1.23/ and as was mentioned/ the reasonable choices are interpretive simulation of full 64 bit integers/ or use Page 13 of • vailable hardware 3? bit integers with sign extension to 64 bits provided i nte rpret i ve I y . The letter alternative- is probably preferable because there are few problems requirinq the use of 64 Dit integers* and the simulation of multiplication and division to the full precision can be quite slow. The PLaTO harOware only supports int'oer operations for the *-8 least significant bits of the 60 rit word* and it is not likely that the the difference between 48 and 32 bits will cause many problems. Because of the practice of dealing with character and bit strirns packed into words as integers/ the integer comparison and bit manipulation operations must always work over the entire word s i z «. . The largest remaininu data representation problems occur with character drita. Many programs on PLATO rncke explicit use of the packinn of ten 6 bit character codes per machin< word; and until recently* it was common practice to make explicit use of the specific 6 bit codes for various characters. Ur ti>e letter reason* it has been suTaested Co] that the PLATO " bit codes be preserved and packed into machine bytes with high order bits unused. Since that suqqestion was made* use of quo to character literals has been stronaly encouraged on PLATO* so any character set will trobably be acceptable as long as it is extensive enough. Thouqh many simple CAI programs may survive the change from ten 6 bit to eiqht M bit characters per word* this change may be responsible for the greatest conversion costs for many of the more interesting programs on PLATO. On the other hand* preservation of Page n the current PLATO character set (on machines with natural addressing to t> bit bytes) could introduce what may be an unacceptable execution overhead on smaller machines/ as well as making PLATO software incompatible with other software already existing on the host machine. One problem that may invalidate the assumptions ebout the use of the natural addressing capabilities of some machines is that TUT'R proqrrms frequently make explicit use of the left to riyht storage of bytes end seqmented variables in a machine word. This will require interpretive intervention if TUTOR is to be supported on i-ny of the large family of machines that store bytes from right to Left in memory. P a q e 15 3. JUDGING OR INPUT MANIPULATION The response judging capabilities in TUTOR serve two separate purposes. First* they provide the user with well structured access tc ?. set of powerful primitives for requesting terminal input* rejecting that input* or requesting that the input be modified. Secondly* they provide access to a powerful set of character string and numeric rxpression analysis facilities for the evaluation of the terminal input. The response judoing subset of TUTOR was originally conceived as a mechanism to be used for computer quiz administration or similar applications where the computer would present a question and decide which of the responses anticipated by the program author most closely resemble! the answer aiven by the user. After having decided which response to the question was given* the program had the alternative of accepting the response or rejecting it. It the response was rejected* the pro-ram could provide appropriate feedback to the user* after which the computer would automatically request that the user modify the response before re -subm i 1 1 i n«i it to the prooram. 3.1. THf RFSPCNSE JUDGING MECHANISM Once the input has been accepted from the terminal* there are a numter of ways that it can be analyzed. TUTOR provides analysis routines that will compare the input with a character strino for an exact match* evaluate the input as a simple numeric quantity* Page 16 evaluate it *s an expression/ parse it into words/ or both parse and compare it with a predefined vocabulary with allowance for simple spellinq errors. All o + these capabilities exist on other systems/ though it is uncommon to find them all in one system. The recuireo analysis methods are disjoint/ and can be inaividually implemented by conventional means. The actual input analysis mechanism for use on a small machine is a separate problem 1253/ and the mechanism used on PLATO hds been described elsewhere [23J. The input output requirements ol TUTOR judqino are considerably more complex than conventional unit record approaches [chapter 6]/ but the complexity is not outside the range of adaptability of some vendor supplied systems [23. The remainder of this chapter deals with alternatives for the implementation of the prooram control structures defined by the TUTTiR judging mechanisms. 3.2. FFFECTS OF JUDGING ON PROGRAM STRUCTURE The control structures proviaed L y TUTOR tor response judging are described by the FLAfO project in terms of a number of program execution states/ where each command may have a different meaning in p required to he in the same unit or proqram segment as the -arrow-. Secondly/ all simple branches into and out of the ranee of a judging ulock must be forbidden. These rules correspond closely to the traditional rules of structured procrammino where unrestrained branching is limited/ and control structures may be nested but not arbitrarily overlapped. 3.2.?. CONDITIONS FOR RESPONSE EVALUATION The 1 judqinq commands in TUTCR fall into two classes: Those that are considered judging commands because they require the input to r> e ready before execution/ and must therefore be executed in judging state/ and those that actually perform some judgment/ ending the judding state with an "ok" or "no". The judging commands may be interspersed with regular commands/ but in judging state/ only the jud nnn commands are executed; th is suqgests linking each judying command to the next by branches that are conditional on judging state. This may be considered to be merely the removal of the regular commands from the linked command list implementation of MULTTTUTOR 117/18]. Page 19 When an -endarrow- is encountered in judging state/ the judoment is "no"/ so the interpretation of all -endarrow-s as being preceded by an implicit -no- command is safe (the -no- command is defined as always endino judging with a "no" judoment). 3.2. '. FXECUT10N OF BLOCKS CONDITIONAL ON JUDOMENT With the addition of the branches from -endarrow- to the first judging command/ and from each judginq command to the next/ it is rather easy to follow through to the end: Any judging command after the first one/ in a sequence that is preceded by regular commands/ must be preceded by a conditional branch back to the location after any previous -specs- command/ or to the -endarrow-. There is an exception to this rule when the previous judging command was -specs-; in which case/ the branch is always to the -endarrow-. These branches are conditional on the state beinc postjudging reqular/ and they accomplish the eventual transfer of control to the -endarrow- where the decision is made whether or not to loop. The maiority of TUTOR judging blocks are actually quite well structured. ?hey typically consist of a loop terminated by an "ok" judoment. The loop contains an input request and a series of blocks of rode executed conditionally on the results of the various judging commands. Appendices D.1 and D.? illustrate the reduction of a TUT' R judgino sequence to a flowchart/ and from there to code in a well structured form. Niote that the inclusion of post -specs- regular commands requires the use of Zahn's event driven block exit [5,12,26] . Page 20 3.2.4. JUDGING AND SUBROUTINE CALLS One of the difficulties of compilinq TUT.'R that will be oiscussed in more detail in chapter u is that it is not possible to specify that a unit is only to he used as a subroutine/ as an extension to another unit/ or is a main program/ in fact/ it is perfectly possible to use a single unit as all three/ though this may be considered bad practice. For tbr purposes of this discussion/ it is sufficient to know that there are two types of subroutine calls in TUTOR: The first o1 these/ the -do- command/ is a reqular command/ and is the most commmonly used. The second is the -join- command/ this is ; somewhat confusing command because it is defined as being executec in 3 L I of thf> TUTOR execution states. If a unit is entered while in judqing state (via -join-)/ Xhi search for a judging command must continue. This may b< accomplished by following the unit entry with a branch on judoin< state to the first judging command (if any) in the unit (to the en< of the unit if none ) . When judqinq is ended within a unit that has been attached as . subroutine by -join-/ control must somehow return to the appropriat' place. In that the compiler does not know how the unit is to b executed/ it will be attempting to create a branch to the pre\/iou -sppcs- command/ or some later -endarrow-. One alternative is t define -endarrow- (even if implicit) differently if it i encountered before an -arrow- in a unit or if there is no -arrow- i Page 21 the unit; the compiler may then link all regular blocks controlled by juduing commands to a possibly virtual -endarrow-/ with the appropriate state marker being set before the return. Thr execution of -join- while in search state (that is while searching for the (possibly implicit) -endarrow- alter an "ok" judgment) is not a wiaely used feature of TUTOR/ ana it was not considered necessary to consider it here. There has teen recent discussion of eliminating search state on FLATO and using a compiled branch scheme where each -arrow- would have a pointer to its cor respondi no -endarrow- or equivalent. The problem is then to differentiate all the different execution states that may exist on return from a unit ottached by -join- with conditional branches to the appropriate places: One branch should be to the next judging comnana it still in judoing state/ the other to the next -enddrrow- if in post ' pseudo' -endarrow- state/ and finally no branch if in any of the regular states. 3.3. INTERPRETER MECHANISES AND THE COMPILER The adoption of the division of control structure semantics and int°rpretation/ as outlined above/ provides the necessary flexibility needed to support alternate source languages that share the same execution packaoe. This places a considerably larger burden on the compiler than the PLATO scheme/ but it broadens the r a n o e of alternative execution schemes. Paqe 22 The various states that have been mentioned so far for judging purposes may be reduced to a 4 bit 'nibble* appropriate tor testiny with simple conditional branches. The required bits are listed in appendix B.1.1, and the test and branch commands in B.3.1. Appendix D outlines the compile time expansion process by which various TUTOR commands arr converted into assortments of conditional branches on status^ and calls to unconditional utility routines. Paqe 23 4. UNITS OP UNIVERSAL PROGRAM SEGMENTS As well *s beinu the basis of the virtual memory scheme on PLATO* TUTOR units may be used as subroutines by the -do- or -join- commands. Units may also be attached as logical continuations of othor units by the -coto- command/' or they may be used as new main program segments by the jump commands (not only -jump-* but also 'key arming' commands). 1.1. THE DIFFERENT USES OF UNITS 4.1.1. AS MAIN PROGRAM SEGMENTS A unit to which control is transferred from another unit by the -jump- command* by one of the interrupt facilities* by sequential entry from the previous unit* or as the first named unit of a new program is executed as a main unit. On entry to a main unit/ the subroutine linkage stack is cleared* the screen is erased* and if the feature is armed* the unit named as an 'imain' unit is called as an initializing routine by a call equivolent to the -do- call. Tb» most obvious approach to providing the special effects on entry to a main unit is to implement them as side effects of the various commands that can start main units. This is the approach used on PLATO* but it has the undesirable result that the int'Tpreter code used for entry to a unit would not be usable for a language where the type of a program segment is not bound by how it I is reached* but by how it is defined. Page 24 An alternative met bod exists for the compilation of main units in which each unit beqir, s with a special commanc responsible for all of the side effects of main unit entry. All commands that enter the unit as a main unit takp the address of the side effect command* and oil others (such as subroutine entry and -ooto-) take the address followina it. This provides for a complete separation of the control structurinn commands from their TUTOR sicie effects at the expense of one or two extra bytes per unit. Uhen control reaches the end of a main unit/ (includinc passing the implicit -endarrow- of section 3.2.1)/ execution holds until the user directs it to continue (by pressing the NEXT key). When ready/ control transfers to either the next unit in sequence or to the unit specified in the last -next- command (if there was one); in either Cose/ the new unit is entered as a main unit. These functions can be accomplished by a special end unit instruction. 4.1 .2 AS SUBROUTINFS TUTOR provides two kinds of subroutine calls which differ only in their relationship to TUTOR judging [section 3.2.4], Clearly/ an essential requirement of subroutines is that they return when completed. This may be accomplished by having the end unit command (mentioned in the previous section) execute a subroutine return if thp current unit was entered as a subroutine; but/ to allow future experiments with alternatives to units/ it is simple to explicitly compile a conditional subroutine return just before the implicit end unit comm and . Page 25 4.1.3. AS INTFRRUPT PROCESSING ROUTINES In an interactive environments it is important to allow the user some way of easily alterinu the flow of program execution. It is easy to tfink of this ability in terms of allowing the user to interrupt one process and initiate another/ possibly with a return to the first when the second is finished. TUTOR allows a special qroup of keys on the terminal keyboard to be a r m e c 1 with unit names to provide a qood approximation of this. Whenever input is requested from the terminal and one of these armed keys is struck/ a -jump- like transfer of control takes place to the associated unit. There r re two types of interrupt-like tranches allowed in TUTOR. The first is simply a user initiated -jump- which is associated with keys such as BACK and STOP/ and provices no real implementation prohlem. The second type of interrupt like -jump- allows a return to the point of interrupt at a later time. This typt/ most freauently associated with the HfcLF and TFRtf keys on the keytoard/ poses the major implementation problems. The ideal behavior of a HFLP type branch would be for the units attached by it to be executed as subroutines/ with the entire execution status beiruj restored on return to the point where the interrupt occurred/ and with allowance for nesting of HELP interrupts. Unfortunately/ the status that would need to be saved includes the entire content of the term i n a I display and input line editinq buffers at the time of the interrupt. On the PLATO system/ with its 512 by 512 dot addressable screen/ this would entail the storaje of over 256K bits of information per level of nestino. Paqe 26 The solution adopted in TUTOR* l reasonable one/ is to return to desionateo point before the point where the interrupt occurred* allowin- for the regeneration of the screen contents and for the reinitiation of any input transaction that may have been interrupted. The restart point in TUTOR is the start of the most recent main unit entered (called the base unit). when a HELP type branch occurs* the BACK key ir, armed in the new main unit to jump bock to the base unit. TUTOR does not allow true nest ino of HELP sequences* rather* it allows the arminq of the HELP key within such sequences to branch to new -help- sequences without chanqinu the base unit pointer. Thouqh the base pointer may be manually cleared or set* it is normally cleared by followinq the specially armed BACK branch. Tht recent addition of the -helpop- mechanism to the repertory of TUTOR key arminq commands poses different implementation prorlems. H"~re* subroutine like unit attachment occurs when an -'op- typp key is pressed*" except that the -'op- unit returns to the point just before the command which was interrupteo* and a siqnifiqant amount of judqinq state information is saved if an -'op- unit is activated within a judqing sequence. The PL '"TO mechanism for supporting TUTOR -help- type branches nnd returns i nvolves tne use of two pointers* one to the current main unit entry [;oint* and one to the current base unit. This scheme is not only adequate for a small machine implementation* but easily lends itself to experimentation with nestinq of interrupts by savin q and restorinq the base unit pointer durinq procedure linkage. Page 27 4.1. 4. AS CONTINUATIONS OF OTHER UNITS Thp -ooto- command in TUTOR simply transfers control to the named unit without any change to any of the program status* includino memory of the location of the previous -arrow- (if present). The resultant interdct ion of -goto- with the judging mechanism includes such thinqs as returns to the last -arrow- and state changes. Because of these pathological cases/ -tioto- poses problems to a new TUTOR implementation. The -goto- command is incompatible with the compilation of branches proposed in chapter 7> as a solution to implementing TUTOR judging sequencing. Fortunately/ the use of this aspect of the TUTOR lanauaae is not encouraqed/ is it is difficult to explain the unexpected results. Because of this/ and in keeping with the rules mentioned in section 3.2.1/ the use of -joto- from within judging sequences may bp forbidden (in almost all cases/ -do- can be used to achieve the same function much more clearly). 4.2. FARAMTFRS TO UNITS Somewhr-t late in the history o ♦ TUTCR/ in f , c t after much of the initial work on this project hao been complete d / the ability to pass parameters with any direct control transfer to a unit was introduced. Previous programming : ractice in TUT(R hod generally included the allocation of fixed -j roups of user variables to each unit that needed parameters/ and then assigning values to each parameter before each call. When the passing mechanism was introduced/ it was made completely compatible with that approach; Page 2b that is/ parameters in TUT^R involve no temporary storage or local variables . fnven c stack based interpreter/ the obvious implementation is to push all of the parameters onto the stack before a call and pop them into the appropriate locations after entry into the new unit. There are two complications to this scheme: One involves main unit entry which must pop the subroutine linkage stack; the other involves thp fact that with any call/ a subset of the parameter list may be passed with only the corresponding locations being changea in the called routine/ the other parameter locations retaining their previous contents. Because parameters may be passed not only with -do- -join- and -qoto- but also with -jump- and/ with trivial extensions/ -nextnow-/ the first problem occurs. If parameters are passed on the stack/ , the commands that start a new main unit must then copy any parameter t' lock down the stack when they undo the procedure linkage. This requires that a count of the n umber of parameters be stored above the parameters on the stack. The count must be on the stack because the 'imain' unit/ if present/ will be done by the begin main unit command before the code to resolve the parameters. The second problem may be solved ry passing/ as an additional parameter/ a bit vector indicatina which parameters are present. Thii bit vector must also oive the types of each parameter (integer or floatinq) because TUTOR performs automatic conversion of parameter types/ and the requirements of fast compilation preclude a nlobal first pass to work out the types expected with each unit. Page 29 Given a 64 bit wide stack and usinq 2 bits for each parameter/ while reserving 8 bits tor the previously mentioned count/ a total of 2b parameters may be passed. This scheme is compatible with the eventual implementation of temporary local data allocation tor units using the single stack. The same calling sequence would be used/ while the receiving sequence could set up some special segmented variable [section 2.1. SI to a 1 1 o w addressino of the parameter list ana new local storage instead of copying the parameters into fixed locations. 4.3. INTERPRETER MECHANISMS AND THE COFPILtk 4.3.1. PROGRAM STATUS INFORMATION The unit sequencing mechanisms outlined above require that the prooram status contain at least i main and base unit pointer/ and thr f p more status bits that may be tested in a manner similar to those used for judging. One status bit would re requirea for the parameter parsing mechanism/ indicating that parameters exist on the stack and must be stored. The second status bit indicates that the current unit is beinc executed as an attached unit by -do- or -join-. The third bit is needed to differentiate -help- from -help op- type unit attachment when the base pointer is non zero. Tn addition to this/ the program status must contain space for a return address for -do- and -join-/ and somf mechanism for nesting these calls. The minimum information that must be saved for nested calls consists of the return a i dress and parameter status bit. Page 30 Saving and restorina the other linkage bits would not cause conflicts/ hut the judoinq status hits must not be saved and restored^ as they are used to return results of judging operations in joined units. Saving and restoring the base pointer would allow future experiments with -help- type interrupt nesting without conflicting with the current TUTOR definition. The use of a single stack for the return linkages as well as intermediate results/ parameters/ loop control blocks/ and future procedure local variables requires that the program status also contain a special linkage pointer to the previous program status block on the st?ck. A. 3 .2 STANDARD CALLING AND RECEIVING SEQUENCES The actual call generated by a -do- or -join- command must consist first of reserving space on the stock for linkage/ then placing the optional parameters on the stack/ followed by the bit vector qiviria the count/ types and positions of the parameters. After this comes the actual subroutine call or branch which must have/ as in line arguments/ both the address of the unit to be executed and a parameter presence indicator (so that the linkage can be correctly placed in the stack). If a unit expects parameters/ it must begin with a branch coniitional on their absence around the parameter recieving code. The parameter recievinq code consists first of the computation of all of the addresses/ followed by the execution of the parameter resolution command which stores values in addresses with optional Page 31 float inq or fixing (as indicated by the parameter presence bit vector and the type information supplied as part of the addresses). The process of parameter resolution pops the values and addresses/ which is why the linkage must be stored below the parameters on the stack. At the end of each unit/ after the (possibly virtual) -endsrrow-/ a return must be inserted conditional on the subroutine status bit. Page 3i TUTOR CONDITIONAL AND LOOPING. COMMANDS All but the most trivial of programs must make choices am repeat various sections of code. TUTOR provides a number o mecr^nisms for this/ ranginq from simple conditional branch command to conditional and looping variants of other commands. 5.1. CONDITIONAL COMMANDS A large number of commands in TUTOR have conditional variant in which the command is executed with respect to one of a group o parameter lists dependent on an integer selector value. Command with conditional variants include flow of control commanos such a -branch-/ -^oto-/ and -do-; key arming commands such as -help- display aeneration commands such as -writec-; and computations commands such as -calcc- and -calcs-. There may be any number o' choices in these conditional forms/ the first one being selecte when the selector is neoative* the second on zero/ the third on one and so forth. These conditional variants spread to a large number of TUTO commands at a time when they were the only control structure allowed within the body of a unit besides those associated wit judging and subroutine calls. On P14T0/ the conditional and simpl form l of a command ore not compiled into variants of the sam intermediate code command/ but into different intermediate com mane which need not have related interpretations. Page 33 It would qreatly simplify the interpretation process if the conditional aspects of a command were compiled so that all commands would have a fixed format from the point of view of the interpreter; this requires that there be a compiler generated directive for selecting from a list of commands and parameter lists. This is analogous to the way -case- statements are handled in many languages with a branch indexed through a table. Appendix C.3 contains an example of the expansion of a typical TUTOR conditional in terms of the instruction set of appendix F. 5.2. LOOPING COMMANDS The looping variants of the -do- and -join- subroutine calls in TUTOR were/ for a long time* the only way that a block of code could oe repeated/ except by the use of conditional -noto- or -jump- commands. These looping variants take an incex variable* initial value/ final value/ R commands/ which are adequately discribed in other references [11 ,19D. B.1 .1 4 JUDGING STATUS BITS/ NOT SAVED IN LINKAGE 0000 - Regular state. 0001 - Post -iirrow- regular state. 100C - Judging state (searching for judgment). 0100 - Post judging regular state/ "ok" judgment. 0010 - Post judoing regular state/ "no" judgment. 1100 - Searching for -specs- with "ok" judgment. 1010 - Searching for -specs- with "no" judgment. 0101 - Post -specs- regular state/ "ok" judgment. 0011 - Post -specs- regular state/ "no" judgment. 1101 - Searching for -er.darrow- with "ok" judgment 1011 - Searching for -endarrow- with "no" judgment B.1 .2 4 UNIT TYPE «ITS/ SAVED IN LINKAGE 1xxx - Parameters on stuck to be resolved. xlxx - Unit entered by -do- or -join-. xxxl - Reserved for future experiments with -helpop-. B.1 .3- OTHER PARTS SAVFD IN PROCEDURE LINKAGE PC or INTERPRETER PROGRAM COUNTER; this is a 16 bit pointer into a vector of 8 hit bytes (the program space) BASE UNIT POINTER; this is a 16 bit pointer into the program space for interrupt return applications. LINK or STACK LINKAGE POINTER; a 16 bit pointer into a vector of 64 bit elements (the stack) This pointer is used to allow recursive and nested subroutine calls. Page 59 FJ.1.4. OTHER PARTS NOT INVOLVED IN LINKAGE MAIN UNIT POINTER; a 16 bit pointer into the program spsce copied from the program counter on main unit entry SP or STACK POINTER; a 16 bit pointer into the strck used by all computational instructions and all parameter passing mechanisms. The push operation increments the SP before stcrinq a value/ and the pop operation aecrements after recovering a value. B.1.5. SEGMENT DEFINITION TABLE This table has 32 entries/ containino: Segment base address/ 16 bits. Seqment entry size/ 6 bits specifying number of bits per entry Si?n extender/ 1 bit specifyinu that entries are signed. Floater/ 1 bit specifying entries in floatinc point format. The first four entries in the segment table are predefined to: 0) System wide status variables (a special common block). 1) User dependant status variables. 2 ) User variables. 3) Common ^ n d storaoe share this. 4) Router variables (if implemented). b .2 . DATA FORMATS P. 2.1 SIMPLE DATA TYhF.S Integers are stored as 64 bit two's complement values. Integer arithmetic operations use only the least significant 32 bits ana sign extend their results to 6A lits/ comparison operations work over the entire 64 bits as do bit manipulation operators. Floatin point data is stored format supported by the host machine. in the 64 bit floating point Page 60 Alphanumeric data is stored in 8 bits per character/ with the least significant seven bits interpreted as ASCII when the most significant bit is zero/ and as additional PLATO characters when the most significant bit is one. When a I ph a numer i c data is packed into integers* the last or rinhtmost character occupies the least sianificant bit position. boolean data/ which is produced as the result of comparisons/ and is interpreted by the branch on false instruction/ is compatable with PLATO and the table lookup branch: true is -1 or negative and false is zero or positive. P. 2. 2. MEMORY ADDRESS ^RMAT Memory addresses may be provided either as significant three bytes of a 6 4 bit stack entry consecutive bytes from the instruction stream in some format is as follows: the least or as three cases. The XXSSSSSF 00000000 00000000 where X is ignored/ S indicates which segment/ and specifies an offset from the base of that segment in terms of the word size of that seament. r indicates the type of the data that the location is expected to holci (0=integer/ 1 = real). P.?.? LOOF CONTROL BLOCK FORMAT STACK LSP3 = increment value. STACK CSP-13 = limit value for index. STACK CSP-rD = initial value for index STACK CSP-3D = memory address of index P. 2 .4 LINKAGE WORD FORMAT The current linkane word occupies one st^ck entry and is pointed to ty the LINK register when executing within a subroutine. There are fields in this word for all the data of P. 1.2 and b.1.3. Paoe 61 R.2.5. PARAMETER TYPE V.ORt) FORMAT The parameter type word occupies one stack position and consists of: ?P entries givinu information about up to 28 parameters/ and an 8 bit count of the number of parameters immediatly below this word on the stack, the least significant entry corresponds to the topmost element on the stack below/ the most signifigant fc bits are the count. The two bit fields for each parameter have the following meaning: Ox - parameter missinq (no corresponding stack entry). 10 - the corrpspondinr word is an integer. 11 - the corresponding word is floating point. 1*2.6. MASK PYTES FOR STATUS TESTING A numter of interpreter instructions test the bit patterns of b.1.1 and B.1.2 with the aid of a mask. *ll such masks have the common format: 11112222* where the bits marked 1 are those of B.1.1/ and those marked 2 are R.1.2. B.2.7 SPECIAL DATA IN THE PROGRAM SPACF When constants requirinq more than P bits are stored in the pronram space/ they ire stored most significant byte first. This holds for 16 bit proaram space adaress constants/ 24 bit data address constants/ and 16/ 32/ arid 64 bit integer constants. P. 3 INTERPRETER INSTRUCTIONS The instructions listed Fere provide the needed support for TUTOR/ and thf required computational ability. The actual TUTOR action routines are not listed here. Each instruction is identified by its first f bits/ the instruction number. The action routine for each instruction may consume additional bytes containino constant data or addresses/ but almost all instructions are fixed format; ir they may consume an extra byte of information/ they will almost always consume it. Most instructions also have a fixed effect on the stack/ always reading and popping or creatine and pushing a fixed numher of entries. Instructions that need variable numbers of parameters are implemented with a well defined fixed (art containing the ipecifi cat ions of the variable parts. Page 62 B.3.1 £2 PI EXECUTION SEQUEf'CE CONTROL INSTRUCTIONS <»5 ftt #10 *M1 »12 (i'13 <16 <1ft <8 If th th ma by va <16 us If ou i s i s fl ty CO <16 Us St ch th bl nt eg cou p is t he the pop ddre oop i nc ound f ro . T and i cat bloc ddre o op- he i f it c h i ped . sk> sk> ask> ask t is r am SL- to t f th ro I ask> or I he m ram to b ask> i s fere ssk> call s s> : ss> : <16 er vr nt, t neaa dddre va lu ed f r ss> : cont r r emen s/ th m the his i fixe ed by k . ss> : cont r n i t i a is w s tak branch b ranc h bit add lue of he coun t i ve / - ss spec e plus m the pos t in 1 bloc tinn/ t en the stack; nst ruct d point the ad prechec o I bloc I va I ue i t h i n b en and to that address. on false and pop stack. ress>: table lookup tranch. the stack top is ore t e r t is used as a value. If 1 is used. A branch is ified by the woro addressed the oiven address/ and the stack. d e x check and branch. k on the stack. he index valup is stack control tlock otherwise the branch ion works tor both on the basis of the dress in the stack k loop encJ branch. k on the stack. in the i nde x / then ounds . If not/ the stack control <16 bit address>: branch on status set. <16 bit address>: branch on status clear. <16 bit address>: Call, indicates parameters on the stack/ obtained from the parameter type word, status save word is stored in st ^ck count/ and the L I n K woru is hat location. The least significant e mask replace tne linkage status bits/ is transfered to the address. : return conditional on any of the inkage status bits matchinc those ask. The return consists of fetching status save word from the location y tho link. <16 bit address>: branch with parameters, ored with the status byte end control d to the add r ess . <16 bit address > : -do- -join-. exceot -do- -join- Lit is set automaticlly Page 63 #14 #15 016 <8 bit mask> <8 hit mask> <16 bit address>: special status checking branch. If any status bit matches a bit set in the first mask and no bits match the second mask* then branch. <8 bit mask>: set bits in status. <8 bit mask>: c I r a r bits in status. 3.2 DATA FETO AND STORE #20 #21 #22 #24 *25 #26 #27 #28 #29 #32 #33 #49 #50 <24 <16 Form S i an <8 b prov <64 <32 <16 <8 b rep <24 sto Repl the <24 pop rep <8 b bits bits at X i f iq its idin bits bits bits i ts lace bit re d ace or iq bit wor I i ca it s of of XSSS ont of d n se of of of uf d add addr ata t he i ona addr d f r tew i g n e data data SSF byte ata> qmen data data data ata> ress ess> thro addr I co ess> om s ord d va >: > : 00 O t >: > : > : ug e s py ta on lu pus pus 0000 f th conv info pus pus pus push n st push h ad s w i of st or ck. sta e>: h immediate address onto stack. h immediate short address onto stack 00 (see B.2.2) where the most e offset is assumed to be zero. ert integer to aadress by rmation. h immediate 64 bits onto stack. h immediate 32 bits siqn extended. h immediate 16 bits siun extended. immediate ft bits sion extended, ack with the data it points to. data from immediate address, dress below it on stack, th the data* and pop the data from the stack. e data in immediate address. c k t op . modify S F by addinj value. PINAFY INTEGER OPERATORS #55 #56 #57 #58 #59 #60 #61 #6? #63 064 #65 replace the top two stack elements by their sum subtract stack top from the value under it. multiply. divide the stack top into the value under it. produce the remainder as in division. (SP-1)=(SP) replaces the elements compared. (SP-1 >\= (SP) (SP-1 )> (SP) (SP-1)>=(SP) (SP-1 )<(SP) (SP-1 )<=(SP) Page 6A b.3.4 BINARY FLOATING POINT OPFRATORS #66 #69 *70 <>72 "73 + 7U *75 '-•76 £77 repl.ce the top two stack elements by their sum subtract stack top from the value under it. mult i p I y . divide the stack top into the value under it. (SF-1)=(SP) boolean comparison for equality. \- > > = < < = E-.3.5. POOLF/iN AND BIT OPERATORS #P0: boolean and #L1 : boo I ean or . fib?: boolean exclusive or. #*3: bitwise and/ mask/ or H h 4 : bitwise or/ merge/ or #85: bitwise exclusive or/ #*6: logical left shift (SP-1) #87: logical right shift. »:&: arithmetic riaht shift. #F 9: circular left shift. of the top two stack elements. intersection operator. union. or difference. by (SP)/ pop count B.3.1* COMPLEMENTATION OF STACK TOP H 9 : #91: t9?'. *9lr INTFGFR FLOATIN BOOLFAN BITWISE N F G A T E POINT NOT . NOT OR NEGATE . ONES COMPLEMENT P . 3 . 7 ODDS ANT FNDS # *■> 5 : convert inteqer to floating point on stack top. t;9 6: convert floatino point to integer by truncation. ff^7: integer part floatino point number in floating point. H9c : fractional part of floatino point number. #99: convert floatino point to inteoer by rounding. -100: replr.ee stack top with integer count of 1 bits in it. #105: convert coarse to fine grid (replace top by two words) Page 65 B.3.E. FUNCTION LIBRARY *12F: 0129: #130: *131 : 0132: #133: MAO: U 141: (M42: #143: #146 : #147: rep I cosi t ann arc arc arc lo. 1 logo ant i ant i expo squc *ce stack top with sine of stack top (floating point) ne ( radi ans). ent . sine. cosine. tanqent . 0. I o o 1 . I o g e . nent i at e . re root . B.3 SPECIAL TUTOR COMMANDS #251: begin new main units reset all but parameter bit in program status/ copy any parameters down the stacks erase terminal screen and reset mode. If an ' i m a i n ' unit exists^ call it with no parameters. ft 253: end main units wait for any armed keypress or NEXT. If NEXT is pressed and there is a desionated next unit to branch to do so^ otherwises fall throuah to the next unit when NEXT is pressed. #255: prefix for other TUTOR commands Paqe 66 APPENDIX C - INTERMEDIATE CODE COMPILATION EXAMPLES C.1. EXPRESSIONS TUTOR CODE: cdc n1 : =n1 +n (n2 : =n2 + 1 ) INTERMEDIATE 1 #20 2-4 5 #49 6 #28 7 #20 8-10 1 1 #49 12 #28 13 #27 U = 1 15 #55 16 #32 17 #22 18 19 #28 ?0 #55 ?1 #32 22 #48 CODE/ COMMENTARY: rush cddress onto stack 24 hit address of n1 replicate address fetch n1 push address onto stack 24 hit address of n 2 replicate address fetch r>? push constant onto stack 8 hit const ant 1 i nt eqe r add n2 + 1 store n2 : = n2 + 1 convert the sum into an address make it n(n2:=n2+1) fetch n(n2:=n2+1 ) inteqer add n1 +n (n2 : =n2+1 ) store n1 : =n1 +n (n2 : =n2 + 1 ) pop the stack to its oriqional state C.2. SIMPLE COMMANDS TUTOR COD F: the code for -at- (pops 2 parameters) C.3. CONDITIONAL COMMANDS Page 67 TUTOR CODE: coles n1 *n2 : =n3/0*-n3 INTFRMEDI ATE 1 #20 2-4 5 *29 6-8 9 #3 10 = 1 11-13 = 36 14 #29 15-17 18 #1 19-20 = 40 21 #27 22 =0 23 #1 24-25 = 40 26 #29 27-29 30 #90 31 #1 32-33 = 40 34-35 = 14 36-37 = 21 38-39 = 26 40 #32 41 #48 CODE AND CO push z th push d ad table th th push d ad br anc h ad push i z e branc h ad push i ad i nt epe branc h ad t 3ble table t sble store pop r * WMEN dare e ad at a dres look e nricj e ata dres to dres mmed ro to dres rom dres r ne to dres addr addr addr r esu suit TARY ss i dres from s n1 up b x imu ent r from s n3 end s of i at e n which to store result s of n? immediate address ranch m i nde x i s 1 y o * the jump table is at 36 immediate address of conditional end constant end of cond i t iona I s of end immediate address s n3 qate -ni end of conditional s of end ess for neqative index ess for 7ero index ess for positive index It in adaress below it value off of stack 5 »27 6 = 1 7 027 8 = 100 9 »27 10 = 5 11 tit 12-13 =21 14 *13 15 =0 16-17 = n <»5 19-20 =14 Dush index address onto stock address n1 push initial value onto stack vnlue 1 push final value onto stack v< lue 100 push increment value onto stack v. lue 5 loop control block ^rerheck and setup address beyond end of loop -do- -join- no parameters address of entry point loop rontrol block post index and branch address of top of loop (C.4. LOOPING COMMANDS continued) TUTOR CODE: rioto 1 lab^ril : *1-0>'2#-1 branch n(n1)/2lab/X/1lab n(n1) :=-1 11 ah ?lab Page 69 INTFRMEDIATE CODE/ COMMENTARY: I #20 push. address 2-4 address of n1 5 #27 push immediate co 6 =10 initidli ndex 7 #27 push immediate co 8 = 2 f ina I i ndex v 9 tt?7 push immediate co 10 - - 1 ir. crementvat II »6 loop control bloc 12-13 =49 address beyon 14 #29 push from immeaia 15-17 address of n1 18 i>22 convert integer t 19 specify stude 20 #28 fetch n(n1) 22 #255 TUTOR command fol 23 £ conditional bra 24 =-4 pop 4 levels be 25 =1 maximum index v 26-27 =4*5 address for ind 28-2^ =0 no f ranch on in 30-31 =44 address for 1 o 32 #29 push d eta from im 33-35 rddress of n1 36 #22 convert n1 to the 37 space attribute 38 #27 push immediate 8 39 =-1 const ant 40 #32 store n(n1):=-1 41 #48 pup h?ck to the I 42 #50 prepare for label 43 =-4 Lytemporaril 44 #50 1lab is here/ rec 45 =4 by restoring. 46 #5 postcheck loop co 47-48 =14 address of to / loop index nstant value nstant a lue nstant ue k precheck and initialize d end of loop te memory adaress o add ress of nits of data oop control block i nsi cie loop y poppino loop control block over loop control block stack pointer ntrol block and loop back p of loop Page 70 />PPFNDIX D - COMPILATION OF UNITS AND JUDGING SIQUENCES of * or r t of this appendix is an example of the structure TUTOR. This is useful as a basis The first pai ■ j udge no write k Page 71 0.2 A STRUCTURED REDUCTION OF THE SAME CODE arrow (1010); writeC'a"); REPEAT input I BEGIN UNTIL specsl OR specs?; IF it-is("h") THEN ELSEIF it-is ("i") THEN {no;urite("j");specs1} ELSEIF i t - i s ( " I " ) THEN {ok;write("m");£pecs2} ELSEIF it-is< M n") THEN Cn6;write("o M );spccs2> WHEN specsl: writeC'f"); specs?: writeC'k"); END UNTIL judqedok; Note that the UNTIL clause is d declaration ot the exit blocks that actually occur in the WHEN clause. This notation is an adaptation of that employed by Knuth L1?D. Paqe 72 P. 3 fARTIM COMPILER SPECIFICATIONS FOR TUTOR JUDGING "Data definition for compilation of TUT< R judging" T Y F T r o m m a n a = (abort/addlst/addl/allow/ ... /wronv/zero); states = (s_renulor/S_postrirrow/s_post juduino/s_pnstspecs /s_judqina/S_specs#s_endarrow); link - "defined bv procedures " ; "Imjortnt powersets of commands" CONST always_ends_judginq = fok/no/in^tch/ ... } ; sometires_ends_judqinn = tans we r/wronu/Stcre/ ... >; never_pnds_juo«]in( | = state" "foreword branch iri {s_postjudeinq/S_specs> state" "foreword branch in -Cs_postspecs/S_endarrow> state" "branch in s_postarrow state" "foreward branch in s_judging state" "foreword in {s_jud"inn>+(n_reaular--Cs_reqular}) M Page 73 "Main compilation control variables" state: SET OF states; "This variable identifies the set of states in which" "the code being compiled is expected to execute. " t hi s_command : command; "This variable identifies by name the command for" "which code is currently beinq generated. " no_ar row_in_un i t : boolean; "This flag is used to select between the two possible" "types of -endarrows- (-ea- for joined unit or normal)" i nput _r equest ed : boolean; "This flag is used to guarantee that the 'first judging "command after the arrow' is well defined" "Procedures for code generation" PROCEDURE codeout (b:byte); "places the value of in the current location" PROCFDUPE undefined : I ink ); "causes all previous uses of to bt for 9 often" "raises an error if has occurred but there" "has been no " PROCEDURE defined : I ink); "causes any instance of < t o d ) > to qenerate 2 b y t <* s " "in the binary image that refer to the current location" "raises an error if has already occurred" PROCEDURE to(l:link); "generates ? bytes of address in the I inary image" FUNCTION definedd: link) -.boolean; "TRUE if has been executed" FUNCTION used( I : link) : boolean; "TPUE if has been executed" "Other procedures external to this definition" PROCEDURE compi le_tag (command) ; "performs a non context dependant compilation of the command" "The main procedure tor compiling a line" PROCEDURE compile_a_line; H E G I N CAbE this_command OF unit : entry : arrow : join : spec s : endarrow : ne ve r _ends _ j udq i ng : sometimes_ends_judaina : always_ends_judging : ELSE end; END " compile_a_line"; c _uni t ; c_ent ry ; c _ar row; c _ j oi n; c_spec s; c _ e n d a r r o «( ; c _ w e a k ; c _st rona; c_stronger; compi le_tdi(this_command) P a y e 7 4 "C omm PROff B t (. I N and specific code neneration procedures D U R F c unit; END ASSERT state IN o.renular; c _enoa r r ow / PSSFRT state IN {s_renular}; ASSFRT i nput _reque s t ed - false; IF u sed ( L _endun it) THEN PFMN define(l_endunit ); unc ef ine( L_enaunit ) ; state := stat e + ; codeout (b_dojoin) ; codeout (o_end_main_unit); end; compile_ta^ (unit); stcte := g_regular + -Cs_judoinq}/' codeout (o_tranch_i t_set ); codeout ); IN {s-re~ular}; r eques ted = false; = O ) PPOCFDUPE c.mtry; FECI N ASSERT state IN g -regular; c-enda r row ; ASSERT state ASSERT input, IF N0T( state THEN BEGIN codeout (o_hranch) ; to(l_regular); stte : - { > ; end; coirpile_ta<: (unit); s t . < t e : - gregular + Cs_judc; codeout ( o _ t ranch_i f_set ); codeout '» st.-te : r state - {s_judqing}; define(l_rpaular); un oefine (l_regular); no_arrow_in_unit :=- true; END "c_entry"; Paqe 75 PROCEDURE c.srrcw; BEGIN ASSERT state IN g_reqular; c_enda r row ; ASSERT state IN ; ASSERT i nput .requested = false; compile_tao(arrow) ; state := {s_postarrou>; no_a rrow_i n_un i t := false; END "c arrow"; PROCEDURE c_join; BEGIN ASSERT state IN g_regular; IF used(l_j udq i ng) THEN PFGIN define(l_judginq); undef ine( l_judqinq); st.te := state + -Cs_judginq>; end; IF (NOT def ined( l_input ) ) Af^D ((s-postarrow) IN state) THEN def int (l_input ) ; comp i I e _t ao (do ) ; state_changes_in_joined_unit; IF {s_ j udqi na} IN state THEN BEGIN codeout (o_branch_if_set_reset ); codeout (b_search); codeout (b_ok_no_specs); t o ( I _ j udgi ng ) i end; state := state - {s_judging>; IF IN state THEN BEGIN codeout (o_branch_if_set_rPset ); codeout (b_search); codeout (b_specs); IF detined(l_specs) THFN to(l_specs) F LS E t o ( I _mar kup ) ; end; state :- state - (s_specs); IF (s.pndarrow) IN state THFN P E (-, I N codeout (o_branch_if_set); codeout (b_search) ; to(lendarrow); FND end; stite ASSERT c_ jo in = state - {s_endarrow>; state IN q_regular; t aoe 76 procedure c .specs; E E G T N ASSERT state IN g.regular; pre_judqinq# ASSERT ^tate IN { s _ j ud -i ng} ; IF {s_juaaing} IN state THEN P F 6 1 N corrpi I e_taq(specs); corteout (o_branch) ; to(l_judginq); TND r L S f error (' command will never be executed* ); unuefine ( I specs); aetine(l_srecs); st. te:= {s-specs/S-postjudqina>; codeout (o_markup); stite:= IN state THEN BEGIN con.f i le_taq(this_command); codeout (o_branch) ; to(l_judge); stte := <>; FND FLST frrorCcommanci will n^ver post _j udqi no; END "c veak"; be executed')/' PROlLDUPE c_strnn,; P E 6 I N » S pr AS IF TH IN q renuUr; LND bN v>o ■c SERT state e_ j udo in g ; SERT state IN (sjud^nq); •Cs_judr;inci> IN state FN Pb t, IN c o rn p i I e _ t a q ( t r. i s _ c o m m a n d ) ; st. te := state + is _pos t j udgi no) ; codeout (o_branch_i t_set ) ; coceout (b_search); to* I _ j udge ) ; st-te := state - \s_juciginq); D ELSF errorCthis command will never be executed'); st _ j u<" ii no ; s t r o ' 1 1 " ; Page 77 PROCEDURE c_stronger; REGIf* ASSERT state IN g_regular; pre_jucfainq; ASSERT state IN {s _j udoing>; IF IN state THEN BEGIN com pi le_tao(this_command); state := {s_post j udgi np>; END ELSE e rror (' command will never he executed'); post_ju'Jging; END "c stroncer"; PROCEDURE c_endarrow; BEG I n ASSERT state IN g_requlsr; IF no_ar row _in_uni t THEN PEG IN IF IN state THFN BEGIN codeout (o_branch_on_reset ) i codeout (b_search_ok_no_specs) ; to(l _regu I ar) ; fnd; state := state - {s.reoular); IF NOT( state = O ) THEN HEGIN codeout (o_branch); to(l_end_unit); fnd; s t - 1 e : = O ; IF (u sed ( I _ma rkup) ) OR (used ( I _enda r row ) ) THEN l) EGIN~ Jef i ne ( I _markup ) ; -iefine(lendarrow) ; unde'fine (l_markup) ; un define* l_endarrow) ; codeout Co_set_status) ; codeout (bsearch); state := state ♦ (s.endarrow/s.specs); end; IF used ( I _ j udoi ng ) TFEN TEG IN ^efine(l_judaing); undef ine ( l_judqinc); state := state ♦ ; end; IF NOT( state = O ) THEN TEGIN codeout (o_branch); t o ( I _endun it); end; Page 7* "c_endarrcw ... continued" fND ELf>F F3FGIN "there wis a previous arrow in this unit" pre_judoino; ASSERT st^te IN < s _ j udc. i n j>; IF fs_judginq} T N state THEN i E 6 I N rompile_taq(no); :t?te := ; IF def i ned ( I _specs ) THEN RFGIN codrout (o-branch); to(l_specs); state : = O; F N d ; end; ASSFRT state IN { s _po s t j uric, i nq 3 ; IF used(Lmarkup) THEN n F 6 1 N refine(L_fnarkup); undefine ( l_markup) *" state := state + (s_spec s / s_post j udc i ng> ; end; IF ( IN state) OR (-Cs _post jurioino} in state) THENfEuIN rode out ( o -markup) i state := {s_postSfecs>/ end; ASSERT state IN {s_postspecs>; If use d ( I enda r row ) THEN l-EGIN r'efine< l_endarrow); un ciefine ( l_end arrow) ; state : =■ state + (s_endarrow/S_postspecs)» END ; IF ({s_postspecs> IN state) OR ({s_endarrow> IN state) T Hf N • F 6 I N rodeout (o_endarrow) ; st«.*te := (s„postarrott/s_reouldr); codeout (o_branch_if_set ); codeout (b_search); to(linput); state := state - < s_post a r row) / e \ d ; F N d ; post _jud'nno; unoefine(l_specs)/* undefine (I _input); input reouested := false; r,o_arrow_in_unit := true; ASSERT -jtate IN {s.recjldr}; E ND "c endar r ow "; Page 79 PROCEDURE BEGIN ASSE IF { THEN end; stat IF i. THEN end; Stat IF i THEN fnd; Stat ASSE IF N THEN end; if i THEN pre_j udgi ng; RT state IN g_regular; s_rer»ular} IN state BEGIN cooeout (o_branch_on_reset ); codeout (b_search_ok_no_specs); to(l_regular); e := state - ; s_post j udgi ng} IN state BEbIN codeout (o_branch_if_reset ); codeout (b_search_specs); IF aet ined ( I _specs ) THEN to(L_specs) ELSE to(l_markup)/' e := state - ; end; FND "pre_jud< ini"; PROCEDURE stte_ch?nqes_in_joined_unit; !• E (i I N IF IF (s_rost arro "th( joined "th'n if it " j u , q inq st IF THEN ■Cs _ i udvi i "th« uni "a j udo i { s _ p o s t j st te := "th unit "a -judqe nu) t i no ud : = s i c FND "a j udoing IF -Cs _post s pec M th> unit i "then a jud s t . < t e changes i w> I un i con ate IN s jo comm inq} tate s en ont i comm s> 1 s en q i n 3 n_jo N st t is tain wi 11 stat i ned and IN + { t e re nue- and N st t ere com i ned ent s a be e TH i n may stat s _ j u d in may may ate d i n mand un i T H E N ered j U d q ent e EN s j ud j end e dcj i n or r ee caub THEN or may t"; stnte := state ♦ ; enters postjuuqino state" nter judginq state" e it to enter search-specs" state := state + {s_endarro enters posts pecs state" st.rt endarrow search state >; nq>; te" w>; PRUTEDURt p o s t _ j u d q i n q /* PEG IN IF used(l_renular) t h r n p r ( i n define r>; E N D ; END "post _ j udni nq"; APPENDIX F - TERMINAL TRANSMISSION CODES AND BUFFERS E.1. THE TRANSMISSION CODE/ AN EXTENSION OF ASCII E.1.1. PRINTING CHARACTERS Page 81 1 First Digit 23456789ABCD E F m sp J& @ P * P - Tf 1 » 1 ft Q a q Oi 2 ■ 2 B R b r P P 3 # 3 C S c s 2 C 4 $ 4 D T d t A S 5 % 5 E U e Li 6 & 6 F V f V 7 • 7 G w g Ul - e fa) 8 ( e H X h X n 9 ) 9 I Y i y u ft * • • J Z J z X B ♦ • » K [ k { ♦- < C > < L \ 1 1 # 1 4 X ■ D - - M 3 m } * -♦ j* > E . > N * n *v > t «M F / ? o + > ♦ Page «2 E.1 .2 CONTROL CHARACTFRS (COLUMNS A N D 1) HEX: NAME: USE: rr NUL 01 SOH 0? STX 03 ETX 04 EOT cs FNQ 0* ACK 07 PEL 0* BS OV NT OA LF OR VT oc F F OD CP OE SO OF SI 10 DLE 1 1 DC1 12 DC2 13 DC3 14 DC4 1 5 NAK 16 SYN 17 ETP 18 c a r. 19 EM 1 A SUH 1R ESC 1C FS 11) GS 1 F RS 1 F US i mor ed home (X,M set 0/ Y snt AV«S). use normal character set Csee t.1.13. use user provided charset Csee DLE], ■force buffered material to screen. * * * onqu ire *** acknowledge ring be I I . backspace (X set X - P ) . tab (on input only). linefeed (Y set Y-16). vert ical tab (Y set Y + 16) . tormfeed (screen erase/ home/ mode write) carriage return (X set M/ Y set Y-16). superscript (Y set Y+'O keyboard SUPFR1. subscript (Y set Y-5) keyboard SUM. data a t m dot line ex te * * * *** * ** cane set SubS esca touc f^xt e * block prefix (binary data/ charsets) . ode. (followinq non control codes ..) mode. (. are interpreted in oroups ..) .mode (. of 3 as screen coordinates ) nded graphics mode (for smart terminals) negative acknowledge synch ron i se tnd of transmission block el (reserved for special editing), mode (following byte is mode), titute - set fth hit in next character, pe to special controls Csee t . 1 . 3 J . h control (following byte is data), rnal device prefix (text mooe). *** communications control * unassioned Page 83 [.1.3 ESCAPE CHARACTERS (COLUMNS 8 AND 9) FSCAPE KEY: HEX NAME : EDITING FUNCTION: S A B C D E F G H I J K L M N 80 81 8? 83 8 A 85 86 8 7 88 *9 £A ^P 8C <^D *F STOP DATA LAB BACK NEXT HELP ANS COPY EDIT ERASE ( squn re) MICRO SUPER SUB copy one word restore word from line buffer erase character copy one cha rac te r 90 91 9? 93 94 95 96 97 9F 99 9A 9B 9C VD 9E 9F ST0P1 DATA1 LAB1 BACK1 NFXT1 HELP1 TkRM C0PY1 ED1T1 FRASE1 copy rest of copy rest of erase word line edit buf f er (square ) 1 FONT MICR01 { TIMEUP i SUPFP1 is 0E ) SUB1 is OF } Page 84 F . ? . BUFFER TYPES HETWFEN INTERFRETtR AND DEVICE HANDLER To the user task/ the terminal is accessed as two separate virtual devices. >ne device/ the "line editor" provides services thot are a superset of the services provided by the standard teletype handler; this device provides all of the line editing and input echoinc services. The other device/ the "key queuer" manaqes the collection of input characters/ with provisions for non-echoing input such as the TUTOR -pause- and -collect- as well as the -press- service which simulates a keypress at the terminal. < wr i t e> software line editor <(...use> -*- < p r e s s > — key queuer har dwa re d i s p I a v s c r een k e ybna rdl The following sections are user interface specifications for these virtual devices in terms cf the input/output functions of the MAX IV operating system on the KodComp IV computer. All of these input output functions take as their parameter a 'users file table' which contains the parameters (or pointers to parameters) for the c a I I . Paqe 85 USERS FILE TABLE FORMAT FOR TRANSACTIONS -1 Inte Poi r { x x Tra Fi I <01 Opt Tro Sys {01 Ir'ys I np Buf rpre t at nt er to ' f e r e n c x xx xx7x DE=xO: = f 1 : = 11: 7 : use nsac t io e n b m e 2345678 ir =NT : fo 7 = R M Q : s f=TBX:i 5 = R A :us 4=AH6:u 7 =B J :bi 2=STD:s 1=DD0:d = Sr. :sy ion a I t nsfer c ten use ?34xxx8 DEF : edi - x x 1 = x 1 x -1xx F C : line s : u = 01 :w = 1 x : d c A : eras = x 1 :e = 1 x :e ' : f o r c e 4=UPP:u ■• = I U S : s ?=0FT: s 1=Rf?R :u HsQR : sy tern def ut/outp f er s i z 1 o es x x e r wr u r al n (a x x r vs nh p se na t a ev st i m ou o 9A t i :e : c : i e a i a i on ur ra r a I s e ys ys se st i n ut e n ( j k e a xx D ase ite ite t e r st a ss i xxx key tern iM wor wo ry nda ice em er/ nt n I y BCD nq dit opy npu dit t i t f •t e r se se onf uc tern t em r e em ed. bu (op "for s y- or 256 b Ex) 1 char er ds with nat e tus w qned xx) 1 queu def i t var d 3 ( rds - t rans rd tr depe def i n sere ret ur i n y I e -paus it (16 6 bit acters i nq ba ove r s char ac ord (s to key 6 bit er L se ned i ous e ot he rw 1 and f e r mo ans f er ndant ed. en p o s ned he E F > 16 bit buffer to u bits/ act if set): e- keylist (optional) word ) vector . echo mode (optional) ckqrcund t r i ke t e r set . ystem defir.ea). queuer or line editor), option wo rd e E.2.33 d i t i nq act ions i se i ano red ) -? (ditto) de mode Csee F.2.2, t.2.51 ition/ or pointer to Same re after transaction. extended option word SP i ng cont ro I or function or any keyp wait equ i r ed for last output last input rd 5 as co i def i n e d defined oisters ins def i ned . keypress r es s edit i no nter to 3? bit value tead of words S and 9 ffer address (optional), t iona I ) . Paoe K6 1.2.7. TRANSACTIONS DEFINED TO THE LINE EDITOR MODE (selected by bits STD and BIN of word 2, E.2.1.) CALL read wr 1 1 e STD . ASCII NONSTD. ASCII STD. BINARY NONSTD. BINARY one line in (7 bit chars) one line with crraqe control one recoru in (8 bit chars) one buffer with emoeded cont ro I chars reserved for ST,drt terminals r p served for s in a r t term inn Is get contents of i ndi cated buffer set cont ent s of indicated buf f er s rewind (erase screen/ clear all state information) oackfile (ignored) backrecord (ignored) advance rpcnrd (clears line editing state) advance file (see rewind) write end of file (see rewind) homt- (see rewind) The nonstandard binary read and write transactions use only the buffer specification option bits in the extended option word. On read only one buffer may be specified. The nonstandard ASCII read interprets all of the option bits in the extended option word. The buffer specification bits specify which (if dny) of the buffers should be cleared before any other processing takes [lace. The standard ASCII redd defaults these options so that the read behaves like a read of one line from a t e I et ype . All ATCII reads interpret the DDO bit as inhibiting prompting for input (prompts consist of an arrow [>3 preceded by a carrage return if th< RA bit is not set). All writes may interrupt all reods/ with the read beino automatically resumed ("as if" there were no interruption) when the write terminates. In addition/ the DDO bit (when used with write) causes the current display mode and location to be saved before the write and restored afterwards (i.e. for system messages). If a keylist is present/ bits set in it correspond to characters that will terminate the current reaa. Tf such a list is not present/ only thp NhXT and CR keys will be active. In the standard ASCII read/ the terminating key is never returned; in the nonstandard ASCII read/ it is always returned as the last item in the buffer. E.2.3. TRANSACTIONS DEFINED TO THE KEY QUEUER MODE (selected by bits STD and BIN of word 2/ E.2.1.) Page 87 CALL STD . ASCI I NONSTD. ASCII STD. BINARY NONSTD. BINARY read from queue (7 tit chars) from queue (fc bit chars ) ignored i gno red writp line of keys with Corraqe cont rol list of keys with embeded cont rol chars i gnored i gnored rewind (dumps the queue) bac k file ( i ono red) back record (ignored) advance record (inserts NEXT in t,ueue) advance file (see rewind) write end of file (see rewind) home (see rewind) The DDO option for all of these transactions causes the queue to he cleareo before processing continues. The NT option applies only to the read operations* and causes a wait until the number of keys asked for can be tronsfered. If the NT option is not selected* the reao operations will return only those keys currently in the queue* or nothing if none were currently queued. If a keylist is specified* it is usen to filter the input returned to the user* i.e. keys not in the list *ill be discarded instead of being placed in the users buffer. BLIOCRAPHIC DATA IEET 1. Report No. UIUCDCS-R-77-868 Tit le and Subtitle Run Time Support for the TUTOR Language on a Small Computer System 3. Recipient's Accession No. 5. Report Date May, 1977 Author(s) Douglas W. Jones 8. Performing Organization Rept. No. Performing Organization Name and Address Department of Computer Science University of Illinois Urbana, IL 61801 10. Project/Task/Work Unit No. 11. Contract/Grant No. 13. Type of Report & Period Covered Master's Thesis Sponsoring Organization Name and Address Medical Computing Laboratory 190 School of Basic Medical Sciences University of Illinois Urbana, IL 61801 Supplementary Notes Revision of Masters Thesis deposited with the University of Illinois in May, 1976 14. Abstracts This report contai VTO computer-aided in Cementation on a sma ;ir reasons are outli ?c i a 1 emphasis is pi a -ge PLATO system. Appendices contain lents of the implemen Iging control structu ' the user terminals, the interpreter. ns an analysis of the TUTOR programming language used on the struction system. The analysis centers on the requirements for 11 to medium scale computer system. Implementation choices and ned, and the results of one such implementation are presented, ced on the desire for program transportability to and from the descriptions and specifications of the critical software com- tation, including compiler specifications for TUTOR'S response res, input/output interface and character set specifications and specifications of the framework and basic instruction set .Key Words and Document Analysis. 17a. Descriptors igramming Languages npilers terpreters >ut/0utput Routines (ching Machines I -Machine Systems ' Identifiers/Open-Ended Terms ITO (computer system) LOR (programming language) 7 COSATI Field/Group 81 vailability Statement 1 NTIS-3B (10-70) 19. Security Class (This Report) UNCLASSIFIFT 20. Security Class (This Page UNCLASSIFIED 21. No. of Pages 92 22. Price USCOMM-DC 40329-P71 '<* ? «o