HHH 
 
 BKoSeS 
 
 m 
 
 SKaSQL 
 
 
 W 
 
 ■■ rasB 
 
 JESSES? 
 —"—""WWW 
 
 
 ■I 
 
 e I 
 
 BsEeP Is BIS 
 
 mmgutSSSSBmOlUSSSBOm, 
 
 twww — nrMM n rnn nn nn rai n w nr 
 
 SKI 
 
 IB 
 
 "tta 
 
 BHBSmucoB 
 JrhsSSosB 
 
 Ba WM W 
 
 n 
 
 HHBMRnSHDiBnBMR 
 
LIBRARY OF THE 
 
 UNIVERSITY OF ILLINOIS 
 
 AT URBANA-CHAMPAIGN 
 
 510.84 
 
 HGr 
 
 no. 818 - 825 
 
 cop. 2, 
 
The person charging this material is re- 
 sponsible for its return to the library from 
 which it was withdrawn on or before the 
 Latest Date stamped below. 
 
 Theft, mutilation, and underlining of books 
 are reasons for disciplinary action and may 
 result in dismissal from the University. 
 
 UNIVERSITY OF ILLINOIS LIBRARY AT URBANA-CHAMPAIGN 
 
 8E P 1 e m 
 
 SEP 2 1 " 
 
 L161 — O-1096 
 
Digitized by the Internet Archive 
 in 2013 
 
 http://archive.org/details/designofwitsstud819whit 
 
2* %% 
 
 lnucDCS-R-76-819 
 
 / l\JU-^- y \A 
 
 \ 
 
 THE DESIGN OF WITS 
 A STUDENT COMPILER SYSTEM ON PIATO IV 
 by 
 Lawrence Allen White 
 
 July, 1976 
 
THE DESIGN CF HITS 
 A Student Compiler Systen on Plato IV 
 
 BY 
 
 LAWRENCE ALLAN WHITE 
 
 E.S., University of Illinois, 1975 
 
 THESIS 
 
 Submitted in partial fulfillment of the requirements 
 for th€ degree cf Master of Science in Computer Science 
 in the Graduate College of the 
 University of Illinois at Urtana-Champaign , 1976 
 
 Urtana, Illinois 
 
Ill 
 
 TABLE CF CONTENTS 
 
 1. Intrcducti.cn 1 
 
 2. Users cf Interactive Compilers on Plato 2 
 
 2.1. Educational Psychology 2 
 
 2.2. Computer Calculus • 3 
 
 2.3. University High School 4 
 
 2.4. CS 105 6 
 
 2.5. Visitors 7 
 
 2.6. Future Users 3 
 
 3. The Plato IV System 9 
 
 3.1. Central Computer Architecture 10 
 
 3.2. Terminal Communications 12 
 
 3.3. Student Terminal 13 
 
 3.4. Software 17 
 
 3.5. Tutor Data Areas 18 
 
 3.6. Resource Limitations 22 
 
 4. WITS Desiqn Philosophy 24 
 
 4.1. Complete System 24 
 
 4.2. Minimal Resource Use 26 
 
 M.3. Language Changes • 28 
 
 4.4. Stable System 29 
 
 5. The WITS System Now 30 
 
 5.1. Structure 30 
 
 5.2. Sophistication 33 
 
 5.3. Speed 34 
 
 5.4. Resource Use • 35 
 
 5.5. Stability 36 
 
 5.6. (lore work Needed 36 
 
 6. The Histcry cf HITS 38 
 
 6.1. Changes to Plato Affect WITS 38 
 
 6.2. Resource Shortages 42 
 
 7. Conclusion 47 
 
 List ot References 50 
 
IV 
 
 PBEFACE 
 
 This thesis discusses the design of an interactive student 
 ccmpiler systei called HITS, an acrcnym for "White's Interactive 
 Timesharing System." The HITS system currently contains two 
 editors, twc filing lessons, and two compilers. Work is in 
 progress cr creating additional editors and compilers, in order 
 tc tetter meet the needs of its users. These compilers have 
 been inplcaerted or the Plate IV computer system, and are being 
 used by students. Included in this thesis is a description of 
 the Flato IV system and hew it affected the development of HITS. 
 
Chapter 1 
 
 Introduction 
 
 
 The Plate IV system [ Alpert, 1970 ] is a computer based 
 educational system developed at the University of Illinois. 
 Various user groups at Plate have been interested in designing 
 or using interactive compilers for student programs. Two such 
 systems of compilers have been implemented on Plate. This 
 t.h3sis discusses the design considerations that went into the 
 i nplementat icn of cne of these compiler systems and the results 
 of that design. The compiler system described here is called 
 WITS, an acrcnym for "White's Interactive Timesharing System." 
 Throughout this thesis, occasional comparisons are made to the 
 other compiler system, CAPS [ Wilccx, 1976 ], which has been 
 implemented by the Computet Science Department at the University 
 of Illinois. 
 
 In order to give some basis for the discussion of the 
 design chesen fcr WITS, the first two chapters describe the 
 users cf the WHS compilers and the computer system on which 
 WITS was implemented. Chapter 4 describes the goals the WITS 
 designers had in implementing their system. Chapters 5 and 6 
 describe HITS as it currently is, and how it became that way. 
 
Chapter 2 
 Users of Interactive Compilers on Plato 
 
 Before the implementation of any computer programming 
 system, consideration must be given to the type of users the 
 system will have, and what their needs are. In designing WITS, 
 several user groups were kept in mind, in an attempt to make the 
 system general enough to be used by many groups. The user 
 groups the author has had experience with are described below, 
 alonq with their reeds as seen by the compiler designers. 
 
 _2_-_l_. Educational Psych ology 
 
 BASIC [ Kemeny, 1 967 ] is a simple programming language, 
 primarily intended for numerical applications. Because of its 
 simplicity and its acceptance in the education environment, it 
 was chosen as the first language to be implemented on Plato. 
 The compiler das written for Professor Kenneth Travers of the 
 Secondary Education Department, and for Axel T. Schreiner of the 
 Mathematics Department, both at the University of Illinois. As 
 understood by the compiler designers, Dr. Travers was 
 instructing future teachers in hew to teach BASIC. Since his 
 students would later, in most cases, be using small interactive 
 systems utilizing Teletypes for communication. Dr. Travers 
 wanted the user interface of the BASIC system we built on Plato 
 to resemble such a system. In particular, his reguirements were 
 
as follows: 
 
 1) User interface similar to standard interactive system, 
 A) Teletype like appearance. 
 
 E) Clear distinction between editing and compiling. 
 C) Ccnmand directives, rather than user choice pag€. 
 
 2) Frovide simple program preparation facilities. 
 A) Permanent program storage space for 10 users. 
 E) Line-criented text editor. 
 
 3) Compile and execute small BASIC programs. 
 
 Unfortunately for the Education Department's students, the 
 Plato system was still experimental at that time, and rather 
 unstable. Additionally, these students were the first to use 
 the forerunner cf the WITS system, and they found many bugs in 
 the editcr, filing system, and BASIC interpreter. To their 
 credit, they stuck with the system for two or three semesters 
 while the Plate system was stabilizing and we were fixing 
 problems in our lessons. 
 
 2^2^ Computer Calculus 
 
 Cne of the cc-authors of that first system, and the real 
 desiqner cf cur BASIC compiler. Axel T. Schreiner, was at that 
 time designing "Computer Calculus" [ Schreiner, 1972 ], a 
 laboratory course supplementing regular Calculus instruction at 
 th<= University of Illinois. His students were writing small 
 numerical analysis and graphical programs using CAIL/360-OS 
 EASIC [IBH] en FIOBTS [Gear, 1969], a local interactive 
 timesharing system. For the purpese of Computer Calculus, the 
 Mathematics Department had set up a laboratory room connected to 
 
the IBM/36C-75 operated by the Computing Services Office at the 
 University of Illinois. This laboratory had 16 teletypes for 
 program preparation and alphanumeric input and output, along 
 with a saall Hewlett-Packard flat-bdd plotter, connected to one 
 of the teletypes, fcr graphical output. 
 
 Mr. Schreiner became interested in using Plato for the 
 qraphics pcrtion cf the Computer Calculus classes, and wrote 
 seme instructional lessens on Plato for this. Later he expanded 
 his interests to include using Plate for a section of his 
 students tc run EASIC programs. Fcr Computer Calculus students 
 tc use Plate for EASIC, they would need essentially the same 
 facilities as Professor Travers needed, but for 20 students 
 simultaneously, not 10. 
 
 Tc meet the goals of these twe user groups. Educational 
 Psychology and Computer Calculus, the user interface of the 
 first EASIC system implemented on Plate looked very much like 
 PICRTS, tc the extent that some of the editing commands were 
 identical tc those en PLOFTS. This system was used by Education 
 and Calculus students until a more advanced system, called HITS, 
 was inplemented. 
 
 2_. 3.. University High Schocl 
 
 The heart cf the HITS system was written in the fall of 
 1973, using seme new features of the Flato system, and was first 
 used the following spring. HITS allowed for the connection of 
 any number of user groups to cne filing system, all using the 
 
