Digitized by the Internet Archive in 2013 http://archive.org/details/csminiapplicatio937schr Cc ^JIUCDCS-R-78-937 ^plcxttL UILU-ENG 78 1732 CSMINI - APPLICATIONS OF A MINI PROGRAMMING SYSTEM ON PLATO IV by Axel T. Schreiner August 1978 CSMINI - APPLICATIONS OF A MINI PROGRAMMING SYSTEM . ON PLATO IV by Axel T. Schreiner 1978 Sektion Informatik University of Ulm We st -Germany The work reported here was performed 1975/1976 while the author held a visiting appointment in the Department of Computer Science at the University of Illinois at Urbana Champaign. A part was added during another visit in summer 1978. TABLE OF CONTENTS 2. 2.1 2.2 2.3 2.4 3. 3.1 3.6 4. 4.1 4.2 4.3 4.4 5. 5.1 5.2 5.3 5.4 6. 6.1 6.2 6.3 Introduction 1 The Mini Programming Systems csmini 4 Purpose 4 Lesson structure and design principles 4 The minilanguage 12 An example: Hilbert curves 14 Implementation notes 17 csminiadm 21 Purpose 21 Design considerations 21 Lesson structure 22 Implementation notes for the filing system 26 cstrees 28 Purpose 28 Lesson structure 28 The minilanguage 29 An example: insertion into a preorder - sorted tree 33 Implementation notes 36 Implementation guide 37 buffering 38 Purpose 38 Lesson structure 38 The minilanguage 41 An example - buffered input 43 semaphore 45 Purpose 45 Lesson structure and synchronization principles ... 45 The minilanguages 50 An example: Dijkstra's P and V primitives 53 Other Applications csdesign 55 Purpose 55 The editor 59 The compiler 61 TABLE OF CONTENTS (Continued) 7. csflow 64 7.1 Purpose 64 7.2 The editor 66 7.3 Implementation notes 70 Open Questions 74 References 78 LIST OF FIGURES 1.1 Standard Lesson Structure ( csdesign ) .... 5 1.2 Catalog Entries ( csmini ) 7 1.3 Program Editor ( csmini ) 9 1.4 Text Management in the Program Editor ( csmini ) 10 1.5 Plotting Hilbert Curves (csmini) 16 3.1 Threaded Binary Trees ( cstrees ) • • • • 32 3.2 Insertion Into Preorder-Sorted Tree . ( csf low ) 35 4.1 Buffered Input ( buffering ) ... 40 5.1 Workspace Directory ( semaphore ) ... 48 5.2 Mutual Exclusion Using the P and V Primitives ( semaphore ) ... 49 6.1 Lesson Execution Simulation (csdesign) .... 56 6.2 Compiled Code ( csdesignc ) . . . 57 6.3 Lesson Graph Editor Options ( csdesign ) .... 60 7.1 Flowcharting Principles ( csf low ) 65 7.2 Flowchart Editor Options ( csflow ) 68 Progress Plane Simulation ( deadlock ) .... 76 ACKNOWLEDGEMENTS H. George Friedman, Jr. has maintained the computer science lessons on PLATO ever since the "Automated Computer Science Education System (ACSES)" has been under construction. Without him, most of this lesson material would not at all be in the reasonable shape it is in. He also reviewed all the lessons described here, and he has managed to keep them operational in spite of a few rather severe "minor PLATO system changes". My students in Operating System Design and Information Structures in spring and summer 1976 were the first ones to use most of these lessons. They coped with sometimes unfinished lesson skeletons and their experience provided substantial feedback. Judy Sherwood and the other PLATO consultants helped me a number of times to untangle my code. Since some of it is rather obscure, although well intended, this was not an easy task and I thoroughly ap- preciate their continuous efforts in aiding PLATO authors. After an abortive attempt at optical character recognition of this report in Ulm, Roletta Fields proved that being able to ask a secretary to type it is still the most pleasant way to produce a paper. To all of them go my thanks. A.T.S INTRODUCTION PLATO [Smith & Sherwood 76] is an excellent medium to teach and practice, e.g., introductory computer science material. Within the ACSES project [Nievergelt et al. 76] lessons were developed which now present half of the usual introductory programming instruction at the University of Illinois. The system was less successful in more advanced computer science applications, mostly because space and execution time constraints limit the complexity of the instructional approaches. It was possible, pri- marily for elementary numerical applications in calculus, to implement a subset of BASIC as a PLATO lesson [White & Schreiner 78], and using the same techniques a FORTRAN compiler- interpreter was also developed [White 76] . Within the ACSES project a major effort was directed at implementing small subsets of a number of conventional languages [Wilcox 73]; the resulting table-driven compiler family produces excellent and extensive diagnostics [Davis 75, Tindall 75] but it definitely exceeds PLATO's processing capabilities and it has thus been more or less abandoned. Implementations of standard languages on PLATO suffer from the fact that their interpretive execution usually requires a massive amount of character manipulation. The customary postfix-based expression eval- uators are necessarily quite time-consuming to run and thus severly limit the amount of numerical processing which such an implementation can support. The lessons described in this report attempt a different approach to supporting advanced programming instruction on PLATO. The author lan- guage TUTOR [Sherwood 77a] supplies the compute statement which will compile 2 and evaluate a characterstring conforming to TUTOR' s expression syntax very efficiently. Additionally, a define statement permits a static (lesson-compile- time) declaration of names and functional expressions; those names and functions are then recognized in compute expression elaborations. It is thus feasible to support a language in a PLATO lesson, as long as that language uses predefined names and conforms to TUTOR's expression syntax.* Sherwood [77b] has already demonstrated on PLATO III that a minilanguage for quick curve plotting can be defined and supported in this fashion. This report will show a number of much more complex applications, mostly in data structure manipulation and systems pro- gramming, which can be efficiently realized by a suitable minilanguage in the TUTOR style. The mini programming systems described in this report cannot make any attempt at program verification. They provide only a simulation setting in which a particular problem solution can be viewed in operation. Obvious bugs cause execution to terminate, but subtle logical error diagnosis is left up to the student. While this is not satisfactory if the goal of PLATO usage is independence from any human instructor, the lessons have still proven to be a useful device to accompany conven- tional instruction; all the mini programming systems have been used in courses on Operating System Design and Information Structures (CS 323 and CS 321 in spring and summer 1976) . The report is intended to serve three purposes: First, the minilanguages are introduced to show what minimal settings are really only required to practice complex concepts such as tree manipulation or * This syntax, although exceptionally close to mathematical notation, un- fortunately gives multiplication precedence over division and is thus not easily exploited to support standard languages. synchronization mechanism implementation. This aspect of the report should be useful for computer science instruction, whether or not PLATO is used. (One of these minilanguages has been implemented in Ulm on a conventional computer system [Schloerer 78]). Second, in presenting application examples it is hoped that these lessons become a standard tool in the repertoire of those teaching the courses mentioned above. This author believes that the simulations demonstrate some difficult concepts a lot more convincingly then a black- board discussion would. Third, parts of these lessons are quite useful for development of new lessons. It was, for example, very easy to construct a lesson to provide a minilanguage for tree manipulation once the basic mini program- ming system was completed. The filing system module has even been employed, with minimal effort, in two new lessons (on lesson structure design and on Nassi-Shneiderman [73] flowcharts) which do not support minilanguages. The implementation notes in this report are intended for experienced PLATO authors; together with the code of the lessons themselves they can perhaps guide and encourage others to construct more mini programming systems . THE MINI PROGRAMMING SYSTEMS 1. csmini 1 . 1 Purpose csmini is a mini programming system in which small recursive algorithms can be studied. Since the PLATO terminal offers excellent graphics facilities, the minilanguage is designed for curve-plotting applications. Following Wirth [76], recursively defined curves can be easily realized. For a PLATO author, csmini should serve as a model implementation of a small programming system. Especially the data structure definitions and the overall design of the lesson are extensively documented and con- structed so as to be easily modified. The parts of the programming system - filing system, editor, and execution simulator - have merely been copied and slightly adapted for the other lessons described in this report. 1. 2 Lesson structure and design principles The programming system consists of a filing system, an editor, an execution simulator, and a help sequence (see figure 1.1, the figure was developed using csdesign ) . The filing system maintains a catalog of systems, each occupying one record in a disk dataset. The filing system is entered from and returns to the table of contents of the lesson. All users may read, write, and delete systems in the catalog. Each system consists of a set of global variables and a workspace (a collection of one or more programs); a system is accompanied by a title for the catalog and a brief abstract. Using the utility lesson csminiadm , a system may be made read-only (indicated by title no base [BACK] iTERMj [DiiTfl Iterm] key help key no Dase (MEXT'j / [HELP] / / Dnteyfts Iterm) sim :>ntents (BfiCK -> TO ■verv 1 ew no base •s. he 1 p i ndx no base / X v \ (next) v x fBflCK0 I'efliMw'fhfc, [termJ work */ IHELPI workspce no base 1.NEXTJ he 1 pwork no base BACK mm [hext) P"!';"'pifcl' •'^le'rfTI miix-iT ed i t or Ihelpi Ir m) ed|t he 1 ped i t no base (§S3£| te simulate workspce IHELPI A fHFJPUn he 1 p run no ba.se Figure 1.1: Standard Lesson Structure (lesson csdesign ) a"*" in the title listing of the catalog; see figure 1.2). Therefore a lesson author or instructor can supply a certain number of permanent examples for the use of the lesson. Normally, systems are password pro- tected: passwords must be supplied upon any access to a system which is not read-only. Therefore a group of students may be assigned a common problem to solve individually. Following a suggestion made by John Risken (Control Data Cor- poration), special entry units to the lesson permit a choice of datasets (mostly for knowledgeable authors) or a preselected dataset other than the standard dataset created by this author (mostly for external user groups) . The available read-only examples in minif ile (the standard dataset for csmini ) consist of various implementations for the space-filling Hilbert-, Sierpinski-, and W- curves [Wirth 76] (see figure 1.2). The workspace editor operates on the directory of programs in the workspace. It is entered from and returns to the table of contents of the lesson. New programs may be added to the directory and existing programs can be changed or deleted. (In designing the lesson sequence, emphasis was placed on efficiency, self -documentation, and simplicity. The programming systems are complete for each application, but rudimentary. This motivates, for example, the absence of copy and rename features in the workspace direct- ory editor) . The program editor is used to create and change a program. It is entered from and returns to the workspace editor, and it operates line oriented on one program at a time. Key to a simple execution simulator is the fact that the program editor is syntax controlled: it permits only the construction of syntactically correct programs. This task, however, is facilitated by an appropriate design of the minilanguage. In particular, the minilanguage must be line oriented and it does not contain compound Hvb. i 1 ab 1 e Sy st ems ( in da t aset m i n i f i 1 e) 1 Hi lfoert Carves Hi Ibert Curves .-- faster version S i erp i nsk i Curves 4 UJ Curves u.i Lurves Chr i s Jenner 6 p 1 ot po I ygon= W Curves -- Bob Roos Curves --- H. P. Clark Select a svst em >> # [NEXT] t * PI'OH-LF'I t HUBSfMEXT] T irlExTl/IPPOM t BBBtBfiCK] t display a system delete a system (without add the present system move in the 1 ist * i Figure 1.2: Catalog Entries (lesson csmini) statements. Each statement consists of a keyword, which the editor expands once the unique first key is pressed, and perhaps parameters such as an expression, for which the editor prompts once the keyword is accepted. Possible statement keywords are displayed on the editor page (see figure 1.3). The editor treats a program as two concurrent stacks of program lines (see figure 1.4). Initially no program lines are saved. New lines are added at the cursor, i.e., pushed onto the program stack. On each line the normal PLATO EDIT key facility is available. The SHIFT-HELP key erases (pops and discards) the last line from the program stack. The BACK key moves the cursor back one line, i.e., the last line is popped from the program stack and pushed onto the save stack. The NEXT key reserves this procedure. It is thus possible to insert and delete lines inside the program; but not to change the order of lines without rewriting some text. Program size is essentially unlimited (all programs together share the keyword and parameter areas in the workspace) but the display on the PLATO terminal screen establishes an esthetic limit of about 20 statements per program. Parameter string length (again mostly for display layout reasons) is limited to about 30 characters. Due to the necessary complexity of some definitions this string length, when expanded by the TUTOR compute statement, seems to approach the limits of the TUTOR expression processor. program. . . Main [helpI CAL.C 1 CALC 2 CAL.C j CrLC 4 PLOT c; SUB 6 IF *V .JUMP o EXIT i*l H<=5 1 2 , screen w i dth x4=y<*-x*x + H/ 2 , Y*y4=y + H/ 2) R : i ( i save 1 ast 1 i ne > nest one next 1 ine cle 1 et e 1 ast 1 i ne 3U. 1 1 .©' STMT, TX1 EXIT Figure 1.3: Program Editor (lesson csmini) Statement headers 10 -(-temporary length-^ -<-saved length- statements saved pointer from code segment descriptor next available statement next available text ward text in use saved -temporary length- text area -saved length- Figure 1.4:' Text Management in the Program Editor 11 The execution simulator is given a program name and a parameter value to start execution, in a workspace; any program can serve as a main routine. The execution simulator is entered from and returns to the work- space editor. Just prior to execution, the values for the global variables and details of the halt condition can be set up. Execution proceeds on a statement by statement basis. Continu- ous execution with a number of monitoring facilities is also available: Once continuous execution is selected, a keypress will stop it (but since the PLATO system queues output, this visual interruption is quite imprecise) , A breakpoint expression can be dynamically introduced which is evaluated prior to each statement and which, when true, interrupts execution. Sym- bolic values can be employed to make breakpoint expressions quite powerful: rtn ... the current program name, loc ... the upcoming statement number. nest ... the current number of nested calls, halt . . . the condition is true if the upcoming statement keyword was flagged prior to execution. Additionally, global and current local variables may be tested. All tests are combined into an expression with the usual TUTOR syntax. The expression rtn = 'seek' $and$ nest > 3 $or$ loc = 2 will interrupt whenever statement 2 of a routine is about to be executed, or before each statement of routine 'seek' at a nesting level greater than 3. (Thanks to the TUTOR compute command, the implementation of this very powerful control feature is quite simple and efficient). Other debugging facilities are a current statement display, as well as a non-assignment expression evaluator which permits inspection of all current values. HELP is available throughout the lesson. However, the sequence of lessons was designed to augment instruction, not to replace it. Each 12 lesson thus provides a help sequence which will discuss usage of the lesson, and perhaps review the illustrated application, but which cannot stand alone. For csmini , HELP pages explaining usage are connected to the workspace directory, the program editor, and the execution simulator. Further pages explain the minilanguage. Additionally, all pages can be read in sequence. As figure 1.1 illustrates, all HELP pages are accessible at all points in the lesson by means of TERM-operations and a table of contents of the HELP pages. csmini is connected to the standard computer science service lessons [Friedman 76] • 1. 3 The Minilanguage The minilanguage for csmini permits recursive subroutine calls, computation, and plotting. It was designed to be extremely simple to learn, easily verified with a line oriented, syntax controlled program editor, and efficiently executed with the TUTOR compute command and a suitable set of define names and functions. These objectives eliminated a number of otherwise desirable convenient language features, but it was felt that in this extremely restricted setting their absence would not distract from the concept to be illustrated by the lesson. The following statements are available: CALC expression THE TUTOR expression (which would usually include assignment) is evaluated. EXIT Subroutine execution is terminated. EXIT from the main routine returns control from the execution simulator to the workspace editor. 13 IF JUMP PLOT PLOT SUB expression The TUTOR expression is evaluated: if it is true (-1) , the next statement is executed, otherwise it is skipped, expression Lines in a program are consecutively numbered from zero. The TUTOR expression in this statement deter- mines the line number of the next statement to be executed. up (expression, expression) down (expression, expression) The program draws on the (0 : 511,0 : 511) PLATO terminal screen. This statement moves the pen to the indicated point, possibly drawing a line, program name: expression The designated program is called as a subroutine with the indicated parameter value. The expressions involve literal constants, variables, and other defined names. All values are integers; expressions follow TUTOR syntax. Since text interpretation was to be avoided, variable names can only be as follows : A...Z global variables, available to every routine nesting level and initialized by the user prior to execution. a...z local variables, available only to the current routine nesting level and initialized to zero when a sub statement establishes a new routine nesting level. The main routine also has local variables. 14 parm the parameter value of the current routine call.. (Read-only) . The symbolic values rtn , loc , nest , and halt , as described for breakpoint expressions, are also available (read-only). Additionally, the vectors Var(l-26 ) and var (1-26 ) can be used to access the global and local variables. 1.4 An example: Hilbert curves Wirth [76] suggests a recursive definition for the Hilbert curves (figure 1.5). The main routine, which is non-recursive, could be coded as follows: calc i ■*= 1, curve index 1 calc H *= 512, plot increment, initially screen width 2 calc x <= y *= 256, start point, initially screen center 3 calc H *= H/2, loop over curve index 4 plot up (X *= x *= x + H/2, pen to start point Y <= y <= y + H/2), 5 sub A : i, curve is plotted as an A segment 6 if (i *= i + 1) < parm, parm is maximal index 7 jump 3, loop to next curve index 8 exit Notes: (1) Comments can be appended to expressions following a comma (a TUTOR compute feature) . (2) The local variables x, y of the main routine monitor the starting points of the curves. 15 (3) The global variable H determines the line segment length, which is constant through all segment routines. (4) The global variables X, Y monitor the current pen position, The recursive curve segment A is if parm < 1, 1 exit 2 sub B : parm - 1, 3 plot down (X «■ X - H, Y) 4 sub A : parm - 1, 5 plot down (X, Y <= Y - H) 6 sub A : parm - 1, 7 plot down (X «= X + H, Y) 8 sub D : parm - 1, 9 exit A (< 1) is just a point add a B segment add an A segment add an A segment add a D segment A plots, from top right to bottom right, three sides of a square, recursively calling other segments (with a lower index) at each vertex. B, C, and D are congruent to A but rotated 90° each. 16 ftE m ake a or eakp DONE oint (l gEHHHD iTli ■"■ how cut rr ent '_•'•_■' de ID Sto) 1 DOk at var i a -A /ZU-~, RO UT IN e: M a i n i_ oc '. 9 n ES t: 1 (H EXT L--S ESJine:- T.L-- [BflC k) to run Figure 1.5: Plotting Hilbert Curves (lesson csmini) 17 1 . 5 Implementation notes The filing system operation is discussed in Section 2.4. Interesting for the interface is only the fact that the available data regions (student variables and storage) are described as two areas: fileQ saved as a workspace by the filing system. bank() not touched by the filing system. Customarily, if storage is used, it would be described as fileQ and bank() refers to all student variables (with the exception of those used for computer science lesson conventions [Friedman 76]); if storage is not used, fileQ and bank() would have to split the student variables. For the programming systems, fileQ generally contains the following areas: global variables usually as 20 bit segments. special purpose area contains at least some pointers delimiting the text-and keyword- areas in use. code segment descriptors describing the routines in the workspace. statement headers containing the statement keywords and possibly pointers to text. text area for expressions belonging to statements. Recursive languages locate their local variables as a stack of activation records in bankQ . The active set of variables is in a fixed position (to improve performance) , a routine call then involves some shifting of local variable values to be inactivated. To improve execution speed all variables exist and are stacked, not only variables actually referenced; routine calls can still be nested aobut 12 deep. Additionally, bank() contains some auxiliary variables. The following strategies are used to obtain write-and sub- script-range protection while using the compute statement: read-only values are defined as 0+location; thus the location may be inspected but not modified. arrays such as Var(i) alias A..Z are defined as follows:* Var(i) - gbl(i+i[i <1 $or$ i > 26]) gbl() is a segment over which the names A..Z are defined in positions 1..26. This name is available but (hopefully) unknown to the student. The subscript for gbl above is whenever the subscript i for Var is out of range; thus, compute will then automatically produce a detectable execution error. The following strategy for the up() and down() functions in plotting is also typical: up(i,j) = 0(gblplot(53) «■ i)(gblplot(54) •" j) gblplotQ are two temporary variables which thus receive the target point of the plot statement with one execution of the compute statement. * Much of this should now be available as TUTOR arrays. 19 This trick requires no explicit text manipulation during the simulation and is thus a very efficient way to gather the data necessary for the plot statement. A workspace mostly contains an area for statements consisting of an area for statement headers and an area for expression text. State- ments for one routine appear consecutively in each of these areas. A statement header contains a code for the statement keyword and (if required) a pointer to the first word of text belonging to the state- ment and a count of the text length in characters. The pointer is relative to the first text word in the routine to simplify compaction of all areas. Among the text words is the pointer required for the TUTOR compute state- ment. Statement headers are packed as 6-bit codes. A code segment descriptor holds a routine name, an absolute pointer to the first statement header for this routine, an absolute pointer to the first text word, and counters for the number of statements defined in the routine and the number of text words used. This information is used to monitor jumps during execution, and it is maintained by the workspace and program editor. The statement area is compacted when a code segment is deleted and the pointers in the remaining code segment descriptors are updated accordingly. When a code segment is newly added or edited, it is always positioned at the end of the statement area — when the area is almost full, editing an existing segment may, unfortunately, become impossible. This policy was believed to simplify text management for the editor (figure 1.4): in order to save the current statement, it is shifted forward to the end of the statement area. Thus the program grows forward in the statement area and the saved statements grow backward. 20 An attempt was made to make the code of the editor easy to extend: two routines, getop and getaux are employed to obtain a state- ment keyword and a parameter expression, respectively. Using the TUTOR store statement, an incoming expression is evaluated: syntax errors can thus immediately be recognized and rejected (only indexing errors and mathematical exceptions must, of course, be accepted). The execution simulator, finally, is straight-forward: once global variables and the halt condition (the latter part of bank()) have been initialized, the simulation proceeds as a continuous loop. Inter- ruptions through explicit keys or the breakpoint expression are considered first. Next, the statement keyword code is used to select one of a number of executors. Finally the loop continues with location counters updated, etc, The executors share an expression evaluator — a compute statement with some error analysis. 21 2 . csminiadm 2.1 Purpose The programming systems such as csmini , cstrees , etc., employ a combination of datasets and TUTOR common storage to realize their filing systems, csminiadm is used to control, expand, and perhaps repair the catalog structure of the filing systems; csminiadm is absolutely ignorant of the contents of a system, i.e., of the interior structure of a record in the disk dataset. A copy of Dave Eland's variable editor from PLATO lesson cslibrary [Friedman 76] is provided to enable the knowledgeable user to inspect and possibly alter this structure also. 2 . 2 Design considerations The filing system for the lessons in this sequence was designed to be generally usable, cheap in resource consumption, efficient and flexible. In order to support various applications, the design should be ignorant of the contents and size of a system (disk record) . As a source of teaching examples, the filing system must provide catalog title and abstract services. Long-term data storage on PLATO is accomplished with a disk data-set - use of such a dataset is permitted only, however, if reasonable limits are placed on the amount of disk access required. In order to make browsing in the catalog a cheap operation, catalog titles and abstracts are maintained in common storage. Each lesson in the sequence, however, operates with its own catalog; each lesson is thus independent of the other lessons. As a catalog grows (more permanent ex- amples are added or a large group of students is assigned a programming exercise), catalog and dataset space must be expanded. It should also be shortened once a programming assignment is completed. Since the catalog 22 data structure is fairly sophisticated, a utility program ( csminiadm ) must aid the instructor or author in these tasks. Common storage in the PLATO system is lesson specific. (This system was designed before name sets and the commonx command became available.) In order to merely maintain one utility program for all lessons, only one common (physically located in csminiadm ) is shared by all lessons. The catalog is saved in the last few records of each dataset used for a filing system and is read into the common as needed. Exclusive access to a catalog for update operations is defined as reserving exclusive use of a common with the TUTOR reserve command. Since it is fairly unlikely that several lessons in this sequence are used simultaneously on the PLATO system, this solution seems a reasonable compromise between resource consumption, (i.e., disk access and memory requirements) and the Control Data Corporation requirement of automating or at least simplifying lesson -dataset- maintenance. The fact that each dataset contains its own catalog, and that each lesson has entry points which permit use of other than the standard datasets, additionally allows an independent group of users to access a lesson with a private catalog of examples and files. An instructor must provide a dataset, initialize it using csminiadm , and route his student records appropriately. (The idea is due to John Risken) . 2 . 3 Lesson structure Access to the lesson csminiadm is available to any user who can attach (i.e., specify on the lesson's entry page) a dataset and who knows it's codeword. Once this information is provided, it is assumed that the user basically understands what he wants to do using csminiadm . A few HELP pages provide information on the services and the catalog structure. 23 The lesson operates in two modes. In non-exclusive mode, the catalog of the attached dataset can be manipulated in the same fashion as in any other lesson using the filing system. Access to the catalog is only temporarily exclusive and any modifications (adding or deleting system descriptions) may be permanent. In contrast, the lesson can also be operated with exclusive access to the attached dataset and catalog. In this case, no other user of the lesson sequence can access any filing system until the user of csminiadm has again explicitly updated or aborted the catalog and released common storage. In non-exclusive mode, system descriptions may be viewed as a student would see them (additionally, parameters such as the password are also shown). Systems can be deleted, fetched from disk (but no further options for system inspection exist), and added. A system is deleted by removing its catalog description from common; the actual system occupies a disk record and is only over-written once a new system is written into the same disk record. (Especially in exclusive mode, catalog manipulation errors can thus sometimes be corrected.) When a system is added, it can be made read-only. The capability to fetch systems from disk and to add systems to the catalog and dataset is intended for copying purposes mostly. In exclusive mode, the catalog may also be manipulated as de- scribed above. Additionally, the catalog parameters (passwords, title lengths, disk record numbers, protection bits, etc.) can be viewed and modified for the entire catalog at once. The catalog for a new dataset must be initialized; existing dataset catalogs can be adapted to allow extension and shortening of a dataset. Defined names of the csminiadm les- son are specified with a TUTOR define student command, (knowledgeable users 24 can thus explicitly modify, and perhaps repair, any parameter); similarly^ a copy of Dave Eland's variable editor from cslibrary permits unstructured access toall variables and, in particular, to a system fetched from disk. Initialization of a catalog consists of marking unused all avail- able disk records in the catalog, and of marking the description area as empty. The size of a catalog in disk records is a function of the dataset parameters: 40 * (records in the dataset) 40 + (words per record) This is truncated to an integral value and bounded by the size of common storage. (40 marks the average size of a description.) The catalog is stored at the end of the dataset; this avoids having to relocate descriptions when the size of the dataset changes - only the catalog itself must be moved to a new position prior to shortening or subsequent to lengthening the dataset. Expansion of a catalog requires that the user first physically extends the PLATO dataset (currently this preserves contents), and then uses csminiadm . The catalog is retrieved from its old position, now inside the dataset, expanded, and stored at the end of the extended dataset. The old size of the dataset in PLATO parts of seven blocks of 320 words each must be provided by the user. Reduction of a catalog requires use of csminiadm to remove systems which no longer fit in a shortened dataset, to decrease the physical catalog size, and to store the catalog in that position in the dataset which will become its end once it is shortened. Then the PLATO dataset is physically shortened (currently this preserves contents) . (Disk space is filled with systems from the beginning of a dataset. A few copy operations are perhaps 25 required to free scattered disk space before a catalog is reduced.) Exclusive access to a catalog must be explicitly terminated - either by storing and thus updating the modified catalog, or by simply destroying the common copy of the modified catalog. 26 2. 4 Implementation notes for the filing systems The common storage used as a system directory has the following layout : name of the attached dataset one control word: number of systems in use allowed number of systems* directory (common) size* fixed part of system descriptors: pointer to variable part length of title length of abstract disk block number protection bit text area (filled from the end forward): variable part of the descriptors: title password abstract A bit map is inserted into the fixed descriptor part area and indicates which disk blocks are in use. * Recomputed to allow for expansion and shortening, 27 The catalog title and abstract display mechanism (part of each lesson) is straight-forward: the common is reserved for exclusive access; if necessary the correct directory is loaded from the desired dataset; titles and abstracts can be viewed. An imain unit and a finish unit are employed to return an updated directory to the dataset if deletions or additions were made. If a system is added, it is saved into an available disk block. The file() area is then used to construct a title and an abstract. If the user does not back out, title and abstract are added to the catalog, and the disk map is updated. In any case, file() is restored from disk. This process is a compromise between minimizing the number of variables necessary for use of the filing system (exactly one word, located among the computer science linkage variables) and keeping the number of disk accesses small. 28 3. cstrees 3. 1 Purpose Linked lists, and in particular trees represented as linked lists, are datastructures used in many programming applications. Knuth [73] describes numerous fundamental algorithms for list manipulation, tree representation, tree traversal, etc. PLATO lessons are being developed (consult [Friedman 78]) which permit manual list node manipulation and graphically illustrate the results. cstrees provides a version of the csmini programming system suited primarily to programming various tree manipulation algorithms. During execution of an algorithm, allocated nodes are displayed on the PLATO terminal screen and the dynamic behaviour of their links is shown. Elaborate use of the TUTOR define statement allowed a very efficient implementation of the execution simulator with the TUTOR compute statement, cstrees was completed in about three days in spite of the complexity of the managed datastructures. The steps of the implementation process, which consisted of modifying a copy of csmini , are explained in the implementation notes below. 3. 2 Lesson structure cstrees uses the exact same structures as does csmini : the pro- gramming system consists of a filing system, an editor, an execution sim- ulator, and a help sequence (see, again, figure 1.1). The filing system, workspace and program editor are copied from csmini ; the program editor is adapted to control the slightly altered mini- language. The help sequence is copied form csmini ; new pages are included 29 to document the modified minilanguage. The available read-only examples in treef ile (the standard dataset for cstrees ) consist of various implementations of binary tree creation, traversal, and deletion algorithms, and of algorithms for the maintenance of sorted binary trees. The execution simulator supports the same control facilities as does csmini . When new nodes are allocated, the execution simulator requests a screen position from the user. The position may be supplied through the PLATO touch panel or through a more conventional cursor implementation with the arrow keys. Once positioned, a node can no longer be moved on the screen. (While a "move node" feature would not pose great technical problems, its absence simplifies execution supervision and en- courages algorithm understanding - only a knowledgeable student can produce a pretty picture.) 3.3 The minilanguage The minilanguage for cstrees permits recursive subroutine calls, computation, node allocation, link manipulation, visitation, and deletion. The objectives in language design stated for csmini still apply. This produced somewhat obscure features such as the "input" and "newnode" defined names. In the small applications envisioned for the cstrees system it should still be possible to write clean code, however. The following statements are available and identical in usage to csmini : CALC expression EXIT IF expression JUMP expression 30 SUB program name: expression The following new statements apply to node manipulation: FREE GET READ VISIT expression The value of the TUTOR expression must identify an existing node, which is destroyed (i.e., vanishes from the screen), expression A new node is created (and must be positioned on the screen) . Its identification (actually a positive integer value) is assigned to the defined name "newnode". Then the TUTOR expression is evaluated. The expression would normally assign "newnode" to some variable or node field, expression A statement to provide input from the user, e.g., to provide information for an entry into a sorted tree. An integer value is accepted from the user and assigned to the defined name "input". Then the TUTOR expression is evaluated. The expres- sion would normally assign "input" to some vari- able or node field, expression The value of the TUTOR expression must identify an existing node which is high-lighted on the screen. The statement is intended to symbolize the coroutine to a tree traversal algorithm. 31 The expressions involve constants, variables and fields of nodes. All values are essentially integers; expressions follow TUTOR syntax, where a functional notation identifies node fields. As in csmini , we have the global variables A . . Z alias Var (1) . . Var (26) , for each nesting level the local variables a . . z alias var (1) . . var (26 ) , the read-only routine call parameter value parm , and the execution control read-only defined names rtn , loc , nest , and halt . Additionally, the READ statement supplies a value for the read- only defined name input , and the GET statement maintains the newnode identification. Nodes have the following fields: info (p) information field, an integer. ltag (p) left tag, a bit. llink (p) left link, should be a pointer. rtag (p) right tag, a bit. rlink (p) right link, should be a pointer. When a node is created all fields are 0, meaning "false" for tags and "nil" for pointers. On the screen (see fig. 3.1), a pointer is shown as a vector to the existing target node, wild or nil pointers are absent, false tags are black and true tags orange squares. "p" in the definition above may be any TUTOR expression yielding a meaningful value. Normally it would be a node field or variable which obtained its value by assign- ment originally from newnode . Access in this fashion is read-only. Write access to a node is permitted once per expression (to simplify implementation of the node animation mechanism of the execution simulator) through the field names: winfo, wltag, wllink, wrtag, wrlink. Additionally, entire nodes can be accessed as node (p) , or wnode (p) . 32 ■ '!:'Lntrri",iin 20 Of . '■v: i :i^'r::i>.''.W!.\'iH l '!"'"!-»".' ^ 2J3TJ0T3 X y II - / i \ \ 3. 0.0' 4 1 M •• "">> to 2.0'05 /\ \ 3.0'.0'6 xl visit ; i n f o (#2 ) = 2 JZf£i' 2 routine : i n log : NE5T : RUNNING (Ljil] make a breakpoint )|Dflffl) show current code [DflTft] look at variables iMEXTV-SMpiMEXTJ/iBflCK) t o run Figure 3.1: Threaded Binary Trees (lesson cstrees) 33 It should be emphasized that syntax verification and execution of all expressions is performed with the TUTOR define , store , and compute statements. Suitable definitions of the node fields enable the node animator to recover all necessary information post-mortem. 3.4 An example: insertion into a preorder - sorted tree The routine "pre" is called with parm pointing to a tree for which the node information is sorted with respect to preorder traversal. Input is information which was placed in the node identified by newnode . This node will be linked into the proper place in the tree. The algorithm is iter- ative, for a Nassi Shneiderman [73] flowchart see fig. 3.2. CALC p <= parm, 1 CALC r *= rlink (p) , 2 CALC 1 «- llink (p), 3 IF r = : ?and$ 1=0, 4 JUMP 14, 5 IF info (r) < input, 6 JUMP 16, 7 IF 1 = 0, 8 JUMP 12, 9 IF info (1) < input, 10 JUMP 18, 11 CALC wrlink (newnode) <= 1, 12 CALC wllink (p) <= newnode , 13 EXIT 14 CALC wrlink (p) <= newnode , 15 EXIT 16 CALC P *= r, 17 JUMP 1 18 CALC P «" 1, 19 JUMP 1 p f root of the tree, initially r t right son of p if any 1 t left son of p if any no sons? yes - attach to the right of p right son smaller? yes - move down on right no left son? yes - attach to the left of p left son smaller? yes - move down on left no - make 1 right son of input ( ) attach to the left of p attach to the right of p p t lower node in tree p t lower node in tree 34 Assumption of the algorithm is that input is information which must be < information in the current node p. Input is not compared to the current node information. Thus, an empty tree must have a root node with no sons. If a node has only one son, its information is assumed to be < the node's own information, and it must be a right son. This state of affairs is used in line 5 and preserved in lines 14 and especially 11/12, A driver routine could be: GET 1 READ 2 GET 3 SUB 4 IF 5 JUMP 6 . . . . P *= newnode, input, winfo (newnode) ■*= input, pre: P, input 4" 0, 1 P + tree, empty root here, obtain input and place it in new node, now attach the node say should stop this (The actual example compares preorder and inorder maintenance.) 35 IHELP) i s ava i 1 ab 1 e routine s preord free space "insertion into a preorder- sorted tree" "p currently points to the root of the tree" wh lie r 'i e w n o d e n o t y e t a 1 1 a c h e d right (p true t ■* ni 1 fa 1 se "there are four cases" ( _la.tta.ch right Cp) ytop $or$ yynd(i) = 0]) y is used to prefix names which are available but (hopefully) not known to the student. The info() field is read-only, protected from subscript violations, and if the y-coordinate of the node, yynd(), is zero, the node — although within subscript bounds — is nonexistent. All violations are automatically trapped. winfo(i) = info(0[yold «■ info(i) ] [yf Id *= 1] + yi «■ i) When the info() field is thus written, it's old value is trapped into yold, an update case is set in yfld, and a pointer to the modified node is trapped in yi (long live embedded assignment!) After the compute statement is done, the display can thus be updated easily. Nodes are stored in bank(), they contain the published fields and the coordinates of the node in the display. The node storage is managed dynamically as a stack, but (obviously) without compaction: deleted nodes can be found as described above. Speed is not essential, since node positioning on the screen is done manually, anyway. 37 3. 6 Implementation guide The following steps were necessary to create cstrees from a copy of csmini : * change the title and page headers. change knowop , the number of known statement keywords, adapt the units putop (keyword display) , s hows tmt (statement display) getop (keyword input to the editor) , and getaux (parameter input) . The unit getplot ( plot statement input) is now obsolete, adjust getexp and get sub so that a multiple use of winfoQ, etc., is rejected, define new variables such as newnode and match them with the student define set . adapt the help pages — the editor is now complete, the initialization unit Setup must be corrected to reflect new statements, the simulation unit Plot must be expanded, execution modules for the new statements have to be inserted. This procedure is fairly straight forward; csmini is commented extensively to aid in this process. As long as the minilanguages are related, the task is relatively small; extensions to languages such as the next two examples are more difficult. * Much of the code should be shared using use statements. Presently this is not done since cslibrary is also used. 38 4. buffering 4. 1 Purpose buffering is a system programming application of the csmini programming system. It provides a setting in which the student can experiment with input-output supervisors performing' buff ered or unbuffered data transfers employing direct memory access hardware. buffering was the first lesson of this sequence. It's essential techniques were subsequently abstracted into csmini . Simplification and generalization of the filing system in csmini was transferred back to buffering . The final version now is an adaption of csmini to a problem in systems programming. 4 . 2 Lesson structure buffering uses a structure very similar to csmini : the pro- gramming system consists of a filing system, an editor, an execution simulator, and a help sequence (fig. 1.1). The filing system is copied from csmini . Examples are available in buf ff ile (the standard dataset for buffering ) for buffered and unbuffered input and output systems. The help sequence, in addition to explaining the minilanguage , discusses the application simulated by buffering : In a third generation operating system, the user's application program is abstracted as follows: OPEN a file for input or output; L: GET BUFFER full on input/empty on output; COMPUTE b with the contents of the buffer b; FREE BUFFER to refill on input/store on disk on output; JUMP L 39 The underlying computer is visualized as a central processing unit (CPU) and a channel performing data transfers. The user's computation takes "rcomp" time units, while the channel takes "rdata" time units for a buffer transfer. The channel may be capable of interrupting the CPU. The student using buffering is charged with programming the input - output supervisor. The interface to his system consists of four routines: OPEN is invoked initially by the user program and allocates "bufno" buffers, the transfer direction is selectable; GET and FREE are regularly invoked by the user program; INTERRUPT is a routine invoked by the channel upon completion of a transfer. Some variables in the system are shared. The filling and emptying of the buffers is shown on the screen by the execution simulator, and the student's input - output supervisor system should, of course, operate correctly and efficiently with respect to buffer usage, "busy waiting", etc. Since the necessary program names are predefined, buffering combines the workspace and program editors of csmini into one module (page) . The program editor provides standard services. The execution simulator is entered from the table of contents or the program editor. First it permits some initialization of values such as transfer - and computation speeds, buffer number, etc. Once started, the simulator illustrates the input - output activity within the ring of buffers. The text of the executing programs is displayed, one routine at a time (fig. 4.1). The breakpoint execution control feature of csmini is eliminated; instead, execution proceeds by statement, routine, or con- tinuously. The program text display can be locked into a single routine. 40 VARIABLES bufno= n; rdata= 4 rcomp= 2 3.— 4 1 C = .0" d= .0' /=> — .0' f= ■J STOPPED !l':-:^ ,'!!,V' J0T i , i pi ..»ii > , . . i Tl i» ni ! hlLllliiiLilljliJuiaiL^'L^.iUj jUvrnt,,. 1 !! « | ™jw« , ,|i ( HELP ) [BACK] PR DBLEM PROGRAM i_: OPEN INPUT GET BUFFER COMPUTE b FREE BUFFER .JUMP L_ IO HANDLER OPEN INTERRUPT 'REE BUFFER [W] DISABLE 1 calc f 4p f- 1 , buffer now empty 2 ENABLE 3 BUSY 4 s xo a , channe 1 ava i 1 ab 1 e : fill! 5 RETURN Current mac h i ne eye 1 e t i me is: M~b] to lock display [hext] for ERnsjfHEXTi for 3£i Lo< >ne cycle >ne rout i n< nation counter is: ( piiTfi ) to keep going [ erase ] to quit Figure 4.1: Buffered Input (lesson buffering ) 41 The student can thus shift his attention and follow, for example, only the action of the interrupt handler, etc. buffering is an example of a problem which has (essentially) only one correct solution, and which is difficult to be assigned in a simulation experiment setting which should require programming a solution to the pro- blem rather than programming the entire experiment. Furthermore the solution is difficult to be completely verified automatically. The lesson provides the simulation setting, a problem-oriented minilanguage for the solution, and avoids the task of verification. Instead, the student is given a simulation of his result, and it is up to him to gain insight, verify, and perhaps correct his answer. Only obvious bugs such as operations on empty or nonexistent buffers, input into a full buffer, use of the same buffer simultaneously by CPU and channel, etc., can be experimentally discovered by the simulator and are signalled to the user. 4. 3 The minilanguage The minilanguage for buffering was designed with the objectives of csmini in mind. It provides the essential statements for the supervision of a direct memory access feature, i.e., the ability to solve the stated problem. (The minilanguage, of course, is not recursive.) The following statements are available and identical in usage to csmini: CALC expression IF expression JUMP expression 42 ENABLE STARTIO The following new statements apply to channel manipulation: BUSY If the channel is busy, the next statement is skipped. This permits "busy wait" - style applications. DISABLE Prohibit an interrupt. (If the channel was busy, it stays busy.) Allow an interrupt again. Critical program sections can be made indivisible with these statements. expression The TUTOR expression indicates a buffer on which the channel is to operate. The channel must not be busy, the buffer must be usable for the operation, and the user program must not COMPUTE on that buffer. terminates the GET, FREE, and OPEN routines. relinquishes control of the CPU by the INTERRUPT routine. If the INTERRUPT routine consists of RESUME only, interrupts are not simulated, buf- fering then operates a channel without an interrupt feature. The expressions involve constants and variables. All values are integers; RETURN RESUME 43 expressions follow TUTOR syntax. We have the (global) variables a . . f , shared by all input - output supervisor routines and the user program. The COMPUTE statement in the user program requires an expression indicating which buffer is to be used. Additionally the read-only defined names bufno , rcomp , and rdata can be employed. 4.4 An example - buffered input OPEN INPUT where bufno > 1 is assumed. CALC b <= - 1, b will indicate the COMPUTE buffer 1 CALC f <= 0, f buffers are full 2 STARTIO a <= 0, a indicates the channel's input buffer 3 RETURN GET BUFFER IF 1 JUMP 2 CALC 3 RETURN COMPUTE b FREE BUFFER DISABLE 1 CALC f ' 2 ENABLE 3 BUSY 4 STARTIO a, 5 RETURN JUMP L f = 0, any buffer full? 0, no - busy wait b *= mod (b + 1, bufno), yes - advance b in a ring on buffer b for the sake of example f - 1, buffer no longer full (if statement 1 were divisible, a race could result) channel available? yes - get going in any case 44 and INTERRUPT one buffer is just filled CALC a *° mod (a+1, bufno), advance a in a ring 1 IF (f <= f+1) < bufno, all buffers full? 2 STARTIO a, no - get going 3 RESUME in any case no race is possible in line 1 since only one interrupt is pending at any one time 45 5. semaphore 5. 1 Purpose semaphore is another system programming application of the csmini programming system. It provides a setting in which the student can experiment with process control and process communication in a multi- programming system. The lesson supports a minilanguage and data-structures in which Dijkstra's semaphores [68] and other synchronization primitives can be implemented. semaphore i s by far the most elaborate application and adaption of csmini . At the time it narrowly missed the absolute bound on lesson size on the PLATO system. Central to the lesson is the belief that a matrix indexed by processes and waiting lists, whose entry for a process is its location counter on the dispatcher's ready list or on a waiting list, is an effective graphical teaching device for the concept of process control and synchronization. Once the device was successfully applied - even in an embarrassingly rudimentary implementation - the minilanguage was developed and the final lesson constructed. 5. 2 Lesson structure and synchronization principles semaphore uses the exact same structure as does csmini : the programming system consists of a filing system, an editor, an execution simulator, and a help sequence (figure 1.1). The filing system and editors are copied and adapted from csmini . Examples are available in semaf ile (the standard dataset for semaphore ) for Dijkstra's P and V primitives solving the mutual exclusion problem and implementing process communication [Dijkstra 68], for an alternate imple- mentation of the P and V operations, for the ENQ, DEQ, WAIT, and POST services 46 of OS/360 [IBM 67], for a generalization of the P and V primitives to control i units of a resource at once and for various dispatching strategies (FIFO, round robin, etc.)* The help sequence, in addition to explaining the minilanguage, discusses the design philosophy of an operating system simulated by semaphore : An operating system is viewed as a set of lists of sequential processes. A process requests from the operating system the execution of a user program ; user programs are designed by the student and then assigned to one or more processes for execution. Processes execute more or less in parallel and can communicate with each other, share system resources, and generally synchronize their mutual activities. The key to process synchronization is the organization of pro- cesses into lists : The ready list initially contains all processes acti- vated by the user. The dispatcher manages the ready list, a process is selected from the list and awarded one time slice, i.e., a certain number of statements in its user program is executed. Dispatchers are designed by the student; the actual simulation commences when the execution of a dispatcher is initiated. User programs may call on list managers to manipulate any of a number of student-defined lists. List managers are designed by the stu- dent; they can transfer their caller process (which, of course, is currently on the ready list) or any other process from their own or the ready list onto any list. List managers are considered part of the operating system, they exit to the dispatcher so that a new process may be selected for execution. 47 Synchronization mechanisms are implemented by the student as suitable list managers - an example is given below. The lesson also permits experimentation with dispatching (scheduling) strategies (through implementation of the dispatcher itself, and through the strategies in the list managers) and with synchronization concepts (through implementa- tion of user programs.) A workspace in semaphore consists of at least one dispatcher, list managers and user programs. Lists are defined as part of the work- space, their parameter values can be initialized prior to execution. User programs in the workspace are assigned to processes. (see figure 5.1). Prior to execution simulation, a linkage phase verifies that all referenced lists and list managers exist. This check originates from the list of processes and thus involves only those user programs, list manager names, and list names which are accessible during the simulation; it is performed to increase execution efficiency by eliminating the necessity to check repeatedly at runtime. During execution, the active programs and their location counters are displayed in two areas (see figure 5.2). Each area can be individually locked - the student can thus take the point of view of the operating system (dispatchers and list managers locked) , of a process (user program locked) , or of the CPU (free display) . Lists are symbolized as the rows of a matrix; within each column a process' presence on a list is symbolized by the location counter of the process being displayed in the corresponding row. A process 1 progress in the system then manifests itself as the location counter moves up and down and changes while the process is on the ready list and selected for execution. The process/list matrix ideally demonstrates mutual exclusion situations, message consumption, etc. 48 LISTS [back] to the table of contents ready mu.tex < number > ( next) a 1 1 er (process) 'number;- (S)|help) remove riarne) (NEXT) add (list) name) IjiJIHelp) delete name) ( edit ) edit (program) n a m e > SjIwlJ (help] d e 1 e t e ^p'yj|[ ME>:f | run dispatcher PROCESSES PROGRAMS * EXECUTES PROGRAM :er User NAME STM TXT TYRE u sed : 5 3 % 6 J3' % P 4 7 LIST MANAGER V 6 1 1 LIST MANAGER The 2 7 DISPATCHER User 9 2 7 user program Figure 5.1: Workspace Directory (lesson semaphore ) 49 t Li=> 1 1-'H» KM User" User User mutex -1 L_ = 1 1 READY !_ = .0 !_ = 1 The PROC 1 JUMP ready (random) J0L no deadlock, we bo [help] [back] VRRI ABLE 5 a .0' b .0' , : - : .0 d .0 e .0 f .0 •5) .0 h .0 i 0' 1 .0 STC PPED .0 IF 1 EXIT 2 APR CD EXIT (parm 4= parm ::.i..-jn <£ cal ler 1) £ CPU cv 0¥ ElJi^MlL H B 1 o< dis F :>La ACTIVE PROCESS [neht] for OTK 1 program: P loc: 3 statement lDftTft) to keep going process ( erase ) -to quit Figure 5.2: Mutual Exclusion Using the P and V Primitives (lesson semaphore ) 50 A slightly expanded version of this operating system simulation laboratory was implemented in PL/I on the TR440 computer of the University of Ulm as project in a course on systems programming [Schloerer 78]. 5. 3 The minilanguages semaphore requires three minilanguages - one for each kind of program which the student may construct. The languages are extensions of a common kernel, and they are based on the language and principles de- scribed for csmini . All languages permit the following statements which are identical in usage to csmini : CALC expression IF expression JUMP expression All languages permit inspection and modification of the (global) variables a . . j alias var(l) . . var(10 )*. The extension for user programs additionally contains two more statements : STOP terminate and remove this process from the system. managername listname execute the list manager for the indicated list (^ ready). List managers, indeed, can be called for various lists; this corresponds to the fact that the P and V operations [Dijkstra 68] can manipulate various semaphores within an application. * Processes do not have local variables. On PLATO this was a necessary evil; in the TR440 project this shortcoming was eliminated. 51 The language extension for list managers contains the kernel and additionally the following three statements: APPEND listname *= expression* the expression value determines a process which will be placed at the end of the indicated list. EXIT the call to the list manager is completed; control reverts to the dispatcher. OWN expression the expression value determines a process; the next statement in the list manager is executed if the process is on the managed list and skipped otherwise. APPEND can only be used to transfer processes from the ready or managed list onto other lists; this restriction was imposed to encourage a certain amount of modularity in the applications. APPEND places processes at the end of the indicated list; this fact is published to simplify the realization of various management strategies (see examples) . EXIT deliberately reverts control to the dispatcher and not (which would sometimes be possible) to the calling process; list manager calls are implemented to be indivisible (the call counts as one unit in the time slice of a process) and the dispatcher is always in control afterwards so that a new scheduling decision may be made. * During editing, this statement does require character manipulation - the 'listname ♦*' must be extracted. 52 List managers have read-only access to the following values: caller length own (expression) random the number of the process calling this list manager. the number of processes in the managed list. expression is a position in the managed list (<_ length); the number of the process in that position is returned. a random value between 1 and 'length' (constant during one call on the list manager) ; supplied to simplify random dispatching strategies. In order to simplify the implementation of various synchronization concepts, each list has a single parameter 'parm', an integer variable unique to the list which the list manager can modify. Typically, 'parm' would be the value of a semaphore represented by the list. The language extension for dispatchers is very similar to the extension for list managers. It contains the kernel and additionally the following four statements: APPEND listname *° expression a process can thus be moved from the ready list to any list. PROCESS expression the expression value determines a process which must be on the ready list; this process is then executed for one time slice. READY STOP 53 expression similarly to the OWN statement the presence of a process on the ready list determines whether or not the next statement is skipped. the operating system terminates. PROCESS gives control to the specified user process. The length of a timeslice is a parameter of the simulation, to be selected by the student. It designates the number of user program statements at most to be executed before the dispatcher regains control. Thus, round robin scheduling strategies are possible. While the ready list has no parameter, the dispatcher has read- only access to the 'length' of the ready list, to 'random' which is con- stant between PROCESS statements, and to process numbers on the ready list via 'ready(position) ' . 5.4 An example: Dijkstra's P and V primitives A semaphore would be represented as a list, the parameter of the list records the value of the semaphore. The P operation can be implemented as a list manager as follows: (parm •*= parm - 1) >_ own *= caller IF 1 EXIT 2 APPEND 3 EXIT Note the embedded assignment in statement 0. Also note that 'own' can be used as a list name in the append statement so that the list manager can operate on arbitrary lists. 54 A list manager for V with random reactivation would be: IF 1 EXIT 2 APPEND 3 EXIT (parm •*= parm + 1) > ready *= own (random) Similarly, a dispatcher with a random scheduling strategy might be : IF 1 STOP 2 PROCESS 3 JUMP length = 0, deadlock: ready (random) It is advisable, to introduce delay loops into the critical section of the user program to increase the probability of actual mutual exclusion: mutex a «■ (a <= a + 1) < 3 2 mutex There is thus one list 'mutex' and in order to synchronize the processes properly, its parameter will have to be initialized to 1. P 1 CALC 2 IF 3 JUMP 4 V 5 JUMP 55 OTHER APPLICATIONS 6. csdesign 6.1 Purpose csdesign was written to graphically demonstrate the branching structure of a PLATO lesson: Students interacting with a lesson usually control their own path through the lesson by means of the branching keys (NEXT, BACK, HELP, etc.) or, if the author provides it, by multiple choice arrows or through the TERM feature. Most of these branching possibilities are explicitly coded with statements such as next , help , etc. in the originating unit, or with a term statement in the receiving unit. However, the action of the BACK and SHIFT BACK keys depends on a variety of context; in particular, the HELP-type keys set up implicit back and backl statements for the receiving unit of the HELP branch, and a base statement in some traversed unit can set up or clear implicit back and backl statements further along the path. Using the imain statement an author might even arrange for branching pos- sibilities to be set up at the beginning of every new (main) unit. csdesign provides a graph of this branching structure. The nodes of the graph correspond to the (main) units of a lesson, the edges to student controlled branches (figure 1.1). A graphical editor permits the design of a lesson graph; additionally csdesign can simulate the execution of the graph — depending on the branching keys pressed, the currently active node is highlighted (see figure 6.1) — and csdesign can take a lesson graph and compile it into equivalent TUTOR code (see figure 6.2). Lesson graphs may be stored on disk. The filing system developed for csmini is part of csdesign , and is thus put to quite a different use. dsgnf ile , the standard dataset for csdeisgn , contains two examples: a lesson graph for the mini programming systems, and a lesson graph for a more tutorial lesson. 56 title no bas- feflCK fTERMl It) (term) key > help key no base *5-_ i;hext] / [HELP] / ;ontepfts (tern] sim b O& (HELP oops. . . . no base he 1 p i nob-- no base / X (term) work ,.y / he 1 pwork no editor uiorkspce d he 1 ped i t no base simulate workspce IHELPJ iflsgpjpLLT he 1 p run Current Un i t Base Unit he 1 pwork workspce UJa i t i ng for Key (edit) to edit Figure 6.1: Lesson Execution Simulation (lesson csdesign) 57 define mu.lt=nl i ma i n KEYS un 1 t title at 1 J3' 1 .0' write title un 1 1 contents term contents base back 4- i 4- 1 j= t It it! he I p he 1 p key at i .u 1 .0 wr i t e contents at 9 3 wr i t e b. . workspce a . . overv i ew arrow 20' IB' long i exact j u.mp catalog match rnu. 1 1 , b , a j u.mp riiu. 1 1 , >' , worksp j u.dge i gnore u.n 1 1 catalog back contents lab! workspce at 10' 1.0 write catalog at 9 3.0 write 1 . . d i sp 1 ay arrow 2£fl0 1 ong 1 match mu 1 1 , i j u.mp rnu 1 1 , x , d i splay j u.dge i gnore un i t c! i sp 1 ay back cat a. log next 1 workspce at 1 .0 1 .0 write d i sp 1 ay end 1 esson u.n i t workspce back contents he 1 p he 1 pwork next 1 simulate at 1 .0 1 .0 wr i t e workspce un i t edit or base workspce next 1 workspce he 1 p lie 1 ped i t jat 1 .0 1 .0 wr i t e editor end 1 esson un i t overv i ew term s i m at 1 01' 1 .0 write overv i ew u.n i t he 1 pwork term work back overv i ew Figure 6.2: Compiled Code (lesson csdesignc ) 58 at 1 1 wr i te he 1 pwork un i t helped it t erm edit back he 1 pwork at 1010 wr i te helped it un i t lie 1 p run term run back helped it at 1 1 .fi- wr 1 1 e ne 1 p run end 1 esson u.n 1 1 he 1 p l ndx at 1 1 .0' write he I p l ndx at 9 3 wri te arrow 1 ong match j ump j udge un 1 1 term at a„ . help key' b. . overview c. . he 1 pwork edit run 201 1 mu 1 t , a t b , c , d , e rnu 1 1 , x , he I p key i gnore help key key 1 1 write help key end 1 esson u.n i t simulate base workspce he 1 p he 1 p run at 1 1 wr i te simulate next workspce u.n i t oops a t 1 1 write oops end 1 esson un i t KEYS datal contents helpl oops estop :rv i ew , lie 1 pwork , he 1 ped i t , he 1 p run Figure 6.2 (Continued) 59 csdesign will refuse obvious errors such as duplicate or non- existent unit names. Global simplification of the lesson graph, however, is not attempted. In particular, there does not seem to be an algorithm to deal with base units at compile time (to eliminate unnecessary base statements and to display all base relations). One PLATO consultant commented on the large number of end lesson statements produced by the lesson graph compiler: In the absence of next or multiple choice edges the NEXT key should terminate the lesson rather than to produce the well-known phenomenon of blank pages, sentence fragments on the screen, and finally (usually) some spectacular crash. At least in this respect csdesign attempts to produce clean code and protect the in- experienced author. 6.2 The editor The editor must display and modify the lesson graph on the screen and a corresponding data structure in memory. Input to the editor consists of geometric information and branching keys (see figure 6.3). Geometric information is the position of the cursor, repositioned in response to the "arrow" keys or to a touch on the PLATO screen. This cursor position can be used to identify a node (unit) of the lesson graph — the node description in the data structure can be found on the basis of coordinates. In response to other input, nodes identified by the cursor can be modified, connected, deleted, etc. Alternatively, new nodes may be introduced to reside at the cursor position, or existing nodes can be repositioned. 60 e s s o n S t r u c t u. r e D e s i g n Press. J Wc^'lE' t, etc. to move the cursor f-s: to change to FINE or CORPSE GRID, U.-U to add or delete a unit. ■B to add or delete a base designation, rrERMj to add or delete a IjerKI. to rename a unit m to move a unit on the screen. [NEKTj. etc. to add a key -directed 1 ink. Th 1 s produces a ' g 1 oba 1 ' key , if the named unit doesn't exist t o add a mu. 1 1 i p 1 e - cho i ce 1 i. nk (erase) symbo 1 to delete a 1 ink. When a unit name is required, you may press the (hnjj] key for the unit to which the cursor points, or the (copy) key for the name of the last unit added, "he (back) key always preempts any command. Figure 6.3: Lesson Graph Editor Options (lesson csdesign ) 61 Branching keys (NEXT, TERM, etc.) request that a corresponding link, i.e., a student-controlled branch, be established. Links will either connect two nodes, or they will relate globally to one node (TERM and branching statements introduced with an imain unit). In order to establish links, nodes must be identified — this is possible by (unit-) name, cursor position, or by reference to the last node added. A special, but common, variety of branching depends on a multiple choice arrangement: the choices are usually identified by single letters; as soon as a letter is pressed the corresponding branch is taken. This structure is usually realized with an arrow statement and (corresponding to PLATO's standard editor) the '■*=' key will introduce a multiple choice link into a lesson graph. 6. 3 The compiler The following information can be obtained for each node (there is more information specific to editing): names of this unit of base unit (if any) global key (if any) TERM word (if any) Each node also provides access to a list of outgoing and a list of incoming links (the latter to speed up editing operations) . A link provides the following information for the compiler: activating key target unit 62 The compiler is given the name of the unit to appear first in the lesson, i.e., the unit first entered when the lesson is accessed normally. Then code is compiled as follows: TUTOR code define mult=nl imain KEYS unit term base < name > at 1010 write at 930 write . . . arrow 2010 long 1 exact jump match mult, letter , jump mult ,x, name , . judge ignore Production condition [always. ] if any unit has a global key pointing to it. [for every node in the lesson graph, see below.] if the unit has a TERM. if the unit has an explicit base unit set. for any outgoing branching key, except NEXT. [always, to document execution of this code.] if the unit has outgoing multiple choice links. for any outgoing multiple choice link. if the unit has outgoing multiple choice links. if the unit also has an outgoing NEXT key. for all outgoing multiple choice links. 63 next if there was no multiple choice and if the NEXT unit has already been compiled end lesson if there was no multiple choice and no outgoing NEXT link. The compiler will now select another unit. If the target of an outgoing NEXT key has not been compiled yet, it is chosen (to clarify the compiled code); otherwise another unit is chosen sequentially from the beginning of the node storage. Eventually all nodes will have been compiled. If necessary, unit KEYS is then produced containing all the global branching keys in the lesson graph. Since regular TUTOR lessons are not permitted to write into TUTOR lessons, the compiled code is deposited in common storage* and the user is instructed how he can copy the code. * The filing system also requires common storage. The compiler was therefore made a separate lesson csdesignc . 64 7. csf low 7. 1 Purpose Structured coding is a fashionable word usually associated with certain programming practices such as relying primarily on the control structures of concatenation (sequential execution), selection ( if-then - else or case ) , and iteration ( while or repeat-until ) . Nassi and Shneiderman [73] suggested a flowcharting technique that — because of certain topological properties — only permits these control structures (figure 7.1) and thus strongly encourages clean coding. The flowcharting technique does not require modern programming languages to accompany it — this author has used it quite successfully in introductory FORTRAN programming courses. It is quite simple to implement the normal ('spaghetti') variety of flowcharts, and a number of PLATO lessons do so. Producing an editor for Nassi-Shneiderman flowcharts is more difficult, mostly because the editing dialogue presents a semantic problem: How do we talk about nesting boxes? csf low is an editor for Nassi-Shneiderman flowcharts. A workspace consists of a number of individually named charts and it may be filed using yet another copy of the filing system discussed earlier. Among the examples in f lowf ile , the standard dataset for csf low , are the usual algorithms found in an introductory programming course (Euclid's algorithm, bubble sort, Simpson's Rule, etc.) and a few more challenging applications: Shell's sort, and an program to justify and print text. At this point, flowcharts constructed in csf low cannot be 'ex- ecuted' — but this is due to a lack of time to write some execution sim- ulator, not because there are any actual problems in such an extension. The lesson demonstrates how an editing dialogue can be realized, and the algorithms developed for the editor are quite independent of PLATO or any applications. 65 ( help ) on . . . C5FLOW Nass l - Shne l clerman F 1 owchart 3 Flowcharts according to this proposal permit only a limited set of control structures; they seem to be easier to verify than the more common 'spaghetti' diagrams. The flowcharts evolve as a nested set of act i ons (boxes) , where each act i on as we 1 1 as each nest has exactly one entry and one exit. Th i s ed i t or support s t lie f o 1 1 ow i ng four act i ons : free: action, used to express an arfo i t r ary comput at i on . t rue i t i on fa 1 se cf, used to express selectior ::■£' one of two alternatives. re peat .;""; r~;i nd i t i on repeat, used to express the iteration of an action until a condition becomes true. c o nd i t i on while, used to express the iteration of an action until a >nd i t i on i s t rue (poss i b 1 \ feftCKJ any t i me . Figure 7.1: Flowcharting Principles (lesson csflow) 66 7.2 The editor The editing dialogue is forced: the flowchart under construction is correct (in its syntactic sense) at all times; the problem of taking a structure and verifying that it, indeed, conforms to the Nassi-Shneiderman proposal is carefully avoided. In order to maintain correct flowcharts we cannot permit geo- metrical operations such as the adding of new actions, i.e., the drawing of new boxes, as sets of individual lines with text enclosed. Instead we allow algorithmic development such as concatenate a new action, which is a selection or iteration or unspecified, to an existing action (or first into the chart) . insert a new action into an existing selection or iteration, nest a chain of actions into a new selection or loop, delete a chain of actions, convert a chain of actions into a separate (named) flowchart . copy a named flowchart into the present chart, concatenate it, or insert it. Actions are, of course, identified by pointing at them on the screen with a suitable cursor. (The editor is summarized in figure 7.2, a sample flowchart is shown in figure 3.2). The key to implementing the editor lies in a suitable data structure for representing a flowchart. This data structure must permit the editing operations mentioned above (especially nesting, extracting, and erasing may be difficult, and PLATO affords very little processing power 67 (help] on . . . CSFL.OI.iJ F 1 oujchart Ed i t or arrow keys, touch panel. move the cursor O . The other editing functions usually assume that the cursor points at the box involved. I'edit] change the text inside the current box ( hekt 'i' i '1'r fly jcopy] concatenate a. new action (box) to the current box (or as first box of the flowchart) (T) is an if, © is a repeat, (y) is a. while, Ihext] i s an unspec i f i ed act i on ; [copy] a I 1 ows an ent i re QDGDCD insert a new action as first one of the true/' false part of if, or as the loop part of repeat or while which must be the current box. RT7j insert a concatenated set of boxes (and all boxes within) as true/fa Ise part of a new if, or as loop part of a. new repeat or while. The current box is the first one of the set, t h e 1 a s t c o n c a t e n a t e d o n e w ill b e r eq u e s t e d . [erase] erase a concatenated set of boxes box with a rou.ti.ne name; the set of boxes is ;rat i on that has not vet been completed. r [back] any t i me . Figure 7.2: Flowchart Editor Options (lesson csf low) 68 if a quick response is required). Additionally, plotting the chart and correlating a position on screen to the representation of a box must be efficient operations. Surprisingly enough, the data structure and its manipulation are just about textbook material for one-way linked lists and binary trees! We make the following observations: a concatenation is a list of actions. an if-action has two dependent concatenations, namely the true and false alternatives, a while- or repeat-action has one dependent concatenation, namely the subject of the iteration, any action, if-, while-, repeat-, or unspecified, has some textual content and participates in one concatenation, a flowchart, finally, is one concatenation. This structure seems to resemble a binary tree where actions are the nodes, if-actions having two sons, while- and repeat-actions having one, and unspecified actions having none. However, a flaw remains: the concatenations do not fit; they really play the role of nodes, composed of many atoms, and the atoms (actions) then provide for descendants in the tree. The data structure thus is not quite a binary tree, but all the manipulation algorithms still are easily developed by observing the close resemblance. actions are the nodes in the data structure; they are typed and make the text content of a box accessible. 69 every node has a successor; the successor node is either the concatenated action (if any) or a blind node designating the end of a concatenation, if-type nodes have two sons; the son nodes are either blind or they represent the first actions in the true and false alternatives of the if-action. while- and repeat-type nodes have one son; the son node is blind or represents the first action subject to the iteration, a flowchart then is a header with a son node; the son node is blind or represents the first action in the flowchart. Plotting a flowchart is accomplished by traversing the representing tree. With a given left and right margin we can iteratively move along the concatenation and down the screen: an unspecified action is plotted over the entire width available. the condition of an if-action is shown, then the son-concatenations are (recursively) traversed in turn on the left and right half of the screen, finally an uneven bottom may have to be adjusted. the condition of a while-action is shown, then the son-concaten- ation is (recursively) traversed on a slightly reduced screen width, finally the while-box is completed. a repeat-action is similar to a while-action, the difference is that the condition is displayed at the bottom of the box. Plotting is thus a recursive traversal algorithm with left, right and top margins as input and bottom margin as output. Each node must only provide its own height (depending on the given width!) it need not know its own coordinates. 70 Finding a node based on a cursor position is accomplished by a similar traversal which performs the same margin computations as does the plotting algorithm, but which does not actually plot. In complete analogy to the plotting algorithm, the finder can distinguish between a hit into any area of a repeat-box and a hit into the actions actually repeated, etc. Deletion of nodes is, of course, based on postorder traversal; copying a chart is based on preorder traversal. A sizing traversal (in preorder) verifies that nesting and copying will not produce flowcharts too detailed to be displayed. Implementation of the editor is a simple exercise in manipulating one-way linked lists and binary trees. Recursion and the introduction of the blind nodes mentioned above make programming quite straight-forward (although in TUTOR the recursion must be simulated through explicit stacks) , 7 . 3 Implementation notes The crucial algorithms have been described above. Since TUTOR does not permit recursion to a sufficient depth, the following technique is used: unit I(sparm(top+l) ,sret (top+1) ) calc top *= top+1 push the stack we define parm=sparm(top) and can thus use a 'local variable' parm. goto I (newvalue,returncode) this establishes a 'recursive call' entry II this establishes the return point 71 calc goto top *= top-1 pop the stack sret (top+1) , . . . , II , . . . this will return from the 'recursive call'. With this technique it is possible to mechanically convert a recursive solution into an iterative one. The necessary stack is maintained in bank(); it is dimensioned so that all plotting algorithms cannot overflow it. In the file() area, csflow allocates control information indicating how much of the remaining area is used, a fixed area of nodes, and a fixed area for text. Nodes are linked to form list of available nodes; overlays are defined for the node area to interpret the nodes as describing boxes or routines: routine descriptor nxt() rnm() rnd() box descriptor nxt() nty() nap() pointer to next routine node or blind node. 6 letter routine name. pointer to first flowchart node or blind node. pointer to concatenated box or blind node. node type field. pointer into text storage (see below.) 72 nle() pointer to left and right sons nri() or blind nodes, if any. Blind nodes have nxt() = nil (zero) — they simplify all node managing operations. A variable avail points to the first node on the avail list; one location (heaplen) in the node area is not attached to the avail list. Typically, to attach a new node, the appropriate information is filled into the node at heaplen, then the value of avail is assigned to the point where the new node is to be attached, finally, the unit getheap is called which will detach the next available node from the avail list and copy the information from heaplen into it; getheap also displays certain statistics. A complementary unit f reeheap will return a node to the avail list. Text storage is organized as an auxiliary pointer area, apt(), to which the nodes' nap() point. The auxiliary pointers then locate text in the actual text area. If text is moved, the auxiliary pointers can be updated sequentially and the nodes need not be traversed. The auxiliary pointers are maintained so that a zero indicates an available pointer; the search statement will quickly locate this. Determining the height of a box once the width is prescribed is a frequent operation. It amounts to counting the number of print positions which a text actually requires — with the character code in the PLATO system, where a variable number of 6 bit codes together may print as one character, a very complicated problem. csf low permits texts of up to 60 characters; when a text is newly obtained, a bit mask of one 60 bit word is constructed which is '1' on every last character in a print sequence. The number of printing positions is then the number of '!' bits in the mask — 73 a very fast operation. The mask is also used in breaking text correctly into several lines of a box. The sizes of the text areas and the node area are fixed, based on some sample workspaces. A better solution would be to organize them somewhat dynamically. 74 OPEN QUESTIONS The mini programming systems described here have seen use in some advanced computer science courses, and they seem to have accomplished their instructional goals; at least csmini has successfully been used to support a programming assignment — an implementation of Wirth's W-curves [76]. csflow was used to provide information for a machine problem in the introductory programming course in summer 1978. While the filing system has shown to be quite adaptable to a number of widely differing applications, it could be improved by employing some new PLATO features: The decision to employ onely one common for all lessons is no longer necessary. Datasets can now be reserved; hence, exclusive access to the catalog can be granted to csminiadm and each individual lesson based on a data- set reservation. Users of one lesson still need to interlock, but overall performance would be improved. Name sets should be attached to provide a private filing facility keyed to the student's name. While the standard examples for the lessons still should originate from datasets with the catalog and abstract service as de- scribed here, namesets would provide easily managed privacy for larger class assignments, etc. The strongest feature of the filing system, however, is its basic ignorance of the content and length of a system (disk record) . This should by all means by retained. 75 The mini languages seem to be rather useful. Only minor irrations were discovered - mostly in the area of global and local variables in semaphore. The implementation of a number of protective measures within expressions could now be substantially simplified through the use of TUTOR' s arrays with subscript bounds. There is still a large number of possibilities for small languages: The recursive descent parsing technique of a compiler requires a language of about 5 simple statements [Schreiner 78], and there are more compiler algorithms that could be adapted to this environment. Coff man's progress plane [71] seems to be a very good graphical vehicle to discuss process scheduling, dead- lock detection and Haberman's algorithm [69]. The simulation of the progress plane is available on PLATO in lesson deadlock (see figure 8.1) but it is not really clear how this concept could be made very interactive in a fashion similar to semaphore . A minilanguage for sorting could be based on a situation where a randomly initalized array of 'N' things needs to be sorted. The language should provide testing predicates, e.g., LE(i,j) true if array element i precedes element j in the assumed ordering and an 'exchange' statement; no actual access to the array is necessary. (The language should allow recursion to facilitate an implementation of 'quicksort'.) Max. Claim Resource i Res ource 2 Process 2 ... „ A 76 !|"" (J* ^F'T" .TITOHi j) ; i' 112 2 11 iu u u u 1 10 1 12 2 j exclusive ' deadlock U unsa f e hidden Process 1 Max. Claim 2 2 * *" The progress plane definition is now complete. e . . . . exc 1 us i ve areas u. , , . . unsa f e areas (c f . Haber mann) d . . . . dead 1 ock areas 1 . . . . areas 1 ocked out by exc 1 us i on iBflCKl. . to LiiiijlBftrKj to quit h. . . . areas hidden by unsafe areas a.... to accelerate the computation Figure 8.1: Progress Plane Simulation (lesson deadlock) 77 The lesson csf low opens up an entirely different area of ap- plications. As it stands, it could perfectly act as. a disciplined flow- charting tool and as such could be employed, e.g., in an introductory programming course for submitting flowcharts and thus stressing the need to design clean control structures. Expansion of the lesson, however, could lead to quite powerful and very language- independent programming environments: Nassi-Shneiderman flowcharts would then be a well-structured language kernel providing the control structures commonly found in a modern programming language; the language extensions for particular teaching ap- plications can completely reside inside the boxes and thus on top of the kernel. Maybe it is just about time to rewrite csmini and friends . . . 78 REFERENCES E. G. Coffman et al . : System Deadlocks; Computing Surveys , June 1971, pp. 67-78. A. M. Davis: An Iteractive Analysis System for Execution-Time Errors; Ph.D. Thesis, Report UIUCDCS-R-75-695*, 1975. E. W. Dijkstra: The Structure of THE Multiprogramming System; CACM , May 1968, pp. 341-346. H. G. Friedman, Jr.: cslessons ; PLATO lesson, to be published by Control Data Corporation. H. G. Friedman, Jr.: cslibrary ; PLATO lesson, published by Control Data Corporation, 1976. A. N. Haberman: Prevention of System Deadlocks; CACM , July 1969, pp. 373-377. IBM System/360 Operating System, Supervisor and Data Management Services ; Form C28-6646, IBM Corporation, Programming System Publications, 1967. D. Knuth: The Art of Computer Programming , Volume 1; Addison Wesley, Second edition, 1973. I. Nassi, B. Shneiderman: Flowchart Techniques for Structured Programming; SIGPLAN Notices , August 1973, pp. 12-26. J. Nievergelt et. al.: The Automated Computer Science Education System at the University of Illinois; Report UIUCDCS-R- 76-810*, 1976. J. Schloerer: Betriebssystem Simulator ; Sektion Informatik, University of Ulm (West Germany), 1978. A. T. Schreiner: Compiler Algorithmen Modelle ; Sektion Informatik, University of Ulm (West Germany) , 1978 - parts published earlier by WANG Labs, Tewksbury Mass. 01876. B. A. Sherwood: The TUTOR Language ; Control Data Education Company, 1977. B. A. Sherwood: graf it ; PLATO lesson published by Control Data Corporation, 1977. S. G. Smith, B. A. Sherwood: Educational Uses of the PLATO Computer System; Science , April 1976, pp. 344-352. * Reports are available from the Department of Computer Science, University of Illinois, Urbana, IL 61810 79 M. H. Tindall: An Iteractive Compile-Time Diagnostic System ; Ph.D. Thesis, Report UIUCDCS-R-75-748*, 1975. L. A. White: The Design of wits, a Student Compiler System on PLATO IV ; M. Sc. Thesis, Report UIUCDCS-R-76-819*, L. A. White, A. T. Schreiner: basicx; PLATO lesson published by Control Data Corporation, 1978. T. R. Wilcox: The Interactive Compiler as a Consultant in the Computer Aided Instruction of Programming; Proceedings , 7th Annual Conference on Information Sciences and Systems , 1976. N. Wirth: Algorithms + Data Structures = Programs ; Prentice Hall, 1976. * Reports are available from the Department of Computer Science, University of Illinois, Urbana, IL 61801. BIBLIOGRAPHIC DATA SHEET 4. Title and Subtitle 1. Report No. UIUCDCS-R-78-937 3. Recipient's Accession No. CSMINI - APPLICATIONS OF A MINI PROGRAMMING SYSTEM ON PLATO IV 5- Report Date August 1978 7. Author(s) Axel T. Schreiner 8. Performing Organization Rept. No. 9. Performing Organization Name and Address Department of Computer Science University of Illinois at Urbana-Champaign Urbana, Illinois 61801 10. Project/Task/Work Unit No. 11. Contract /Grant No. 12. Sponsoring Organization Name and Address 13. Type of Report & Period Covered 14. 15. Supplementary Notes 16. Abstracts Design objectives, application examples, and implemention notes for a number of published PLATO lessons sharing certain features, instructional approaches, or code modules: the programming systems csmini to study recursion and curve plotting, cstrees to study linked list algorithms, buffering to study input- output buffering techniques, semaphore to study implementation and use of pro- cess synchronization primitives; csflow , an editor for Nassi-Shneiderman flow- charts, and csdesign , a graphical PLATO lesson structure development system. The report is intended for instructors wishing to use the lessons, PLATO authors attempting to implement similar systems, and teachers interested to export the instructional concepts to other computer systems. 17. Key Words and Document Analysis. 17o. Descriptors input output supervision, linked lists, minilanguages , PLATO, process synchronization, programming education, recursion, structured flowcharts 17b. Identifiers/Open-Ended Terms 17c. COSATI Field/Group 18. Availability Statement FORM NTIS-35 ( 10-70) 19. Security Class (This Report) UNCLASSIFIED 20. Security Class (This Page UNCLASSIFIED 21. No. of Pages 22. Price USCOMM-DC 40329-P71 aug ian.