Paul F. Seelig and Henry N. Blount University of Delaware Newark, 1971I
A Time-share Based Simulator to Teach the Use of Digital Computers
The ubiquity of the laboratory based digital computer is resoundinelv self-evident (1-20). Its role in research (2-7). in analyti&l service laboratories (8-12), in biomedical applications (13-16), and in teaching (17-20) is an increasingly important one. New developments in microelectmnics have continued to yield reduced prices of minicomput e n to the point that essentially every chemistry department can afford the four or five thousand dollar price of a popular minicomputer configured with 8K of core memory, a modest data acquisition system, and a teleprinter (21). Implicit in the acknowledgment of these facts is the incumbent responsibility which befalls departments of chemistry to train their undergraduate and graduate students in the fundamental's of laboratory based digital computers as chemical tools. Several departments now offer courses dealing with the "small machine." Purdue University has been a notable leader in this area (22, 23). In many instances, and unfortunately so, courses of this nature are added to curricula and turn out to be instruction in high-level language programming (e.g., Fortran, Basic, Focal, etc.) and, as such, compromise the benefits which the students could derive from such a course. If the student is to truly understand and appreciate the laboratory based digital computer as a chemical tool with which he or she can make contributions to the chemical discipline, then that student must he taught a t the fundamental level of machine architecture, and machine and assembly language programming. It is only then that the student develops effective rapport with computer-coupled chemical instrumentation. Although many educators acknowledge the need to train chemists a t the machine level, such training almost invariably presents itself as a burdensome task due to hardware limitations: there simply are not enough computers available in a department to he devoted to the effective teaching of such a course. An approach to this problem which has been found to be most effective in this department was to develop a simulator which operates on the University's time-shared computer system and causes the remote terminals of this time-shared system to reflect exactly the hardware functions of the single minicomputer used in the teaching of the course. This has allowed the student to become familiar with the minicomputer hardware structure, to learn machine and assemblv- laneuaees. " - . to develo~. . . edit. assemble, and execute programs which are exact facsimilies of Droerams executable on the small machine itself. . In this paper, the simulator per s6 and the use of it by a class of 20 graduate and senior-level undergraduate students is described. The Course The purpose of the course was to acquaint the student with the laboratory based digital computer a s a chemical tool. The design of the course was patterned after the summer course "Digital Computers in Chemical Instrumentation" offered by Professor S. P. Perone at Purdue Presented at the Conference on Computers in Education, Kingston, Ontario, June, 1974.
University. Fmm a pragmatic point of view, the thrust of the course was to give the students "hands-on" experience with the machine in a laboratory environment, thus removing some of the mystic aura associated with the term "computer." As a three semester-hour offering including a single three hour-per-week supervised laboratory, the course proceeded from a lecture based introduction of number systems and representations and of Boolean algebra basics to lecture and laboratory coverage of digital logic, digital input/output fundamentals, assembly language programming, basics of interfacing, and signal transmission and conditioning. Student laboratory assignments increased in complexity throughout the course and culminated in the development and implementation of an assembly language program for on-line acquisition and analysis of analytical data. Practically speaking, an effective laboratory for this course cannot operate with more than a single person having access to the machine a t any given time for software development in assembly language, and certainly with not more than two or three persons having access to the machine a t any given time during orientation to machine operation. This dictates that either several machines are needed so that the students' encounters with them can be supervised in the same location a t the same time by a single laboratory instructor, or the size of the class must be severely restricted. Otherwise, an inordinate amount of instructional time must he committed to the offering of such a course, and such a commitment is, naturally, a budeetarv imoracticalitv. In almost every chemistry department today, timeshared computer capability is available. This becomes en obvious and ready source of aid in the teaching of laboratorv based dieital machines (minicom~uters) if the simulator% developed andimplemeked such that the experience gained by the student in interaction with the time-shared system is directly transferable to the small machine. In addition to providine more "machines" to the students during scheduled laboratory periods, many time-share systems are available on a 24-hour basis and thus provide-the students with ample opportunity for free study and practice outside the scheduled laboratory periods. Such outside preparation renders the students' contact time in the laboratory far more effective than would otherwise be. "
.
A
The Systems The laboratory-based system consisted of a Data General Corporation NOVA 1200 computer configured with 8K of core memory, high-speed paper tape reader and punch, ASR33 teleprinter, 62 KHz 10-bit analog-to-digital converter, and a 1 MHz real-time clock. Associated software used by the students consisted of a binary loader, paper tape assembler, and a paper tape editor. In addition, an assembly subroutine library was made available to them to facilitate assembly language programming. The time-shared system was supported by a Burroughs B5500 processor configured with 32K 48-bit words of real memory and an additional 6M words of virtual memory. In addition to handling batch operations, 20 remote Volume 52, Number 7, July 1975 / 469
T-pJJ DEFER
WECUTE
The flow diagram of the NOVA 1200 simulator at the state level of the hardware. All switch requests from the front console are passed to KEY for decoding and execution, and those requiring memory referencing (e.g., DEPOSIT, EXAMINE, etc.) activate KEYM. Control is then passed to FCOM where Instruction decoding and execution proceeds if run is set: Otherwise. DUMMY is activated wherein the console information is printed out with control being returned to the front console. For instruction decoding and execution. FETCH retrieves the instruction from memory and provides for partial decoding. ALC handler all arithmetic and logic operations. DEFER resolves indirect addressing, and EXECUTE senses the status of 110 devices (busy and done logic) and resolves memory references.
ASR33 and/or KSR33 teleprinter terminals could also he simultaneously serviced. Fortran, Algol, Cobol, and Basic were supported hy this system. The Simulator
In considering those attributes which had to he reflected by the simulator, the design was viewed as having four major areas: front console hardware, internal hardware or instruction decoding and execution, software support for use of the simulator, and special functions allowing debug capabilities. It was desirable that the implementation of these functions in the simulator he relatively easy and that the resultant code be readable and to a large extent self-documenting. This led to the decision regarding the language in which the simulator and associated software would he written. While Fortran IV offered compatibility with a large number of computers and an even larger user base, it did not have the string or hit manipulation operations that were required. However, the structure of Algol naturally lent itself to the writing of the simulator and provided for faster execution. Therefore, the B5500 TSS Algol (24) was the language chosen in which to write the simulator and supporting software. The NOVA 1200 is a 16-bit minicomputer with four general purpose registers, multilevel indirect addressing, 256 words of directly addressable memory, an instruction set having 22 basic instructions and 2115 variations, and can he configured with from 1K to 32K of 1.2 rs/cycle core memory (25). The hardware permits up to 62 devices to be serviced with busy/done logic or interruptive control, and data transfer can he effected by either single words through a register or in blocks of words uia the data channel (direct memorv access. DMA). From the front console, there are 18 functions which can be initiated: examine or deposit accumlators (0-3): examine, examine next, deposit, and deposit next any core location; start, stop, and continue execution of instructions; and reset, instruction step, and program load. Information available from the console lights consists of current address, contents of that address (although this depends upon the pre-
vious operation), run, ion (interrupt enable), fetch, defer, execute, and carry. The fetch, defer, and execute lights indicate the state of the machine in the decoding and execution of an instruction and are not of value to the average assembly programmer. It was from this set of hardware specifications that the defining criteria for the simulator were determined. For any computer, the switches, switch register (SWR), and lights are the only direct lines of communication hetween machine and operator; hence, they comprise the machine/human interface. If this interface hecomes unnecessarily difficult to use or understand, then the time commitment required to assimilate i t outweighs the benefits gained by such an assimilation. To ease the transition of going from simulator to computer, the same commands found on the front console were employed as simulation commands. In princide, all front console operations should be implemented i n order to completely~simulatethe hardware. Realistically, however, this is not feasible due to the inherent limitations of operating in a remote environment (i.e., hardware control by the user of the processor supporting the time-shared system is limited). It was decided that two of the front console operations should not be built into the simulator. The implementation of a STOP command would have required a separate input/output (110) handler for the B5500 which would have allowed pre-scan of the teleprinter input which could have, in turn. initiated a controlled termination of the simulator's path of execution and then returned system control back to the simulator console. Secondlv. - . the PROGRAM LOAD was not implemented because of restrictions of the timeshared system disallowing the direct reading of paper tapes from the teleprinter into a program while under program control. All other console commands were incorporated and followed the logical flow of the computer at the register transfer level (26). The decoding and execution of console commands was done in two sections: KEY for all non-memory access commands (e.g., EXAMINE ACCUMULATOR, DEPOSIT ACCUMULATOR) and KEYM for all memory access commands (e.g., EXAMINE, DEPOSIT, EXAMINE NEXT, etc.) as is shown in the figure. The simulator required a set of commands identical to those found on the front console. Since input to the simulator would be throueh the telenrinter. these commands. their associated format, and the resulting action (syntax and semantics) had to be easilv comnrehended. Since a prime requirement of the simulated console was simplicity, the mnemonics used as simulator commands were identical to those on the computer console. The command line was free format, with a command heing any number of characters to identify that command. The BNF notation (27,281 for a command line was
-
(command line): : = (command)(spaee)(SWR) 1 (command) (space): : = blank / (space) blank (SWR): : = null I, (octal number) iactal number): : = (octal digit)'^ (octal number)(oetal digit) (octal digit): : = $ 1 1 1 2 1 3 14 15 1 6 17 (edmrnand): : =DEPOSIT 1 EXAMINE / DPSNXT I EXANXT / START I ACEX# / ACEX1 / ACEX2 I ACEX3 1 ACDP4 I ACDP1 I ACDP2 I ACDP3 / RESET 1 SWITCHES 1 FINISHED 1 CONTINUE I STEP / BINLD I TRAC I TRACD I TRADR 1 TRASTP I ASSEMBLE I FILE I TIME
If a command were entered with the simulated SWR heing empty, then this was equated to a null action on the part of the operator and the SWR maintained its previous value. This meant, as it does with the computer switch register per 56, that modification of the SWR would occur only as a result of specific user actions. The use of octal numbers rather than binary, which is actually the base of
the machine, provided a convenient form of I/O as well as an exercise in base conversion exercise for the student. A comparison between free field format and fixed field format was carried out with the results clearly indicating that the free field approach was needed to maintain the desired ease of operation. At the completion of each simulated console command or simulated program, the pertinent information from the front console was printed out. The second part of the simulator, instruction execution, was approached in much the same manner as the console, the desired result being the simulation of the NOVA 1200 hardware in the decodine . - and execution of the instruction set. Other than the absence of interrupt simulation, all of the NOVA instructions were duplicated on the B5500. Proper decoding of machine-instructions and their execution is not a trivial matter and, if extreme care is not taken, the integrity of the hardware-dictated logical flow will very quickly be compromised in the writing of the simulator software. Of primary concern was the development of a program with code which was neither hulky nor difficult to read and which was easily modified. Before considering the decoding and execution of instructions by the simulator, the question of the physical storage of these instructions e . , the structure of the simulated core memory) had to he resolved. Preliminary ideas of having one B5500 word correspond to,a single bit in the simulator (1simulated NOVA word = 16 B5500 words) were quickly discarded due to the excessive storage demands upon the B5500 in the simulation of even 1K of core. This led to a core structure wherein two words (32 bits) of simulator core would reside in one word (48 bits) of B5500 core. Although i t seems obvious that three simulator core words (48 bits) should fit into a single B5500 word (48bits), this is not the case since only 47 bits of a B5500 word are available to the user for hit manipulations. Algol specifications for the B5500 limit the size of a single dimension in an arrav to 1023 (29), thereby restricting the core size to approx&ately 2K of simulator core. However, by using a multi-dimensional array and a page-selection decoding scheme, it was possible to expand the simulator core to the 32K limit, although, for the purpose of simulation, 8K was sufficient in all cases encountered, and 4K sufficed for most. The NOVA 1200 instruction set can be divided into four categories: memory reference instructions without accumulator, memory reference instructions with accumulator, input/output instructions, and arithmetic and logic instructions (25). While this division of instructions along the lines of function is useful, an even more meaningful breakdown along common hit boundaries as shown in the table is quite helpful. The 11 bit strings extracted from a word are all that is needed to decode any given instruction. For the hardware, parallel operations greatly enhance the speed of this process, but for the necessarily seSit Strinas for Corn~uterWord Decoding Bits of Nova Instruction string
word
5
5-7
6
8-9
7 8
8-15 10-11
ALC, I/O ALC, I/O
MRWOA. MRWA ALC I/O ALC L C
.
.wncmonin usld am Memory R d e m e s Wlrhuut Aeevmulator MRWOA.. Memory Hdernnm With A m m u l s l o r M R W A Input and Output .I0, and Anrhmetrc and L v a ~ r A1.C Arsunmx equal uvlge of the four hnsic instruvl~onx.theaverace numbrr of Idrttilrm r r a u m d U, dmodean instruc-
.
tion issir.
quential operation of the simulator, excess bit manipulations result in added overhead. Rather than generating all 11 bit patterns for each instruction, the decoding operation p m e e d s in a tree-like manner, eliminating duplicate operations and reducing the maximum bit strings to eight with an average of only six. Instruction execution software was developed using the hardware, considered a t the register transfer level, as a model. Three basic states, FETCH, DEFER, and EXECUTE, were considered and implemented as shown in the figure. As previously indicated, interrupts were not incorporated into the simulator, but I/O from the teleprinter was included for a program operating within the simulator. The set of instructions for non-interruptive I/O was the same for the simulator as for the machine; only the appearance of the input changed. As with most operating systems, input to a program is achieved by a "read with wait" termination being signaled by a special character, carriage return, or line feed. Furthermore, echoing of characters is done in the hardware or software of the time-shared system, thereby restricting the user I/O options. Simulator input to a program was entered into a 72 character buffer from which the executing simulated program would extract the characters as needed, and, if none were available in the buffer, the simulated program would wait for input. The inherent echo feature of the B5500 time-shared system did not. however.. nreclude the execution of user de. signed assembly language echo routines. In addition to simulation of the hardware. software support was necessary to facilitate the learning of the NOVA 1200 system. Toward these goals, an assembler/editor. written in Algol, was incorporated into the simulator. This allowed the user to load an assembly source program, to assemble the program, to edit the program, and to transfer the assembled binary image into the core of the simulator. The original assembly language source program could be entered into the simulator in either of the two ways which are compatible with the NOVA: paper tape or teleprinter keyboard. Such source entry was into a usertransparent B5500 disk file which served as the actual input to the assembler/editor. The assembly language and the associated mnemonics exactly paralleled those of the NOVA. There were three edit features included in the assembler/editor: inserting, deleting, and replacing a single line of code. A listing of the assembler output, similar to that generated by the real NOVA assembler, was provided for the user. This output reflected addresses and binary contents, the assembler instructions, and errors. From this, the user could determine source errors, edit them out, and reassemble, all while still in interaction with the assemhler/editor. After assembly, the binary image could be loaded into the core of the simulator and immediately executed, thereby determining runtime errors, if any. A(thoueh instruction execution is much faster on the NOVA, this procedure of simulated assembly and execution of a machine program was more expedient than real assembly and execution on the NOVA itself because the need to load the various paper tape programs for assembly, edit, and execution was eliminated. A binary tape compatibility between the NOVA 1200 and the simulator would have allowed the binary output of programs developed on the simulator to be run on the NOVA. However, the restricted ASCII character set of the B5500 and the control of only seven bits of the teleprinter punch effectively eliminated any hope of a one-to-one correspondence. The writing of a program to reformat the binary tapes of the NOVA to a form readable by the B5500 would have been one way around the problem. However, the compromise solution decided upon was the generation of an octally coded paper tape of the assembly output which could be read back into the simulator core Volume 52. Number 7, July 1975 / 471
via a user transparent B5500 disk file, thereby showing the user a form of "binam" innut like that which-exists in going from assemhly to execution on t h s small machine. The same lihraw of basic assemhlv suhroutines which was available to u&rs on the NOVA (30) was accessible to users of the simulator. Although the simulator is slower in instruction execution than the hardware which it mimics, a number of options not normally available with the hardware itself hecome apparent in the simulator. Inherent to software simulation of hardware, particularly where the software is modeled after the hardware, is the possibility of monitoring the state of the simulator (i.e., accumulators, addresses, or decoded information) because of an expansion of the time domain. A natural manifestation was the inclusion of debug facilities wherehy the contents of an accumulator or action a t a specified address could he traced during a simulation. For the novice assemhly programmer, this proved to he a n invaluable aid in debugging programs as well as in simply observing what was happening a t the machine level. Without the availability of a STOP command from the keyboard, there was the threat of a simulated program entering an "infinite loop" with the final result being either excess execution time or a forced discontinuation of the simulator by the user. To combat this occurrence, checks were placed within the simulator to catch blatantly obvious "loops" and return an error message. Although it was not oossihle to counter all runtime errors (it was not necessariiy desirable to do so), some meaningful fail-safe character was found to be helpful. Results and Discussion The laboratory assignments were designed to provide the non-user student with that information and experience necessary to operate a lahoratory-based digital computer as a chemical tool. To this end, laboratory exercises involved experiments with digital logic per s6 as well as machine oriented encounters. The fort of the simulator was realized in this latter type of assignment. For use in this course, students were introduced to the simulator and to the machine a t the same time. Use of the NOVA and of the simulator by specified students durine suoemised laboratory ~ e r i o d swas on a rotating basis. ~xerc