same editor and compiler. The first new group of users was from 
 University Hiqh School, which already had access to Plato, and 
 whose instructors were interested in teaching their students to 
 program. 
 
 The "Dnihi" students had no previous experience with other 
 computer systems, and in many cases, WITS was their first 
 encounter with Plato. These students, rather than using 
 programming to learn another subject, as were the Calculus 
 students, were learning about computers, computer systems, and 
 programming. As such, the HITS system was one of the things 
 they were learning about, rather than being just a tool in the 
 study cf something else. 
 
 The basic reguirements for the University High School 
 students were slightly different from those of the other user 
 groups previously described. What they needed HITS to provide 
 are described below: 
 
 1) Frovide a programming system at small additional 
 ccst to the school. 
 
 2) Ee simple enough to allow seme guick achievements 
 for students, powerful enough to hold their interest 
 for a semester or two. 
 
 3) Ee simple enough to explore by trial and error, safe 
 enough so students can not accidently hurt anything. 
 
 4) Provide filing space for 35 students. 
 
 The original HITS system filled all these needs, so the 
 University High School students started using it. As HITS has 
 expanded to include a Fortran compiler and another editor and 
 
filing system, Unihi students have continued to utilize all the 
 capabilities cf the HITS system. 
 
 2..J4_. C S 1 5 
 
 The Computer Science Department at the University of 
 Illinois has been wcrking for a few years to automate their 
 introductory programming ccurses [ Nievergelt, 1974 ]. To do this, 
 members of the department have written many instructional 
 lessens on Plato, and have implemented interactive diagnostic 
 compilers for subsets of several programming languages 
 [ Hilccx,1 S76 }. Of particular interest is the CS105 programming 
 course, with about 1000 students each semester. The HITS 
 desiqners have tried to expand their compiler systei to support 
 this group, but due to the large number of students, this 
 attempt has been only partially successful. 
 
 CS105 is an introductory programming course for business 
 students. In many cases, this will be their only programming 
 course, which they take because it is required of them. Such a 
 group is, en the whele, only interested in getting their machine 
 probleus dene with the least amcunt of effort. They are not 
 interested in learning hew editors or filing systems work 
 (unless that is assigned to them) , and they are very intolerant 
 when they can not get the system to wcrk. 
 
 Since there are so many cf these students, they are 
 scheduled rather tightly, and are unlikely to come in on their 
 own time, unless it is to finish a late programming assignment. 
 
Due tc the large number of students, a different organization of 
 resources nay he required in HITS to handle them all. Below are 
 listed the major requirements to use IITS for Introductory 
 Computer Science Courses at the University of Illinois: 
 
 1) Provide Fortran and/cr PL/1 compilers. 
 
 2) Support 40 simultaneous users. 
 
 3) Frovide filinq space for 1000 students. 
 
 4) Use a minimum of costly system resources. 
 
 5) Provide self-explanatory editors and filinq systems. 
 
 Expected use of HITS in the near future by the CS 
 department appears rather minimal at this time. This is due to 
 the department havinq its own compilers on Plato, and to the 
 availability cf batch compilers on CSC»s IBM System 360/75. One 
 way HITS miqht be used is as an intermediate step between their 
 Plate Compilers and the 360. The students could learn the basic 
 features cf a prcqramminq lanquaqe usinq the departments 
 diaqnestic compilers on Plato, and could then move to HITS for 
 writinq lenqer prcqrams, and later move to the 360 to learn 
 about a batch oriented system, printed output, file I/O, and 
 still larqer proqrams. 
 
 2_. 5. Visiters 
 
 In addition tc servinq the orqanized qroups described 
 ahove, the HI1S desiqners have encouraqed people to set up Plato 
 records so students miqht "visit" the HITS system. Several such 
 
8 
 
 visiter records have been created for students to practice 
 proqua a irinq on their own. In some cases, these students have 
 even teen provided with disk space for storing their programs 
 between sessiens. If they do have such space, it is shared 
 between all users of their Plato signon. For HITS to support 
 such visiters, the following are needed: 
 
 1) Visitors may write and run programs even if they are 
 not allocated file space. 
 
 2) They shculd not be able to interfere with regular users 
 cf HITS. 
 
 3) Help paqes shculd be provided to answer their guestions 
 without Deeding an instructional book or teacher. 
 
 4) WITS should wcrk reasonably well with a single user. 
 
 2.. 6_. Future Users 
 
 In the next few years it is expected that the Plato system 
 will expand to include several computers at different 
 universities. The designers cf HITS are trying to make their 
 system transportable to other Plato systems. To do so, they 
 expect the following: 
 
 1) Eiverse user needs, as above. 
 
 2) Visitors may be familiar with the Plato editor, and 
 want a similar editor fcr HITS. 
 
 3) Resource use ty HITS may be a critical factor. 
 
 4) HITS data structures should te stable, even if the 
 host system is occasionally unstable, since the HITS 
 designers will not be around to correct problems. 
 
Chapter 3 
 The Elato IV System 
 
 When designing a compiler system for a particular 
 environment, it is often just as important to understand what 
 that environment can support as it is to understand what the 
 users will need. In early 1973 it was thought, fcr one reason 
 or another, that Elate couldn't support student compilers. 
 Claims were made that Tutor, Plate's programming language, was 
 net powerful enough fcr a compiler; Tutor's data areas and 
 structures were too small cr too simple; or Plato's CPU capacity 
 was insufficient. That was before Axel Schriner designed, and 
 he and the author iiplemented, their first BASIC system. They 
 showed that Plate could support a compiler system, if that 
 system were designed and inplemented carefully, and if the users 
 were running "reasonable" programs. Since the capabilities of 
 Plato strcngly affected the design of WITS, the next few 
 sections describe Plato, sc that later discussions of WITS will 
 be mere firirly based. 
 
 Ihe goal in the design of Plato was to provide high guality 
 educaticn at low ccst [ Bitzer , 1973 ]. The method of achieving 
 this goal was to use a powerful computer to enable the creation 
 of quality instructional materials, and to keep the cost per 
 student low by running hundreds of students. One of the 
 important characteristics of quality CAI is fast and flexible 
 
10 
 
 feedback to the student, giving better reinforcement in 
 learning. Hew Plato provides fast response to student input is 
 described in the next two sections. One section is concerned 
 with the central computer, the other section outlines the 
 cemmun icatiens system. 
 
 3_j_K C ent r al C omputer Arch it ecture 
 
 The computer on which Plato runs is one of Control Data 
 Corporation's 60C0 series. Specifically at the Urbana Plato 
 system, a Cyber 73 is used. The Cyber 73 has two Central 
 Processing Units (CPUs) , and ten Peripheral Processing Units 
 (PPUs) . The FPUs ccntrcl communications between the computer 
 and ether devices, such as printers, tape drives, and the disk 
 system. In addition, the PPUs handle the main part of system 
 job scheduling, telling the CPUs what to do. The CPUs do most 
 of the work in running prcgrams, including the execution of 
 Plato lessens. Mere on the design of the central computer may 
 be found in I" Thorton, 1970 ], though he basically discusses the 
 CEC 6€CC. 
 
 Many standard interactive computer systeis employ something 
 known as "swapping" in their operation. Swapping involves 
 keeping the informaticn needed for all users on soie secondary 
 memory device, generally slower and cheaper than main memory, 
 and transfering one user's information into main memory whenever 
 he needs to execute. This is mainly an economic feature, 
 allowing the computer to get by with less nain memory than would 
 
11 
 
 be needed if all active users were kept there all the time. The 
 transfer speed between the secondary lemory and main memory is 
 often an important factor in how well, or how many users, the 
 system can run, both of which are important aspects of the Plato 
 
 system . 
 
 In order to provide good response time for many users, 
 Plato uses Control Data Corporation's Extended Core Storage 
 (ECS) for its secondary memory storage. The transfer rate 
 between ECS and Plato's main memory (called Central Memory or 
 CK) is 6CC million bits per second. This high transfer rate 
 allows Fiatc to swap its users in and out of CM very guickly. 
 However, in addition to Plato using ECS to perform a fast swap 
 ot users, Flatc's programming language allows users to directly 
 access data areas in ECS. Thus, ECS goes beyond -just being a 
 transparent system implementation feature, invisible to the 
 users; it affects the whole design of data manipulation 
 programs, including those in the WITS system. The data areas in 
 ECS that a lesson may reference are described in Section 3.5. 
 
 Many computer systems use disk packs for their swapping 
 medium. Due to its much longer access time and lower transfer 
 rate, disk packs are used by Plato only for the permanent 
 storage of icf reguently accessed data. Among the types of 
 informaticr Plato stores on disk are the permanent records for 
 all users, the scurce code for lessons, files for collection of 
 data en active students, and files for normal lessons to store 
 data in. At the start of a session, a user's information is 
 
12 
 
 read from disk into ECS, and it is stored back on disk when he 
 signs off. Ey storing a user's intonation in ECS during a 
 session, the number of disk accesses required to run a student 
 is reduced, and the time needed to access a user's information 
 is shortened. A similar strategy is employed with most other 
 data references. For example, when editing the source code of 
 Plato lessens, the text is brought into ECS in blocks of a few 
 hundred words, frcm where it is edited and later returned to 
 disk. 
 
 3.-2_. Te rmina l Communications 
 
 In providing fast response to user input, two things are 
 important, the time reguired to set up a user for processing and 
 the ccumunicaticn time tc the terminal. The swapping of users 
 was briefly discussed in the preceding section, while this 
 section describes the communication to the terminal. This 
 communication did not, however, affect the design of HITS as 
 much as did Plato's architecture, so it is described even more 
 briefly. More complete information is available from 
 rstifle,1572]. 
 
 Each Plate teisinal is designed to connect to a voice grade 
 phone line (1260 baud), which is in turn connected to a Plato 
 Site Controller. Each site controller handles the input and 
 output of 32 terminals. Input to the computer from each site 
 controller is provided by a phone line to the Network Interface 
 Unit or NID [ Tucker, 1971 ]. Cutput from the central computer is 
 
13 
 
 passed to the NIU, where it is formatted into a video signal. 
 Output to 1008 terminals reaches over a video cable from the NIU 
 to all site controllers, each of which picks off the output 
 meant for their own 32 terminals. 
 
 At the central computer site, input and output through a 
 channel tc the NIO is directed by a program running on a PPU. 
 This FEU program stores key input from the terminals in ECS and 
 tells a CEU program where to find the key input. The PPU 
 prcgrair is alsc responsible for picking up the output waiting to 
 qo to the terninals and sending it to the NIU. The Plato 
 interpreter pells the input tables looking for keys every 50 
 milliseconds, giving each terminal with a key a timeslice of 
 computation. In addition to keys from the NIU, Plato may 
 generate pseudo-keys to indicate that a terminal needs to 
 continue seme computation that was previously interrupted. 
 
 3.3. Student Terairal 
 
 The Plate IV student terminal is designed tc provide 
 features desireable for many teaching applications. The basic 
 terminal includes a graphic display panel for output and a 
 keyset for input. Cptional accessories include a slide selector 
 for displaying slides on the panel, an audio device supporting 
 recorded messages, and a touch panel for providing touch 
 sensitive irput. Jacks are provided on the back of the terminal 
 for adding external devices. The bandwidth to the terminal is 
 126C baud, higher than that used at most timesharing systems. 
 
14 
 
 The terminal features that affected the development of WITS are 
 descrited below. A more complete terminal description may be 
 obtained frcm [ Stifle, 1973 ]. 
 
 The display device in the terminal is an 8 1/2 inch square 
 plasma pannel, containing a grid of 512 by 512 dots, each of 
 which may be illuminated independently. The plasma panel 
 display needs no refreshing to held a display, as does a CRT, 
 and its orange dots on a black background provide high contrast, 
 flicker free cutput. The display may be referenced in "fine 
 grid" rotation, using (x#y) pairs in the range from (0,0) to 
 (511,511) to indicate points. Alternately, the panel may be 
 referenced in "coarse grid" notation, as 32 lines of 64 
 characters each. Each character position is 16 dots high by 8 
 dots wide. 
 
 Since student programs in the WITS system may be longer 
 than 32 lines, some method is reguired to show only part of a 
 student's program at once. In a "teletype" editor for BASIC 
 programs, this is dene by writing lines down the screen and then 
 wrapping arcund tc the top of the screen. In a "cursor" editor, 
 the student's workspace is divided into three "pages" of 30 
 lines each, with the student being able to move from one page to 
 another. In a "tutor" editor, so called because of its 
 resemblance to the standard Plato source editor, the student 
 moves a "frafe" arcund within his program, and all lines within 
 the frame are displayed on his screen. 
 
15 
 
 Since the display width is only 64 characters, the maximum 
 lenqth cf a line cf text in WITS was chosen as 60 characters, to 
 leave space fcr displaying line numbers- Continuation lines did 
 not appear to be necessary, but were implemented in the Fortran 
 compiler as an extra feature. Output from a running program is 
 - 1 -- cn "^racters, a significant departure from the 
 
 : width cf 120 or more characters 
 
 _ "I T^_Jj-_J 
 
 *K 
 
 
 i the plasma panel is accomplished 
 :ter generator. This generator 
 i which are stored the dot patterns 
 Each memory contains the 
 •rs, each character consisting of 8 
 il can take from the character 
 ;rn that represents a character and 
 screen. Two of these memories are 
 :acters, i.e., the representations 
 > considered to be the most useful. 
 \ loaded under program control with 
 sires. This "alternate" character 
 standard uses include loading a few 
 .) mathematics lessons, or whole 
 alphabets needed in foreign language lessons. Another very nice 
 way tc use the alternate character set is to design pictures 
 using several characters from the alternate character set, and 
 tc display the picture very rapidly, at character display speed, 
 rather than at line drawing speed. A good example of this is 
 
Mi 
 
 The terminal features that affected the development of HITS are 
 described below. A more complete terminal description may be 
 obtained frcm [ Stifle, 1973 ]. 
 
 The display device in the terminal is an 8 1/2 inch square 
 plasma pannel, containing a grid of 512 by 512 dots, each of 
 which may be illuminated independen 
 display needs no refreshing to hold 
 and its orange dots on a black backgrou 
 flicker free cutput. The display may 
 grid" rotation, using (x,y) pairs i 
 (511,511) to indicate points. Alternat 
 referenced in "ccarse grid" notatic 
 characters each. Each character positi 
 dots wide. 
 
 Since student programs in the 
 than 32 lines, some method is reguiied 
 student's program at once. In a "t 
 programs, this is dene by writing lines 
 wrapping arcund tc the top of the scree 
 the student's workspace is divided in1 
 lines each, with the student being ablt 
 
 another. In a "tutor" editor, so caliea Because oi its 
 resemblance to the standard Plato source editor, the student 
 moves a "fraire" arcund within his program, and all lines within 
 the frame are displayed on his screen. 
 
15 
 
 Since the display width is only 64 characters, the maximum 
 length cf a line cf text in WITS was chosen as 60 characters, to 
 leave space for displaying line numbers. Continuation lines did 
 not appear to be necessary, but were implemented in the Fortran 
 compiler as an extra feature. Output from a running program is 
 also limited to 60 characters, a significant departure from the 
 mere ccnverticral line printer width cf 120 or more characters 
 fcund en racst systems. 
 
 Alphanumeric writing on the plasma panel is accomplished 
 using the terminal's character generator. This generator 
 implcys four "memories," in which are stored the dot patterns 
 that represent characters. Each memory contains the 
 representation of 63 characters, each character consisting of 8 
 times 16 dots. The terminal can take from the character 
 memories the 8 by 16 bit pattern that represents a character and 
 display it anywhere on the screen. Two of these memories are 
 built with the "standard" characters, i.e., the representations 
 of the 126 characters that are considered to be the most useful. 
 The other two memories may be loaded under program control with 
 any character set the user desires. This "alternate" character 
 set has many uses. Some standard uses include loading a few 
 special characters needed in mathematics lessons, or whole 
 alphabets needed in foreigr language lessons. Another very nice 
 way to use the alternate character set is to design pictures 
 using several characters from the alternate character set, and 
 tc display the picture very rapidly, at character display speed, 
 rather than at line drawing speed. A good example of this is 
 
16 
 
 the Plato IV version of the biology lesson "fly" [ Hyatt, 1972 ], 
 in which fruit flys with various genetic traits are displayed 
 using combinations of alternate characters. 
 
 One way of thinking of the loadable character set is as a 
 way of changing the display form of Plato internal character 
 codes. Conversely, if the loadable character set contains a 
 rearrangement of the standard character set, this can be thought 
 of as rearranging the internal codes used to store characters. 
 Standard Plate format for character storage is a Mixture of six, 
 12, and 18 tit codes. Opper case letters, such as commonly used 
 by programming systems, are 12 bit codes in standard Plato 
 format. The lessens in the HITS system use the alternate 
 character set to rearrange the internal codes of characters, so 
 each supported character can be stcred in a six bit code. This 
 decreases the space needed to store a program, and also, 
 decreases the complexity of the compilers and editors in the 
 HITS system. 
 
 The terminal contains a vector generator, allowing it to 
 draw lines, given only the endpoints of each line. This allowed 
 the incor pcration of some plotting features in the implemented 
 BASIC language. On PLORTS, one flat bed plotter was shared 
 between all students of each Computer Calculus section. On 
 Plato, graphic plotting was available at each student terminal. 
 
17 
 
 3_.4_. Software 
 
 Plate supports but one language, Tutor [ Sherwood, 1 974 ], for 
 its users. Tutor has developed under the direction of Paul 
 J. Tenczar, head cf Plato's system software staff, as a command 
 oriented, second generation language. It is much more powerful 
 and easy to use in teaching applications than most programming 
 languages ard many CAI languages [ Lower, 1 976 ]. In non-teaching 
 applications, such as the HITS system. Tutor provides as much 
 power as many general programming languages, though it is 
 sometimes awkward in such situations. To use Tutor for 
 non-teaching applications often reguires much training and 
 practice, after which it may still te difficult to use. 
 
 
 A Tutor program is called a "lesson," and consists of a few 
 hundred to a few thousand lines of code. Each lessen is further 
 divided into "units," each containing anywhere from one to a few 
 hundred lines of code. Program seguencing has traditionally 
 be^n from unit to unit, with each unit performing a specific 
 function. This allows easy structuring of a lessen into 
 functicnal nodules. 
 
 Each Tutcr command may reguire many machine operations, and 
 for the Tutcr compiler to generate machine code for each command 
 would result in very large binaries for lessons. To reduce the 
 code needed in each lesson, the compiler "condenses" Tutor code 
 into an easily interpretable form for the runtime system to 
 interpret. Tc save execution time, however, the compiler 
 qenerates machine cede for expressions, which may then be 
 
18 
 
 directly executed by the computer. 
 
 Like all the ether information needed for each user, 
 lessons are kept in ECS and swapped into CM only when needed. 
 The organizaticn of a Tutor lesson into units relates itself 
 very well with Plato's architecture. Each unit is a self 
 contained part cf a lesson, and gets swapped into CM 
 independently of the rest cf the lessen. In trying to write 
 fast Tutor code, one remembers that there is seme overhead in 
 bringing units into CM, and that it may be faster to branch 
 within the unit than to load another unit from ECS. 
 
 The data referenced by Tutor lessens is kept separate from 
 the lesson itself, and the interpretable code within the lessen 
 is never changed during execution. Thus, the condensed code for 
 all lessens is automatically reentrant and reuseable as far as 
 Plato is concerned. This allows a minor speedup by not having 
 tc write units tack to ECS after execution, and a major savings 
 in ECS use ty allowing any number of users to share the ECS 
 binary cf a lessen. 
 
 3.5. Tutor Data Areas 
 
 Previous sections have mentioned the data storage resources 
 the Plato system has, namely CM, ECS, and disk space. In the 
 distant past, normal Tutor lessons could only access data in 
 Central Memory, with Plato controlling all reading and writing 
 of ECS. Since then, additional commands have been added to 
 Tutor to allow lessens tc access data in CM, ECS, and en disk. 
 
19 
 
 Since lessens in the WITS systea use all three of these storage 
 areas, their characteristics and use are described below. 
 
 Each user, when he signs onto the Plato system, is 
 allocated a 40C-500 word area of ECS, called the "student bank." 
 A portion of this, 150 words long, is called "student 
 variables," and can be modified explicitly by the code of 
 whatever lessen the user is currently in. The rest of the 
 student back is used by Plato to store status information needed 
 during a session. Much of the student bank, including the 
 student variables, is saved en disk between sessions, often 
 allowing the student to resume a lesson at a later session at 
 the point frcm where he left it earlier. 
 
 In addition to student variables, a Tutor lesson may 
 request an additicnal area in ECS called "common." Hhereas each 
 user has his own student variables, there is only one copy of 
 each cemmon, shared between all users of a lesson. A common may 
 reside permanently en disk when not in use by any lesson, being 
 brought into ECS by Plato when needed, and written to disk when 
 no longer referenced; or it may be "temporary" common, which is 
 net saved on disk between sessions. In addition, a number of 
 lessens may share the same ECS copy cf a permanent common. A 
 common may new be up to 8050 words long, and is ideal for the 
 storage of small to medium amounts of data, due to its low 
 overhead in disk accesses and its easy accessibility in ECS. 
 
20 
 
 If a Tutor lessen needs lore storage space, it can request 
 an additional area of ECS that will be individual to the user. 
 This area is called "storage," and Bay be op to 1500 words long. 
 Unlike student variables cr coamon, Plato does not save storage 
 variables en disk between sessions. Like student variables, 
 each user of a lesson will have his own set of storage 
 variables. Storage is not shared between users, as is comon. 
 
 All three of these memory storage areas, student variables, 
 common, and storage, reside in ECS. 1c perform calculations on 
 the data in these areas, however, they aust be in Central 
 Memory. Some method is needed for Tutor lessens tc aove this 
 data back and forth between ECS and CM. Plato will, at the 
 start of every timeslice, load the student bank, including the 
 student variables, into a fixed buffer in CH. The student 
 variables may then be accessed by the lesson, and they are 
 written back tc ECS by Plato at the end of the timeslice. Since 
 Plate automatically does this for the user, few people 
 distinguish between the ECS copy of the student variables and 
 the CM copy of the student variables. 
 
 An area is also allocated in CM for the loading and 
 unloading cf common and storage. The area where student 
 variables are loaded is called *n* variables, while the area for 
 cemmon and storage loading is called *nc* variables. Since *nc* 
 variables are only 1500 words long, only portions of coaaon and 
 storage can be loaded at one time. Commands are provided in 
 Tutor to direct Plato to automatically load and unload these 
 
21 
 
 areas of common and storage into *nc* variables at the start and 
 end of every timeslice. It is up to the lessen to decide what 
 tc load, and to see that the loaded areas do not overlap. 
 During the timeslice, the lesson can do any calculations it 
 wants en the *nc* variables, and those *nc* variables that are 
 "protected" by being loaded from ECS will be saved in ECS until 
 the next timeslice. The *nc* variables that were not 
 "protected" will te zero en entry tc the next timeslice. It has 
 been possible in the past to reference unprotected *nc* 
 variables during a timeslice, which provided very convenient 
 "temporary variables," whose values disappeared at the end of 
 the timeslice. Ihis is no longer safe, since users no longer 
 know when their timeslice will end. 
 
 Until recently, Tutor lessons could not access disk 
 directly. Their only areas of permanent storage were in a 
 user's student variables, which Plato would save on disk when 
 the user signed off, or in permanent common, which Plato would 
 return to disk when the last user left the last lesson 
 referencing that cemmen. Direct disk accessing was provided for 
 Tutor lessens in order to allow users to store large amounts of 
 infrequently accessed data, such as is needed in a filing system 
 for student programs. 
 
 Disk files that Tutor lessens may access are called 
 "datasets," and are organized into fixed size records which are 
 anywhere from 64 tc 512 words long. Information read from disk 
 may be sent to the ECS copies of student variables, common, or 
 
22 
 
 more traditionally, storage. Users of one lesson may be 
 connected to different datasets, and a user may switch froi one 
 dataset to another during execution. 
 
 3_.6_. Besource Limitations 
 
 When tfce designers of the BITS system first started on 
 Plato, the system was rather small compared to its current size. 
 At that time it had only a single CDC 6400 CPU, only 500K words 
 of ECS, and a new 8 41 disk system with three or four disk packs. 
 At present, the Plato system is attempting to expand from two 
 6400 CPUs in one main frame to four CPUs in two main frames. 
 Their disk system is now both larger and faster, and consists of 
 afcout a dozen 844 disk drives. ECS has been expanded to the 
 maximum of two Billion words. Also during the past few years, 
 the nunber cf users on Plato has increased tremendously. In 
 cider to assure a minimum standard of service to all users, the 
 Plato staff has placed some restrictions on all scarce 
 resources. Naturally, not all users are expected to use all 
 resources tc the lisits. 
 
 The system limits en resource use, particularly on 
 processing power, ECS use, and disk accesses, have been outlined 
 by the Plato system staff. The following values are taken from 
 f Tenczar , 1974 ], where the expected limits for the following two 
 or three years were described. Enough processing power is 
 available tc allow twe thousand Central Processor instructions 
 per user per second. ECS space is available for about 1500 
 
23 
 
 words per terminal, and disk accesses are available for about 
 one access per user per ainute. These limits are what the 
 system has available, but luch cf each resource are used by the 
 system in -just running the student. The conclusions reached 
 were that Plate could support the following type cf operation: 
 "four terminals sharing a 6000 word lesson for at least 15 
 minutes, using 20CO-3000 instructions per terminal per second." 
 
24 
 
 Chapter H 
 WITS Design Philosophy 
 
 Ie previous chapters, we have discussed two of the 
 influences en the desiqn of WITS, the expected users of WITS and 
 the computer system on which it would run. This chapter 
 discusses our desiqn philosophy, that is, not what we did, but 
 our attitude as we did it. Our first goal in designing the WITS 
 system was tc provide an interactive compiler system that many 
 people could use. Our second goal was to determine how far we 
 cculd stretch the capabilities of the Plato system, to find out 
 what it could really support. In this second respect, we have 
 been surprised: Plate has been able to support more than we had 
 oriqinally expected. 
 
 H^l_. Complete _ System 
 
 Since cne of our goals was to serve as many users as 
 possible, we had to provide enough features so that they would 
 want tc use WHS. For those people who were already using an 
 established timesharing system, such as PLOETS, we had to 
 provide as many features of the existing system as possible. 
 For those who were not already using a timesharing system, it 
 was important that cur system be easy to use even if one had no 
 previous experience. In discussing a "complete" system, we mean 
 a logical structure of filing systems, editors, compilers. 
 
25 
 
 interpreters, and debug packages. Each of these components is 
 descrited below. 
 
 The purpcse of an editor within the WITS system is to allow 
 the student to write and modify a program. It should be 
 organized in a narner to make program preparation a simple, easy 
 to understand operation. If a single editor is not suitable for 
 editing programs in different languages simply, multiple editors 
 are needed, each one suited for a different programming 
 language. If, in addition, the users of the editors cover a 
 wide range cf sophistication and experience, it may be possible 
 tc provide tore complex, more powerful editors for those with 
 qi°atGi ability, while still filling the needs of more 
 inexperienced users with the simpler editors. 
 
 The purpose cf a filing lessen within the WITS system is, 
 as with the source editors, tc facilitate program preparation. 
 A simple filing system will allow the user to save a program and 
 retrieve it later. More complex filing systems may allow a two 
 level file structure, manipulations of multiple files, access of 
 files by multiple users, or any number of other options. Two 
 important features of filing systems are the resources used for 
 saving files and the stability of the filing structure under 
 adverse conditions. 
 
 Since Plato only supports a single language for its users, 
 for students to write programs in another language requires the 
 construction of a compiler for that language and an interpreter 
 for the internal code generated by that compiler. The job of 
 
26 
 
 the compiler is to perform syntactic and semantic analysis of 
 the user's program while generating an easily interpretable 
 internal fcrm of his program. An interpreter then runs over 
 this irtercal form executing each statement. Upon termination 
 of the running program, either normally or abnormally, it is 
 possible tc add a debug package to allow the user to display the 
 contents of any of his variables. 
 
 i*.. 2. Binimal^Resource .Use 
 
 Since the Plato system supports simultaneously several 
 hundred students, it is very restricted in the resources it can 
 qive tc an individual student. The expected limits on resource 
 use were described in section 3.6. In order to assure that the 
 WHS system wculd work once it had been implemented, its design 
 emphasized minimal resource usage. With this design we hoped to 
 approach as close as possible tc these limits, but we knew we 
 could never reach them. Important resources we considered 
 included disk space, disk accesses, ECS reguirements, and CPU 
 usaqe. 
 
 In designing the filing lessons, the major resources under 
 consideration were the disk space reguired to store many 
 programs, the disk accesses reguired to save or fetch a program, 
 and the ECS needed fcy the filing lessen and its directory of the 
 disk. These amounts we used of each of these resources could be 
 traded eff to have an improvement in cne of the others. For 
 example, keeping the directory of programs on disk would reduce 
 
27 
 
 the amount of ECS needed, but would increase the number of disk 
 accesses required to manipulate programs. Keeping all programs 
 in a single block on disk would reduce the number of disk 
 accesses, tut would increase the disk space needed. Three 
 important pcints were considered in deciding how to trade off 
 various resource uses. First, if the filing lesson used too 
 nuch ECS, at times it might net be accessible to the student due 
 tc a shortace cf ECS, even if all the student wanted was to save 
 his program and leave. Second, if the directory for the 
 programs was kept in ECS, it would be possible for the disk to 
 be chanqed, and a system crash tc cause the changes to ECS 
 common tc be forgotten, resulting in an cut of date directory. 
 Third, the Elato system can regulate the speed at which disk 
 accesses are dene, but ECS usage and disk space usage are 
 pre-determiced quantities. Thus, if we could reduce our ECS use 
 or disk space use by requiring more disk accesses, it might make 
 WITS mere usable, if enly slightly slower. 
 
 In the editors and compilers in WITS, the two important 
 resources we had to consider were ECS reguirements and CPU 
 usaqe. Whenever there was a guesticn of whether to inplement 
 seme lanquage or compiler feature, the usefulness of that 
 feature was traded off against the resources needed by it, the 
 work required to iirplement it, and the effort required to 
 maintain it. 
 
28 
 
 J4_- _3_. L angu age Change s 
 
 When seme language feature appeared too costly to be 
 iaplemented in WITS, we often felt obligated to provide some 
 substitute feature. The best example of this is the use of 
 READ-WFITE-F05M AT statements in standard Fortran. Due to the 
 complexity of these statements, both in syntax and semantics, 
 much ccmpiler cede would have to be written to compile these 
 statements, and the CPU time needed to execute them would slow 
 dewn interpretation significantly. The language features 
 provided, as an alternative, were fenat free PRINT and READ 
 statements. In fact, it is becoming standard to use format free 
 I/O statements in introductory programming courses, as evidenced 
 by a standard Fortran programming textbook, "Ten Statement 
 Fortran Plus Fortran IV" [ Kennedy , 1970 ]. Thus, we felt no 
 obligation tc stick to programming language standards when such 
 standards required significantly mere resource use. 
 
 One "justification for leaving out expensive compiler 
 features is the improved response this allows. The student 
 learns nothing while the compiler is computing; it is only when 
 the compiler cr interpreter interacts with the student that the 
 student can learn. Thus, the faster the compiler can respond to 
 input from the student, the faster the student can learn. 
 Learning is especially hindered if the compiler system is so 
 slow as to not even allow the student to enter his program at a 
 reasonable speed. 
 
29 
 
 Another justification for leaving out expensive compiler 
 features is the increased compiler usage this allows. The 
 author benefited in high school from the availability of free 
 computing time, limited only by the availability of terminal 
 time. One of his personal goals in designing the HITS system 
 was tc provide a similar system, where a student could write and 
 run as many programs as he desired. The only way he could do 
 this was tc make the WITS system as cheap to use as possible. 
 
 4^4^ Stabl e Sy stem 
 
 As authors en the early Plato IV system, we became well 
 aware of what occasional system crashes could do to certain 
 types of data storage methods and structures. As HITS 
 developed, we endeavored tc design our data structures so as to 
 be unaffected by system crashes. Cf course, we were not always 
 entirely successful, but we did succeed in making some 
 structures less affected by system crashes. For example, the 
 directory in ECS for one of the filing systems was designed so 
 it didn't change when programs were saved or retrieved from 
 disk. Thus, a system crash did net result in an incorrect file 
 directory. Another example would be that if a student enters 
 WITS with a program saved in his student record, the automatic 
 checkpointing of his record to disk while he is running is 
 turned off. That way, if the system crashes while he is 
 running, his signon record with the program in it will not have 
 been overwritten by whatever was in his student bank while he 
 was running. 
 
30 
 
 Chapter 5 ' 
 The WITS Systei Sow 
 
 The first few chapters of this thesis described the users 
 of WITS and the computer system on which it runs. The fourth 
 chapter described the design decisions we aade in building it. 
 Toqether these chapters detail why and how the WITS systei was 
 iiplemented. This chapter describes the resulting systea, its 
 appearance, its users, and its operational characteristics. 
 
 5.1 . Structure 
 
 The first EASIC systea on Plato was iapleaented with filing 
 system, editor, ccmpiler, and interpreter all contained in a 
 single lesson. In order to expand the system to include more 
 compilers we had to break it into connected modules, with well 
 defined interfaces. The structure of Tutor allowed the BASIC 
 compiler/inter prefer to be placed in one lesson, accessible from 
 a number of editors; and the editor/filing systea to be placed 
 in another lessen, with access available to a number of 
 compilers. At the same time, work was in progress on a Fortran 
 compiler, and these changes allowed the existing editor and 
 filing system to be used to test this new compiler. 
 
 Currently there are three editors available in the WITS 
 system. The first, called "linedit," is essentially the saae 
 editor as was used in our original EASIC systea, though it has 
 
31 
 
 been rewritten twice. This editor is line oriented, and looks 
 quite similar to the editor that was available en the PLOHTS 
 system. In our implementation, linedit is quite suited for 
 BASIC programs, but may also be used for other languages. 
 
 The second editor built for the HITS system, called 
 "cursedit," is a cursor oriented editor, quite similar in 
 appearance tc those used in the CAPS system. All editing 
 actions take place at a "cursor" on the screen. The user has 
 available function keys both for positioning the cursor on the 
 screen, and for performing line, wcrd, or character operations 
 on the text of his program. The ability to specify line numbers 
 in cursedit has net been implemented yet, i.e., it is not yet 
 suitable for editing EASIC programs. It has, however, been used 
 by CS1C5 students fcr running Fortran programs. 
 
 The third editor, called "tutedit," is currently under 
 construction. This editor is similar in appearance to the 
 standard Flatc source editor, and is intended for those users 
 already familiar with such an editor. He plan for it to be able 
 to handle programs with and without line numbers, so it may be 
 used fcr both EASIC and other languages. 
 
 All three of these editors will use very much the same 
 internal format for source programs, in order to allow the user 
 tc move with his program from cne editor in HITS tc another 
 without requiring a let of processing. This allows him to 
 access any cf the compilers in the HITS system, tc move to any 
 of the ether editors, and to use any filing system in HITS. 
 
32 
 
 Also, by standardizing the internal foraat of user programs, and 
 the interface reguireaents between lessons. He have Hade it men 
 easier for additional lessens to be added to the WITS systea. 
 
 Two filing lessons are currently in use in the WITS systea. 
 The first was designed in the fall of 1973 along with the line 
 oriented editor, and was built into that editor. Each prograa 
 in this filing systea is stored in a separate block on disk, 
 thus reguiring only a single disk access to either save cr fetch 
 the prcgraa. The directory fcr the disk resides in the lesson*s 
 common, and indicates for each student signon the block nuabers 
 that the student may save prograas in. The student references 
 these blocks by way of letters A, B, C, through J, which the 
 lesson uses to index into the list of blocks for that student. 
 This results in a filing system that reguires very few disk 
 accesses and a small directory in ECS, and is very stable since 
 the directory does not change when prograas are saved or 
 fetched. A large amount of disk space is "wasted," though, 
 since blocks are allocated even if there is no program saved in 
 them, and because only one prcgraa is placed in each block. 
 
 The second filing lesson in BITS was designed in the fall 
 of 1975, and was built to reduce the aaount of disk space needed 
 for saving student prograas. Two methods Here used to reduce 
 this space. First, prograas were packed to allow more than one 
 proqrat per disk block, and second, space was not allocated in 
 the disk file until a prograa was actually to be saved. This 
 did result in a substantial savings in disk space. 
 
33 
 
 
 Unfortunately, it also resulted in a very large directory for 
 the disk file in ECS, and a directory that changed when programs 
 were saved cr deleted. 
 
 Currently accessible from the editors in HITS are working 
 compilers fcr Fortran and BASIC. The BASIC compiler is 
 essentially the one used in our original BASIC system cf 1973. 
 The Fortran compiler is much newer, and is not really complete 
 yet, even tfcouqh it has enough basic features and is reliable 
 enouqh that it was used briefly fcr CS105 students in the fall 
 of 1975. Cf course, these are not real "compilers," they have 
 to qenerate an internal cede for the user's program and then 
 interpret that internal form. Thus each of these compilers is 
 built in two parts, the compiler section and the interpreter 
 section, which could be in separate lessons, but are currently 
 together in ore lesson. 
 
 Two ether compilers are currently accessible in the HITS 
 system, but only fcr testing purposes. One is for an extensible 
 languaqe called "extran," and has been worked on ty Bruce 
 Parrello. The other compiler is beinq constructed by Bruce 
 Copland, and should be able tc execute a subset of PL/1 next 
 fall. 
 
 5,.2_. Sophistication 
 
 There are several reasons for makinq the HITS system fairly 
 unsophisticated, as have been mentioned in previous chapters. 
 Our attempt at unscphistication has been very successful. He 
 
34 
 
 provide a very tasic interactive compiler system on which 
 students can learn to write programs. No attempt has been made 
 for oui lessens to teach the student how to program, but only to 
 let him practice what he has learned elsewhere, lith this goal, 
 the best thing we can do to help him learn to program in the 
 real wcrld is to provide a system where he can learn by 
 practice. 
 
 5_.J_. Speed 
 
 He have been impressed with the speed at which our 
 compilers and interpreters run; we would not have guessed that 
 Plato could have supported such straight computing as is done in 
 compilers and interpreters. If one compares the turnaround time 
 of many tatch systems with the time it takes to compile a 
 proqram in cne of the HITS compilers, one finds that HITS often 
 takes less time. This does not mean that HITS is fast. On the 
 contrary, waitinq at a terninal while nothing is happening on 
 the screen can be much mere aggravating than turning in a 
 punched deck cf cards and going tc read a book while the job 
 sits in the computer. Just to have some real statistics, it 
 takes approximately 100 seconds real time to compile a 40 line 
 prograii in the Fcrtran compiler at the current Plato CPO limit. 
 Interpreting the internal form of these compiled statements 
 averages 1.5 tc 1.9 lines per real time second. 
 
35 
 
 Sjji. Resource . Use 
 
 Pesides CPO use, the lessons in the HITS systei use other 
 resources, notably ECS space and disk space. Breaking up the 
 WITS systen into modules contained in separate lessons has 
 decreased the ECS needed tc run a single user, since he is in 
 only one lesson at a time. For a whole class of users, however, 
 the ECS use has only decreased slightly from our first BASIC 
 system. In particular, the BASIC ccmpiler reguires 5900 words 
 of ECS, while the Fortran compiler currently uses 8300 words. 
 The line criented editor with the built in filing system 
 requires 44CG words of ECS, while the cursor editor requires 
 only 3300 wcrds. In addition, each user in any cf the WITS 
 lessens will have his own storage area in ECS, whese length will 
 he anywhere from 320 to 1C0O words long. The default length of 
 320 words licrks quite well for proqrams up to about 60 lines 
 long using ncne or a few small arrays. 
 
 Disk space is used by the HITS lessons for permanent 
 storage of user prcgrams. The space needed to stcre each 
 program is about 60 words mere than the length of the actual 
 text in his program. Most of these extra words are used to keep 
 a line table, describing the positicn and length of each of the 
 lines in his program. The rest of these extra words contain a 
 header containing what WITS needs to know about the program. 
 Most of the groups using WITS have allocated enough disk space 
 for cne program per student tc be saved. This is apparently 
 adequate for most of their needs, especially since the WITS 
 
36 
 
 editors will cften be able to save cne program in the user's 
 student variables between sessions. 
 
 5.. 5,. Stability 
 
 As indicated earlier, one of tee goals of the design of the 
 WITS system was that it be stable, even under occasional system 
 crashes. We are guite pleased with this aspect of much of our 
 system. The line oriented editor and filing system, as 
 previously irentioned, does not reguire changes to its directory 
 of disk when programs are saved or deleted from disk. Since the 
 directory is kept in common for easy access, this is very 
 important, otherwise it would be possible for the directory to 
 fce updated in ECS, for the changes to be made on disk, and then 
 for the system to crash during the interval before the common is 
 returned tc disk. 
 
 5_.6.. Mere Work Needed 
 
 We are guite pleased with the speed and reliability of most 
 of the WITS system, as is probably apparent from the above 
 descriptions, but that doesn't mean that all the problems in the 
 system have teen solved. In particular, the stability of a 
 filing system recently added to WITS is somewhat unknown. In 
 trying tc reduce the amount of -disk space needed to store 
 programs, its directory stored in common in ECS reguired 
 changing when files were saved and destroyed. Luckily Plato's 
 reliability has improved during the past few years, but even so. 
 
37 
 
 a better algoritha in that filing system should be attempted. 
 
 Also, many improvements are possible in those parts of the 
 system that are already being used by students. In particular, 
 a few extra features might be added to the BASIC compiler, such 
 as MATBIX statements. The Fortran compiler can use a lot of 
 wcrk. Many useful features of Fortran have not been implemented 
 yet, such as full array input/output, or DATA and COMMON 
 statements. Also, the errcr diagnostics of both the Fortran 
 compiler and the EASIC compiler need to be improved, in order to 
 help the student learn where his errors are. 
 
38 
 
 Chapter 6 
 The History of HITS 
 
 As the reader has already learned, WITS has been in use for 
 almost three years now, in one form or another. It started as a 
 EASIC compiler, editor, and filing system contained in a single 
 lesson, capable of running 10 students at once and storing maybe 
 30 programs. It has grown during that time tc the current 
 system, described in the last chapter, which can support any 
 number of students at once and store as many programs as the 
 user can get disk space fcr. The sections of this chapter 
 descrite some of the steps alcng the way to the current WITS 
 system . 
 
 6 j. J . Changes to Elato Affect WITS 
 
 When we began to design WITS, in early 1973, the Plato 
 system was still experimental. It cculd support 150 users with 
 difficulty, crashes could be expected daily, and strange 
 problems with Tutcr lessens could often be traced to errors in 
 the run-time interpretation routines. Many useful features of 
 Tutor were still tc be developed, but the form of the language, 
 and most commands, remain today as they were then. The major 
 language changes that affected the development of the WITS 
 system are described below. Some of these descriptions are 
 rather technical, and might only be understood after some 
 
39 
 
 experience en Plate. 
 
 fcrce Bicrc / altfont alt 
 
 Plato terminals have ever 120 built in characters, with 
 internal cedes of six, 12, or even 18 bits used to reference 
 them. In crder to reduce the complexity of our original BASIC 
 compiler, we used six tit internal codes for all characters. 
 This shortened the amount cf space needed to store the student's 
 proqram, and mere importantly, it simplified the implementation 
 of the editcrs and compilers. This required the editor for 
 EASIC programs to collect key presses and convert them to the 
 desired interr.al cedes. This naturally reguired both Tutor code 
 and CPU tine. 
 
 In 1S73, seme time after our first BASIC system was 
 written, the Plate system announced a new command, -force 
 micro-. Normally a micro table is used to substitute a series 
 of characters for a single key press, such as substituting the 
 equation cf an ellipse for the students press of MICRO-e. The 
 -force Bicrc- command directs Plato to translate all key presses 
 throuqh the micro table, even if the user has not hit MICRO. 
 The micro table in the WITS system translates those keys in our 
 character set with six bit internal codes into themselves (about 
 50 cf these). These keys for characters with 12 or 18 bit codes 
 qet translated into unused six bit codes. For example, the 
 sinqle quote gets mapped into the code 53, which is normally 
 used fcr the Tutor assignment arrow. 
 
40 
 
 Since it Mould be a bit disconcerting for the student to 
 see an assignment arrow when he typed a single quote, we use an 
 alternate character set to change the display representation of 
 our six tit internal codes. Normally charsets are used to 
 display often plotted characters or figures without drawing then 
 dot by dot each time, such as Russian characters in a Russian 
 lanquaqe lessen. Charsets are loaded into the read/write 
 character memory of the terminal ence and then can be referenced 
 as fast as references to the built in, read only, character set. 
 The charset that SITS uses looks like the built in character 
 set, except it is rearranged a little and has fewer characters. 
 
 Side affects of having all input come through a micro table 
 and all cutput being shown through a charset are nice things 
 like havinc Shift-o delete a character as on a teletype (the 
 micro table translates Shift-o into a single press of ERASE), 
 and displaying capital letters for lower case internal codes 
 (just making the designs in the charset look like upper case 
 letters) . It should be noted that numbers and operators in 
 expressions get mapped into themselves. This allows the use of 
 standard Plato routines at execution time to process input 
 expressions and to display numerical results. 
 
 Time Slice Changes 
 
 In early 1973, the programmer of a Tutor lessen indicated, 
 by means of a -break- command, where Plato should check to see 
 if he was nearing the end of a timeslice. If he was, Plato 
 
41 
 
 wculd interrupt him at that point. When he returned from an 
 interrupt, all his *nc* variables would be zero, so before a 
 -break-, he wculd generally -unload- his common and storage from 
 *nc* variables into ECS. After the -break- command, he would 
 -load- his *nc* variables from ECS again. During a timeslice, 
 he could use *nc* variables that were not loaded from ECS, and 
 their values would remain intact for the duration of the 
 timeslice. These variables provided "temporary variables," 
 which could be used much like the local variables available in 
 many ether programming languages. 
 
 
 In August, 1973, -break- commands became obsolete, with the 
 Tutor interpreter determining when a timeslice interrupt, or 
 -autobreak-, should occur. Since an -autobreak- could happen 
 between any twe commands, temporary variables could now be 
 depended cr enly fcr the duration cf a single command, and even 
 that iray change in the future. Before this time we had been 
 using temporary variables extensively, so removing -break- 
 cemmands reguired many hours cf our time to get our lessons 
 working again. 
 
 The commands -load- and -unload- were only usable when one 
 knew where a -break- would occur, so in addition to making 
 temporary variables obsolete, removing -break- commands also 
 reguired a change in the manner cf referencing common and 
 storage. Twc new commands, -coilcad- and -stoload-, were 
 provided to automatically load and unload portions cf cemmon and 
 storage every timeslice. 
 
42 
 
 Th€ language resulting after the implementation of 
 -autotreak- was cleaner and lore powerful than the previous 
 version of Tutor. However, some UC hours of rewriting were 
 reguired to get the BASIC filing system, editor, and compiler, 
 tc wcrk with -autobreak-. Much of this could have been avoided 
 if we had known a year and a half ahead of time what changes 
 were planned for Tutor. However, probably no one knew at that 
 time what was gcing tc be done. 
 
 6.2. Eesou ice Sh ortage s 
 
 Periodically during the history of Plato, various resources 
 
 have teen in short supply compared to the demand for them. 
 
 Belcw are descriptions of each of the resource shortages the 
 
 WITS system has survived, and how each affected the development 
 of WITS. 
 
 Disk Space_ Crun ch 
 
 As with Brany ether computer systems, Plato has to be 
 careful in allocating its disk space to users. At one time disk 
 space was given to users freely, but it was soon learned that 
 such policies wasted disk space. But, even with careful 
 allocation, sometines new disk drives didn't arrive when 
 expected, cr the drives would arrive, at which point it was 
 found that the necessary disk controller had not even been 
 ordered. Scnetimes Plato was short of disk space for months at 
 a time. Cnly rarely, however, did the HITS project slow its 
 
43 
 
 development due tc the lack of space in which to author lessons, 
 but thought was given continually tc the amount of space data 
 structures vould take on disk, and how many students could run 
 with a particular disk setup. The original BASIC system, which 
 required a copy cf the entire filing system, editor, and 
 compiler fcr every grcup of users, wasted a lot cf disk space 
 compared tc later versions of HITS. 
 
 F.CS Crunch 
 
 Occasionally, during the three years that the author has 
 teen running compilers, the number of users on Plato has grcwn 
 tc where all the available ECS has been in use. When trying to 
 run classes in instructional lessons, this results in students 
 scmetiires being unable to sign on to the system, or unable to 
 mcve frcm cne lessen to another. The original BASIC system 
 resided in a single lesson, and since any number of users can 
 share the ECS copy cf a lesson, that system rarely had trouble 
 running classes. Running just cne student during unscheduled 
 time was cften impossible, however, since he was unable to 
 obtain a large amcunt of non-shared ECS. 
 
 when WITS was built, the compilers resided in lessons 
 separate frcm the lesson with the editor and filing system. 
 With this setup, it was possible fcr all students to sit in the 
 editor with the compiler unaccessible due to lack of ECS. The 
 scluticn, ence Plato allocated ECS to physical sites, was to 
 reserve a classroom for a whole class of students running in the 
 
44 
 
 compiler, and to ask other users in the classioci to leave 
 whenever ECS became scarce. Funning a single student became 
 easier with this setup since he was only charged for the ECS of 
 the lessen he was using at the time, either the compiler or the 
 editor, both cf which were smaller than the original BASIC 
 system . 
 
 The current KITS design assumes classroom use where both 
 the editor and compiler can be continuously shared between many 
 users. When modifications are made to WITS, attempts are made 
 to shorten the total ECS it uses. Also, it is desireable that 
 if the ECS situation becomes too tight to run, the student 
 should te atle to get to the filing system and save his program. 
 Uses cf WITS for other than whole classes at once will have to 
 be restricted to ti»es when ECS is plentiful. 
 
 CFU Crunch 
 
 As the number of Plato users has grown, the CPU time 
 available to each has diminished. To guarantee a certain amount 
 cf processing time for each user, the Plato system programmers 
 have added software checks to control CPU allocation. Even so, 
 the Plato system has occasionally felt sluggish to experienced 
 users. The worst such time was for about two weeks during the 
 1975 Spring semester, when Plato was running over 400 users 
 regularly. Improvements to the Plato interpreter during the 
 following sosirer allowed it to handle peak loads of well over 
 5C0 users during the 1975 Fall semester with hardly any 
 
45 
 
 ncticable delay. Since CPU use is a critical resource, the WITS 
 designers have attempted to keep prccessing tine to a minimum 
 without increasing use of other resources (such as ECS). Their 
 techniques for this are described below. 
 
 The WI7S system consists of several interconnected lessons. 
 Since a user can go from any lessen to any ether lesson, and 
 will cften move frcm an editor to a compiler and back, it is 
 important to keep the processing tine at such interfaces small. 
 This is dene by standardizing the internal format cf the user's 
 program in all the lessons. Additionally, it is important that 
 no compiler destroy information that an editor would have to use 
 CPU time tc recompute. At various times during the development 
 cf WITS, seme lessens violated the above two rules. The BASIC 
 compiler has traditionally destroyed information the editors 
 want, just to save 15 words of ECS; and a new editor used a 
 different format for programs in order to reduce its own 
 processing, but mere processing was required to access a 
 compiler than was saved. Both cf these violations have been 
 corrected, with a savings in processing tiae, and only a minor 
 increase in ECS usage. 
 
 The C£PS compiler system has a much different structure 
 than KITS has. CAPS compilers, rather than being hard coded 
 Tutor, are coded in an assembler-like language, and are 
 interpreted by a common driver, written in Tutor. Since the 
 driver is shared between all the compilers, it loses some of the 
 speed it might have if it had language dependent, optimizations 
 
U6 
 
 built in. To save processing tine, the HITS compilers are coded 
 directly in Tutor. 
 
 A third way of keeping CPU use by the HITS compilers and 
 interpreters low was to utilize Tutor commands and data 
 structures that were known to be fast. Such things included 
 using -find- commands where appropriate, referencing full words 
 rather than segments cf words when possible, and referencing 
 information directly rather than through links and pointers. 
 
 Prcbatly the greatest effect on CPO time and ECS 
 consumption was not from any cne thing done during the design of 
 the ccapilers, but rather en the method used in building the 
 HITS system. All parts of the system were designed by one or 
 mere people in discussion with ether authors, but only one 
 person implemented each part. The system was thus broken down 
 into parts that cculd be thoroughly understood by a single 
 person, allowing him to recognize optimizations when he saw 
 them. Cften, after a portion of the system was completed, it 
 was examined by the other HITS designer to make sure it was 
 understandable to both. The ether designer would occasionally 
 suqqest improvements, and both were then competent to correct 
 bugs that appeared in the lessen. 
 
47 
 
 Chapter 7 
 
 Conclusion 
 
 Previous chapters have described who the WITS compiler 
 system was luilt for, how it was built, and what its current 
 appearance is. Mention has been made several times to CAPS, an 
 acronym for the "Computer Assisted Programming System" that has 
 been developed en Plato by the Computer Science Department at 
 the University cf Illinois. This chapter compares and contrasts 
 these two student compiler systems. 
 
 I The CAPS programming system was designed to fill part of 
 the role of a consultant in helping the student write his 
 program. As the student enters his program in cne of the CAPS 
 editors/compilers, it is checked, character by character and 
 token by token, for correct syntax. Immediately upon receipt of 
 an invalid token or syntactic construct, the compiler gives an 
 error message to the student, and the editor will not let him 
 proceed until he has corrected his mistake. If the student does 
 net understand the first error message, which generally is guite 
 short, he can press HELP, and receive a mere detailed 
 explanation . If the student still does not know how to correct 
 his program, he can direct the compiler to give him a series of 
 changes, each cne cf which would make his program correct 
 syntactically. The student can make cne of these changes, and 
 continue entering his program. This is a very impressive 
 
48 
 
 operation, examples of which can be seen in [ Tindall, 1975 ]. 
 
 At program execution time, the CAPS interpreters keep trace 
 information at every step of interpretation. If the student 
 receives an execution error during interpretation, this allows 
 the diagnostic routines to actually reverse execute the 
 student's program, shewing hi« each step of the execution, until 
 he can determine where the error in his program was. This 
 process is further described in [ Davis, 1975 ]. 
 
 In the area cf compile time and execution time diagnostice, 
 the WHS system is severely lacking. At present, the student is 
 essentially tcld that the compiler can not understand some line. 
 A hint might be given as to what the compiler is expecting next, 
 but the student is not even told where in the line the compiler 
 was processing. Essentially, the student is expected to already 
 know the syntax for his programming language, and the MITS 
 compilers allow him to write programs in that language. When 
 the student receives a compiler error message, he may have to 
 look up in a reference book the syntax for the particular 
 statement he wants to use, and then follow that syntax exactly. 
 
 In the area of execution speed and resource use, the WITS 
 system comes out better than the CAPS system. The 
 editor/compiler in the CAPS system must be able to compile 
 forward performing syntax checking, and uncompile backward as 
 the studert moves his cursor back to change a previous 
 statement. At execution time, the CAPS interpreters must keep 
 trace information in order to allow their reverse execution 
 
49 
 
 routines tc wcrk. This naturally requires more CPU tiae to 
 collect this data, and more ECS space to keep the data for later 
 use. An analysis of where CPU time was being spent during 
 compilation in the CAPS system was performed last year, and is 
 descrit€d in [ White ,1975 ]. 
 
 In summary, the Plate system has two student compiler 
 systems currently being developed. Each system is designed 
 differently and has different operational characteristics. The 
 CAPS compiler system is designed to watch the student as he 
 enters his programs, and help him whenever he has trouble. The 
 WITS compiler system, described in this thesis, is designed for 
 speed and ninimum resource use, in order that the student can 
 learn programming by receiving lets of practice. Because of its 
 somewhat simpler design, the HITS system has been slightly more 
 reliable while in the construction stages, though this should 
 disappear as the CAPS system is polished up. Both of these 
 systems need mere wcrk, the CAPS system to speed it up, the HITS 
 system to improve its error diagnostics. 
 
50 
 
 Li st of Ref erences 
 
 f Alpert , 197C ] Alpert, D. and D.L. Eitzer, "Advances in 
 Computet Based Education," Science, Vol. 167, 
 March 20, 1970, pp. 1582-9C." 
 
 f Ritzer , 1973 ] Bitzer, D.L., B.A. Sherwood and P.J. Tenczar, 
 "Computer-Eased Science Education," CEBL Report X-37, 
 Computer-based Education Research Laboratory, University 
 cf Illinois, Urbana, Illinois, Hay 1973. 
 
 [Eavis,1975] Davis, A., "An Interactive Analysis System for 
 Executicn-time Errors," Ph.D. Thesis, Department of 
 Computer Science Report # OIDCDCS-R-75-695, University 
 cf Illinois, Urbana, Illinois, January 1975. 
 
 TGear,1969] Gear, C, A. Whaley and N. Weidenhofer, "The 
 
 University of Illinois PLORTS System--Provisicnal User's 
 Manual," Department of Computer Science File No. 793, 
 University cf Illinois, Urbana, Illinois, March 1969. 
 
 fHyatt,1972] Hyatt, G., D. Eades and P.J. Tenczar, 
 
 "Computer-Eased Education in Biology," BioScience, 
 22-7, July 1972, pp. 4C1-09. 
 
 r IBM 1 CAIL/360-OS EASIC Language Reference Manual. 
 
 GH2C-0699, copyright 1970, 1971 by International 
 Eusiness Machine Corporation. 
 
 f Kemeny, 1967 ] Kemeny, J.G. and T.E. Kurtz, BA SIC Progra mming , 
 John Wiley and Sons, New York, 1967. 
 
 f Kennedy, 1570 ] Kennedy, M. and M.B. Solomon, Ten Statement 
 F ort ran Plus_Fortran IV, Prentice-Hall, Englewood 
 Cliffs, New Jersey, 1970. 
 
 flower, 1976] lower, S.K., "Authoring Languages and the 
 
 Evolution of CAI," Simcn Eraser University, Eurnaby B.C. 
 Canada, Eetruary 1976. 
 
 f Nievergelt , 1974 ] Nievergelt, J., E.M. Reingold and 
 
 T.R. Wilcox, "The Automation of Introductory Computer 
 Science Courses," A. Gunther, et al. (editors). 
 International Computing Symposium 1973, North-Holland 
 Publishing Co. , 1974. 
 
51 
 
 f Schreiner, 1972 ] Schreiner, A.T., Coaputer C alculu s. 
 
 Stipes Publishing Co., Champaign, Illinois, 1972. 
 
 r Sherwccd, 1974 ] Sherwood, B.A., The TUTOR Language. 
 
 Computer-based Education Research Laboratory and 
 Department cf Physics, University of Illinois, Urbana, 
 Illinois, 1974. 
 
 [Stifle, 1972] Stifle, J., "The Plato IV Architecture," 
 
 CERL Report X-20, Computer-based Education Research 
 Laboratory, University of Illinois, Urbana, Illinois, 
 May 1972. 
 
 f Stifle, 1973] Stifle, J., "The Plato IV Student Terminal," 
 CERL Report X-15, Computer-based Education Research 
 Laboratory, University of Illinois, Urbana, Illinois, 
 June 1973. 
 
 r Tenczar, 1971 ] Tenczar, P.J. and B.A. Sherwood, "limits," 
 
 Plate System feature Notes, Urbana Plato System, Urbana, 
 Illinois, September 24, 1974. 
 
 C Thortcn, 1970 ] Thortcn, J.E., Design o f a Computer. 
 Scott, Foresman Co., Glenview, Illinois, 1970. 
 
 r Tindall, 1975 ] Tindall, H.H., "An Interactive Compile-Time 
 
 Diagnostic System," Ph . D thesis. Department cf Computer 
 Science Report # UIUCDCS-R-75-7U8, University of 
 Illinois, Urbana, Illinois, Cctober 1975. 
 
 f Tucker , 197 1] Tucker, P., "A Large Scale Computer Terminal 
 Cutput Controller," CERL Report X-27, Computer-based 
 Education Research laboratory. University of Illinois, 
 Urbana, Illinois, June 1971. 
 
 f White, 1975] white, L.A., "CAPS Compiler CPU use Report," 
 
 Department cf Computer Science, University of Illinois, 
 Urbana, Illinois, December 1975. 
 
 T Wilcox, 1975 ] Wilcox, T.R., "An Interactive Table Driven 
 
 Diagnostic Editor for High Level Programming Languages," 
 Department of Computer Science, University of Illinois, 
 Urbana, Illinois, 1975. 
 
 T Wilcox, 1 976 ] Wilccx, T.R., A.M. Davis and H.H. Tindall, 
 "The Design and Implementation of a Table Driven, 
 Interactive Diagnostic Programmin System," to be 
 published in the CACM. 
 
BIBLIOGRAPHIC DATA 
 SHEET 
 
 4. Title and Subtitle 
 
 I. Report No. 
 
 UIUCDCS-R-76-819 
 
 The Design of WITS: A Student Compiler System on 
 PLATO IV 
 
 7. Author(s) 
 
 Lawrence Allen White 
 
 9. Performing Organization Name and Address 
 
 Department of Computer Science 
 
 University of Illinois at Urbana-Champaign 
 
 Urbana, Illinois 6l801 
 
 12. Sponsoring Organization Name and Address 
 
 Department of Computer Science 
 
 University of Illinois at Urbana-Champaign 
 
 Urbana, Illinois 6l801 
 
 15. Supplementary Notes 
 
 3. Recipient's Accession No. 
 
 5- Report Date 
 
 Julv 1Q76 
 
 8. Performing Organization Rept. 
 No. 
 
 10. Project/Task/Work Unit No. 
 
 11. Contract /Grant No. 
 
 13. Type of Report & Period 
 Covered 
 
 M. S. Thesis 
 
 14. 
 
 16. Abstracts 
 
 This thesis discusses the design of an interactive student compiler 
 system called WITS, an acronym for "White's Interactive Timesharing System." 
 The WITS system currently contains two editors, two filing lessons, and 
 two compilers. Work is in progress on creating additional editors and 
 compilers, in order to better meet the needs of its users. These compilers 
 have been implemented on the PLATO IV computer system, and are being used 
 by students. Included in this thesis is a description of the PLATO IV 
 system and how it affected the development of WITS. 
 
 17. Key Words and Document Analysis. 17a. Descriptors 
 
 interactive student compilers 
 PLATO IV 
 
 7b. Identifiers/Open-Ended Terms 
 
 7c. COSATI Fie Id /Group 
 8. Availability Statement 
 
 5RM NTIS-38 ( 10-70) 
 
 19. Security Class (This 
 Report) 
 
 UNCLASSIFIED 
 
 20. Security Class (This 
 
 Page 
 UNCLASSIFIED 
 
 21. No. of Pages 
 
 5h 
 
 22. Price 
 
 USCOMM-DC 40329-P7 1 
 
DEC 1 5 1976 
 
m u m