- Email: [email protected]
A prototype microcomputer-based implementation of NATAL
0360-131 S/84$3.00+ 0.00 PergamonPressLtd
Compur. E&UC. Vol. 8, No. 4. pp. 361-370, 1984
Printedin GreatBritain
A PROTOTYPE MICROCOMPUTER-BASED IMPLEMENTATION OF NATAL C. S. PHAN’, A. M. HLADY~, J. W. BRAHAN’ ‘National
Research
Council,
Ottawa,
Ontario, London,
Canada Ontario,
and T. E. HEAVEN’
KIA OR8 and lGenera1 Canada
Computing
Systems,
INTRODUCTION NATAL is a high-level language designed as a vehicle for the creation and specification of course materials for computer-aided learning (CAL) applications[I]. A primary goal of the NATAL project at the National Research Council (NRC) has been to ensure the availability of a series of compatible implementations on a range of computer hardware. This series of compatible implementations of a “standard” author language is seen as a key prerequisite to achieving the economical creation and distribution of CAL courseware for education and training. Initial efforts in the NATAL project focused on relatively large computers, starting with the DEC system-lo. As a result of development work by NRC and Honeywell Information Systems-the latter through a technology transfer agreement with NRC-NATAL implementations now exist on three time-shared computers in the mainframe and large minicomputer class. Each of these implementations is a complete CAL system for course preparation and delivery along with associated support capabilities for course and student registration, performance reporting, etc. As a programming language, NATAL contains a rich complement of features. An implementation of the full NATAL specification[2] places considerable demands on the computer hardware in terms of memory capacity and capabilities for data manipulation, computation and file handling. Although microcomputers have been proliferating rapidly in applications related to education and training, it is only in the last few years that they have become sufficiently powerful to seriously consider their use with NATAL. A microcomputer-based system for CAL applications is commonly configured as a stand-alone, single-user unit as depicted in Fig. 1. Courseware authored and prepared on the same unit or another identical unit can be stored on floppy diskettes for subsequent use when required. Alternatively, if the system has a hard disk, a library of courseware can be stored on-line. An optional communication link can couple into a network of similar machines and also provide access to additional courseware from a central repository. An alternative configuration is shown in Fig. 2. In this configuration, authoring, testing and validation of courseware is done on a larger time-shared computer which generally has better support packages for these activities than do microcomputers. After a course has been prepared in this way, individual microcomputer delivery systems can deliver the course to students. Courseware distribution to the student stations can take place either electronically over a communication line, i.e. down-loaded, or physically by means of floppy diskettes.
_
MICROCOMPUTER
-
COURSE LIBRARY
oDoo**o DseDne ****o TERMINAL
-f-+--t COMMUNICATION LINK iOPTIONAL)
Fig.
-COURSE -COURSE -COURSE
I. Stand-alone 361
CAL
system.
AUTHORING TESTING DELIVERY
362
C. S.
PHANet al.
COURSE LlElRARY
(TIME-SHARED)
COW$lJ;~;TION (OPTIONAL)
-COURSE
AUTHORING
-COURSE
TESTING
-
COURSE
DELIVERY
AN0
VALIDATION
Fig. 2. Distributed CAL system.
The prototype microcomputer implementation of NATAL described in this paper provides only a course delivery capability. It is dependent on NATAL courseware generated on a larger NATAL system and therefore resembles the model illustrated in Fig. 2. However, with the rapid increases in microcomputer capabilities, it is becoming more practicable to implement NATAL on a micro as a full CAL system, including a course preparation ~pability, as shown in Fig. 1. This latter approach is discussed further in the last section of the paper. Regardless of how and where CAL courseware is created, the delivery of that courseware via a single-user stand-alone microcomputer-based configuration can offer advantages when compared to a configuration based on a cluster of terminals connected to a multi-user, time-shared computer. The most obvious for the small user is availability due to the much lower capital outlay to acquire a minimal installation. Although the cost per user may not be lower for applications requiring many student terminals, the ability to start small by buying only one or two microcomputer systems can be a definite advantage. A stand-alone delivery system also offers portability and flexibility in the sense that it is not constrained by the need to be near a communication line. A further, less tangible advantage is the public perception of microcomputers as “friendlier” than larger machines which in turn results in a more receptive user group. In keeping with the overall objectives for NATAL, a microcomputer-based implementation must be compatible with other implementations if easy courseware exchange is to be achieved. This effectively rules out sub-sets of the language. For this reason, the goal for a microcomputer implementation was the full NATAL specification excepting those features that apply only in a multi-user environment such as course variables and shareable files. The goal of supporting a full NATAL implementation on a computer with limited capabilities presents somewhat of a dilemma. A partial solution is possible by ensuring that the implementation is structured in a highly modular fashion. This permits the creation of custom configurations for those applications where it is known in advance that certain NATAL features will not be required. Although this approach is somewhat difficult to carry out in the general case, it is feasible to do this at least with some major modules such as the graphics routines, system functions and file handling. PROJECT
INITIATION
The microcomputer-based NATAL project began in 1979 with a small feasibility study contract awarded to General Computing Systems of London, Ontario as a result of a submission by that company to the federal government’s Unsolicited Proposal Program, This initial work was performed on a 8080 8-bit microcomputer system with 48K’memory and UCSD Pascal. The study showed that a successful implementation would require a l&bit computer with at least 64K bytes memory. In 1980, it was decided to proceed with a prototype implementation of a NATAL delivery system on a commercially available l6-bit microcomputer. At that time, most of the NRC laboratory 363
A prototype
microcomputer-based
implementation
of NATAL
363
resources devoted to computer-aided learning were focused on the transfer of NATAL technology to Honeywell. The microcomputer-based implementation was to be a relatively small scale effort ending up with a prototype delivery system. With regard to the choice of an implementation language, several possibilities were considered. Writing in assembly language was rejected outright. In order for NATAL to fulfill its stated purpose as a national authoring language, it had to be reasonably easy to port from one computer system to another as hardware technology progressed. Implementations in assembly language would hinder NATAL portability. Among the various higher-level languages available, the first alternative was BCPL-a systems development language which was used for the mainframe NATAL implementations. BCPL had already proven itself to be sufficiently flexible to implement the NATAL specifications and it was available on several computers. However, it was not available on popular microcomputers and we would have had to port BCPL to the target micro as a first step in the project. Although this was a possibility, the prospect of subsequently porting BCPL to other new microcomputers as the demand arose made this option less desirable. The language C, a newer cousin of BCPL, was already attracting considerable attention at that time, but it was not yet clear that it would become popular in the microcomputer environment. UCSD Pascal was finally chosen as the implementation language for the project. It was already available on a variety of microcomputers and gaining popularity on that class of machines. An attractive feature for us was its emphasis on portability with the P (pseudo)-machine concept. UCSD Pascal is compiled into P (pseudo)-code. Machine dependencies are generally isolated in the P-code interpreter that is required for each target machine. Although Pascal had been criticized for its many dialects and lack of a useable standard version, UCSD Pascal appeared to becoming a de facto standard within the microcomputer community. Pascal has some features that make it attractive for this application. It has very good control features and the record construct is well suited for the implementation of system structures such as activation records. The Pascal system has a stack-like heap on which occurrences of activation records can be added or removed dynamically. In order to acquire a suitable target machine for the project, a purchase requisition was issued for a 16-bit microcomputer system supporting UCSD Pascal. At that time, the Intel 8086, Motorola 68000 and Zilog 28000 16-bit CPU chips were available and board-level microcomputers based on these chips were starting to appear. We expected that these would be the prime contenders. However, after the bids were evaluated, Qupro Data Systems Ltd of Kitchener, Ontario best met the specifications with their Q-Engine-a product based on the Western Digital Pascal Microengine*. The 16-bit Qupro Q-Engine differs from other microcomputers in that its instruction set corresponds to that of the UCSD P-machine-i.e. it is a hardware implementation of a P-code interpreter. Because of this, it is able to execute UCSD Pascal compiled into P-code significantly faster than other machines in its price range. The Q-Engine was acquired with 64K bytes of RAM and dual 8” diskette drives. Figure 3 contains a photograph of the Q-Engine connected to a Lektromedia multi-media student terminal. The Q-Engine memory was later upgraded to 128K bytes when it became evident that 64K was too limiting for most applications. Development work on the prototype delivery system continued until the end of 1982. The development involved both the NRC laboratories and General Computing Systems under contract to NRC. IMPLEMENTATION The current NATAL mainframe implementations are based on a two-step compiler structure. In general, in a two-step structure, the compiler is divided into two parts: a front-end processor and a back-end processor as illustrated in Fig. 4. The front-end processor translates the high level language source program to an intermediate language program of an abstract machine. The
*Trademark
of Western
Digital
Corp.
c. s. hIAN
364
Fig. 3. Delivery
intermediate modes:
language
program
Interpretation. Native code generation, Microcoding.
is then processed
generating
target
et (II.
system
hardware.
by either
machine
one of the following
three common
code.
One of the major advantages of such a division is in the area of portable design. In the interest of portability, the abstract machine is designed to be machine independent so that the major machine dependent part of the compiler can be included in the back-end processor. With this approach, in order to port the compiler to a new machine, only the back-end processor would require major modifications, whereas the front-end could be ported with minimal effort. Among the three common modes of the back-end processor, the interpretive approach was chosen for our NATAL implementations. This is primarily due to the dynamic nature of NATAL variables and the display sublanguage. An outline of the NATAL compiler structure is shown in Fig. 5. The CHECK processor is responsible for translating NATAL source to an Intermediate Language Code (ILC) program. Since NATAL supports separate compilation, a linker (the PREPARE processor) is necessary to link the separately compiled ILC modules into an executable course file (CRS file). The CRS file is then loaded and interpreted by a NATAL INTERPRETER. The prototype is a NATAL interpreter implemented on a microcomputer. Since the CRS files on mainframe versions of NATAL are in binary format which inherently carry many system dependencies such as word-length, data structure, disk structure, and the implementation language used for the interpreter, they cannot be used directly for interpretation on a microcomputer. A
Fig. 4. A two-step
compiler
structure.
A prototype microcomputer-based
implementation
of NATAL
365
Fig. 5. NATAL compiler structure.
program was devised to convert the mainframe CRS files to a form more suitable to the target microcomputer hardware configuration and programming system. The output of the conversion program is in ASCII format. These ASCII files are transferred to the target microcomputer through an asynchronous communication line and rebuilt back to binary format by a receiving program at the microcomputer site. The various stages of course preparation and delivery are summarized in Fig. 6. In the following, we shall present a brief description of the various modules of the prototype implementation, and discuss the compatibility and differences from the NATAL DEC system-10 implementation, the implementation problems encountered and possible solutions, and finally the results of the implementation. conversion
Description of the prototype implementation The prototype consists of seven major modules: main, globals, stack, ioproc, vaproc, file and sysfun. Some of these modules are also divided further into submodules. The primary objective of such a design is to provide ease in system reconfiguration. For example, to adapt the system to support a new terminal, only the low level I/O submodule requires major modification; in addition, if the terminal does not have graphic capability, the whole submodule of system graphic functions is removed from the system. A brief description of each module is presented below: Main module. This is the main program module which contains the central interpreter routine. The program first prompts the user for a course name. It then loads the entry pms group (preprocessed module segment group) in core and calls the central interpreter procedure. A pms is the ILC produced by the NATAL CHECK processor for a single NATAL source routine. All the pms’s necessary to form a course are packed together into groups called pms groups by the NATAL PREPARE processor. The entry pms group is the pms group that contains the entry procedure which is the starting procedure of a NATAL program. The system normally maintains one pms group (or a few more depending on the availability of physical memory) in core. If a subsequently called pms is not in one of the pms groups currently residing in core, the system will bring in the corresponding pms group from disk. This mechanism is similar to a virtual memory system. It allows the system to support very large NATAL courses. The central interpreter procedure is only a simple looping routine. Its primary function is to obtain the next opcode and select the appropriate module interface routine to be called. Globals module. This is the module that contains the interface routines which are required by more than one other module. Of particular importance are the BRINGPMS, DECODE and ASSIGN routines. BRINGPMS loads a pms group into memory. DECODE retrieves the value of a NATAL variable. ASSIGN sets a value to a NATAL variable. Stack module. This module contains most routines required to process opcodes relating to routine and condition block invocations and terminations. Zoproc module. This module is responsible for those opcodes that interact with the terminal. It is subdivided into two submodules; one consisting of low level input/output routines and the other routines dealing with the processing of display sublanguage commands and the opcode response. Most of the terminal dependent input/output routines are isolated in the low level I/O submodule so that when the system is adapted to support a new terminal, only this submodule will be affected significantly. Vaproc module. This is the module that is responsible for operations that involve NATAL variables, such as arithmetic and relational operations, conditional and unconditional branches, and do blocks. c At R,4D
COURSE
PREPERATION
FOR
TO
FILES
-
preparation
MICROCOMPUTER’
COURSE
COMPUTER
stages of course
DOWNLOADING
OF
COMPUTER
DEUVERY
POSTPROCESSING
MAINFRAME
COURSE
Fig. 6. Various
ON
MAINFRAME
LINE
COMMUNICATION
and delivery.
I
I
I
SYSTEM
LINKAGE NATAL
DELIVERY WITHOUT
COURSES
MAINFRAME
MICRONATAL
DISKETTES
BY TO
ON
NATAL
COURSE
MICRO CWPUT COURSE FILE BUILDER
1 -MICROCOMPUTER
A prototype microcomputer-based
implementation
of NATAL
367
File module. This module contains all the routines necessary to support NATAL files. $~-fun module. This module contains most of the NATAL system functions. It is divided into
two sub-modules; one dealing with general system functions and the other with graphics functions. For terminals without graphic capabilities, the graphic submodule is empty. Compatibility and d@erences from DEC system-10 implementation
The original goal was to maintain source level compatibility between the prototype and the DEC system-10 implementations, i.e. a NATAL program that runs on the DEC system-10 installation will be able to run on the microcomputer without any modification to the NATAL source program. However, due to limited resources of a microcomputer system, the goal has been achieved reasonably well but not completely. The major differences between the two implementations are listed below: Mixed mode arithmetic and relational operations: only limited conversions are provided. Condition blocks: operations or procedure calls with actual parameters involving variables of types numeric, string, numeric vector and bit vector are not allowed. File system: record key values are restricted to 32766, and record length is also shorter on the prototype. NATAL files of the underlying Pascal operating system. They are stored collectively in two Pascal files, one for directory information and the other for data. As a consequence, the system file handling utilities such as file copying and directory viewing cannot be used on individual NATAL files. A special utility program has therefore been created for these purposes. The program allows one to list the NATAL file directory on the system, to read the content of a NATAL file, to transfer, to rename, and to delete a NATAL file. In addition, the program also includes the function of translating a NATAL file into an ASCII file and vice versa. System functions: the system functions CA, EVAL, INTERVAL, LMATCH, PMATCH, SYMB and CHAR have not been implemented. Support features: checkpoint/restart has not been included, and record and proctor were implemented in a different format. Features related to multi-user environment: as mentioned earlier, the prototype is intended for a single-user delivery station, so these features were not considered in the implementation. Implementation problems
In order not to “re-invent the wheel”, efforts have been made to follow the design of the NATAL DEC system-10 implementation as much as possible. However, due to the differences between the two computers and implementation languages used, many problems have been encountered during the implementation. At the earlier stage of the development, many of the problems were primarily due to the limited 64K bytes of memory. These problems were subsequently resolved with the upgrading of memory to 128K bytes. The few outstanding problems were mainly attributed to the slow disk accessing of the microcomputer system. The operations that have a major effect on system performance are garbage collection, pms group swapping, and NATAL file accessing. Garbage collection. In the DEC system-10 implementation, the collection process amounts to creating a disk file containing a new reordered NATAL stack with all the garbage removed. This file is then read back in the top of the existing stack. In the prototype implementation, since disk accessing is relatively slow, an alternative IN MEMORY collection scheme has been used. In the current running prototype version, collection is performed only on the top activation record of the stack. However, with some elaborate effort, the concept could be extended to cover the whole NATAL stack. This IN MEMORY collection scheme works well when the collection is due to a “memory low” situation. Nevertheless, the collection task becomes formidable when the call is to reorganize a split stack caused during the execution of a condition block. This is the reason why the current prototype cannot support the full capability of the NATAL ON CONDITION feature. The garbage collection problem is closely related to the storage management scheme used for the run-time system. To alleviate the problem, one alternative solution is to use a different memory management scheme. Due to the dynamic nature of NATAL variables, an appropriate combination of a stack-based technique with a heap-based technique could well ease the problem rather than a strictly stack-based technique as used in the current implementation[3].
368
c. s. &MN et ui.
Pms group swapping. Pms group swapping is a consequence of the segmentation scheme devised to support large NATAL courses. The swapping is hardly noticeable on the DEC system-10 computer; however it has a significant effect on the microcomputer. The problem could be eased with more memory to support several pms groups in core. Another possible solution is the addjtion of an optional function to the NATAL PREPARE processor to allow the course author to group pms’s instead of leaving the grouping to be performed automatically by the processor. With this option, a course file could be built by the author in an optimum structure that minimizes the occurrences of pms group swapping. iVATAL.file accessing. This is an operation that depends on the disk access capabilities provided by the underlying operating system. Similar to pms group swapping, the system performance couid be enhanced with more memory to support buffering. Results
The current prototype provides support for three types of terminals, namely, the Lektromedia LEK 304 multi-media terminal, the Telidon colour graphics terminal and the VT100 terminal (partial support). The size of the system, in terms of lines of source programs, breaks down as follows: Main module: 4X0 lines Globals module: 1320 lines Stack module: 720 lines Ioproc module: 3.50 lines for the low level submodule, and 1580 lines for the other Vaproc module: 1130 lines File module: 1170 lines Sysfun module: 1270 tines for general system function submodule, and 760 for the graphic function submodule. The run-time code size (supporting only one pms group in core) is about 73K bytes for the LEK 304 version and 8OK bytes for the Tehdon version. Tests run on the enhanced version (the 128K bytes version) have shown performance comparable to the DEC system- 10 implementatjon except for courses requiring extensive file I/Q or numerical computation. In order to enhance the run-time performance, more efficient opcodes have been introduced to the IL instruction set for the prototype implementation. These include 3-address opcodes for arithmetic and relational operations, branch on true, compare and branch and a new opcode format that includes an additional operand for destination. A local peephole optimizer has been introduced in the postprocessing phase. Data collected indicated that the size of the ILC code area is reduced by an average of 1376after the optimization. As to execution time, it is difficult to obtain data for programs running in interactive mode. However, a simple test program without user interaction indicated an improvement of 25y0 on execution time.
TRIAL
APPLICATIONS
Although the prototype delivery system just described is not a final version in polished form that could be released for general use, it has found use in a few trial applications that tested its capabilities under actual field conditions. Early interest in the system came from the Solar Energy Program within NRC. At the time, they were using a NATAL program entitled CAISSE {Computer-Aided Information System on Solar Energy) to inform the public about the potential benefits of solar energy through multi-media interaction on a Lektromedia LEK 304 terminal. Because this formed part of a travelling exhibit, portability was an important feature. Despite the limitations imposed by the 64K memory of the Qupro machine, a version of the delivery system was configured to support those NATAL features required for CAISSE. Although the technical
A prototype
microcomputer-based
implementation
369
of NATAL
content of CAISSE became outdated for its original purpose. it continued to serve as an in-house demonstration facility. A second application of the system was by the Children’s Hospital of Eastern Ontario Department of Language/Speech Pathology in conjunction with Pressman Associates. They had adapted a series of tests entitled the Auditory Skills Battery to NATAL for the automated assessment of auditory discrimination skills in children[4]. The tests used a Lektromedia 421 Portable Learning Assessment Terminal, functionally equivalent to the LEK 304. As in the previous application, the NATAL program made use of slide and audio presentation with touch-screen input. Another application currently underway by Pressman Associates involves an automated psychological test for the measurement of stress and Type A behaviour and its link to heart disease[5]. This application required a configuration of the delivery system supporting only alphanumeric I/O on a DEC VT-100 terminal. In each of the cases listed above, the NATAL program was initially authored and tested on the DEC system- 10 NATAL installation and subsequently transferred to the Qupro machine. Because of the prototype status of the Qupro version, each transfer invariably uncovered software bugs in the implementation that had to be corrected before the NATAL program would execute correctly on the Qupro system. Because each of these applications involved using the microcomputer exclusively for delivering a particular program or set of related programs, it was feasible to “customize” the configuration for that purpose. Although this customization approach is not suitable in a general CAL environment where a variety of courses using NATAL in different ways are encountered, it does offer benefits in terms of improved performance and reduced memory requirements for the class of applications amenable to this approach. For this reason, it is important that a microcomputer implementation of NATAL be highly modular to facilitate reconfiguration for special applications. FUTURE
DIRECTIONS
During the course of the prototype development, there has been considerable outside interest in a microcomputer-based implementation of NATAL, generally referred to as micro-NATAL. This interest has been expressed both by industry as potential suppliers of micro-NATAL products and by organizations in the private, public and academic sectors as potential users in various applications related to education and training. A general specification for microcomputer-based implementations of a NATAL system providing facilities for both course preparation and course delivery is a current goal of the Information Science Section at NRC. The experience gained in developing the prototype on the Qupro machine and recent progress in microcomputer technology have helped in deciding on a suitable course of action in order to achieve this goal. Work has begun this year in the NRC laboratories on an implementation in the C language. It is intended that this will form the basis for collaboration with industry on the creation of a wide range of application-oriented products for commercial distribution. Figure 7 summarizes the anticipated overall progression of micro-NATAL technology in going from the original NATAL specification through to microcomputer-based products.
CAL COMMUNITY
I I N STRUCTIONAL
MICRO -NATAL
I
TECHNOLOGY ___~___ MICRO
DEVELOPMENT
Fig. 7. Micro-NATAL
technology
flow.
-
NATAL
370
C. S. F%AN et al.
REFERENCES J. W., Henneker W. H. and Hlady A. M., NATAL-74 concept to reality. Proceedings-Third Canadian Symposium on Instructional Technology, 233-240 (1980). Honeywell Information Systems: NATAL-II national author language. Language Specification Manual. Order Number ZB07 (1981). Phan C. S., An efficient memory management scheme for micro-NATAL run-time system. National Research Council of Canada Report ERB-962 (1983). Pressman D. E.. Cunnineham S. J.. Pressman I. S.. Brahan J. W. and Henneker W. H.. Computer evaluation of language skills in childrei. National Research Council of Canada Report ERB-945 (1982). Pressman I. S. and Pressman D. E., Applications of CAL to patient testing and screening. Comput. Educ. 8, 435440 (1984).
1. Brahan 2. 3. 4. 5.
Compur. E&UC. Vol. 8, No. 4. pp. 361-370, 1984
Printedin GreatBritain
A PROTOTYPE MICROCOMPUTER-BASED IMPLEMENTATION OF NATAL C. S. PHAN’, A. M. HLADY~, J. W. BRAHAN’ ‘National
Research
Council,
Ottawa,
Ontario, London,
Canada Ontario,
and T. E. HEAVEN’
KIA OR8 and lGenera1 Canada
Computing
Systems,
INTRODUCTION NATAL is a high-level language designed as a vehicle for the creation and specification of course materials for computer-aided learning (CAL) applications[I]. A primary goal of the NATAL project at the National Research Council (NRC) has been to ensure the availability of a series of compatible implementations on a range of computer hardware. This series of compatible implementations of a “standard” author language is seen as a key prerequisite to achieving the economical creation and distribution of CAL courseware for education and training. Initial efforts in the NATAL project focused on relatively large computers, starting with the DEC system-lo. As a result of development work by NRC and Honeywell Information Systems-the latter through a technology transfer agreement with NRC-NATAL implementations now exist on three time-shared computers in the mainframe and large minicomputer class. Each of these implementations is a complete CAL system for course preparation and delivery along with associated support capabilities for course and student registration, performance reporting, etc. As a programming language, NATAL contains a rich complement of features. An implementation of the full NATAL specification[2] places considerable demands on the computer hardware in terms of memory capacity and capabilities for data manipulation, computation and file handling. Although microcomputers have been proliferating rapidly in applications related to education and training, it is only in the last few years that they have become sufficiently powerful to seriously consider their use with NATAL. A microcomputer-based system for CAL applications is commonly configured as a stand-alone, single-user unit as depicted in Fig. 1. Courseware authored and prepared on the same unit or another identical unit can be stored on floppy diskettes for subsequent use when required. Alternatively, if the system has a hard disk, a library of courseware can be stored on-line. An optional communication link can couple into a network of similar machines and also provide access to additional courseware from a central repository. An alternative configuration is shown in Fig. 2. In this configuration, authoring, testing and validation of courseware is done on a larger time-shared computer which generally has better support packages for these activities than do microcomputers. After a course has been prepared in this way, individual microcomputer delivery systems can deliver the course to students. Courseware distribution to the student stations can take place either electronically over a communication line, i.e. down-loaded, or physically by means of floppy diskettes.
_
MICROCOMPUTER
-
COURSE LIBRARY
oDoo**o DseDne ****o TERMINAL
-f-+--t COMMUNICATION LINK iOPTIONAL)
Fig.
-COURSE -COURSE -COURSE
I. Stand-alone 361
CAL
system.
AUTHORING TESTING DELIVERY
362
C. S.
PHANet al.
COURSE LlElRARY
(TIME-SHARED)
COW$lJ;~;TION (OPTIONAL)
-COURSE
AUTHORING
-COURSE
TESTING
-
COURSE
DELIVERY
AN0
VALIDATION
Fig. 2. Distributed CAL system.
The prototype microcomputer implementation of NATAL described in this paper provides only a course delivery capability. It is dependent on NATAL courseware generated on a larger NATAL system and therefore resembles the model illustrated in Fig. 2. However, with the rapid increases in microcomputer capabilities, it is becoming more practicable to implement NATAL on a micro as a full CAL system, including a course preparation ~pability, as shown in Fig. 1. This latter approach is discussed further in the last section of the paper. Regardless of how and where CAL courseware is created, the delivery of that courseware via a single-user stand-alone microcomputer-based configuration can offer advantages when compared to a configuration based on a cluster of terminals connected to a multi-user, time-shared computer. The most obvious for the small user is availability due to the much lower capital outlay to acquire a minimal installation. Although the cost per user may not be lower for applications requiring many student terminals, the ability to start small by buying only one or two microcomputer systems can be a definite advantage. A stand-alone delivery system also offers portability and flexibility in the sense that it is not constrained by the need to be near a communication line. A further, less tangible advantage is the public perception of microcomputers as “friendlier” than larger machines which in turn results in a more receptive user group. In keeping with the overall objectives for NATAL, a microcomputer-based implementation must be compatible with other implementations if easy courseware exchange is to be achieved. This effectively rules out sub-sets of the language. For this reason, the goal for a microcomputer implementation was the full NATAL specification excepting those features that apply only in a multi-user environment such as course variables and shareable files. The goal of supporting a full NATAL implementation on a computer with limited capabilities presents somewhat of a dilemma. A partial solution is possible by ensuring that the implementation is structured in a highly modular fashion. This permits the creation of custom configurations for those applications where it is known in advance that certain NATAL features will not be required. Although this approach is somewhat difficult to carry out in the general case, it is feasible to do this at least with some major modules such as the graphics routines, system functions and file handling. PROJECT
INITIATION
The microcomputer-based NATAL project began in 1979 with a small feasibility study contract awarded to General Computing Systems of London, Ontario as a result of a submission by that company to the federal government’s Unsolicited Proposal Program, This initial work was performed on a 8080 8-bit microcomputer system with 48K’memory and UCSD Pascal. The study showed that a successful implementation would require a l&bit computer with at least 64K bytes memory. In 1980, it was decided to proceed with a prototype implementation of a NATAL delivery system on a commercially available l6-bit microcomputer. At that time, most of the NRC laboratory 363
A prototype
microcomputer-based
implementation
of NATAL
363
resources devoted to computer-aided learning were focused on the transfer of NATAL technology to Honeywell. The microcomputer-based implementation was to be a relatively small scale effort ending up with a prototype delivery system. With regard to the choice of an implementation language, several possibilities were considered. Writing in assembly language was rejected outright. In order for NATAL to fulfill its stated purpose as a national authoring language, it had to be reasonably easy to port from one computer system to another as hardware technology progressed. Implementations in assembly language would hinder NATAL portability. Among the various higher-level languages available, the first alternative was BCPL-a systems development language which was used for the mainframe NATAL implementations. BCPL had already proven itself to be sufficiently flexible to implement the NATAL specifications and it was available on several computers. However, it was not available on popular microcomputers and we would have had to port BCPL to the target micro as a first step in the project. Although this was a possibility, the prospect of subsequently porting BCPL to other new microcomputers as the demand arose made this option less desirable. The language C, a newer cousin of BCPL, was already attracting considerable attention at that time, but it was not yet clear that it would become popular in the microcomputer environment. UCSD Pascal was finally chosen as the implementation language for the project. It was already available on a variety of microcomputers and gaining popularity on that class of machines. An attractive feature for us was its emphasis on portability with the P (pseudo)-machine concept. UCSD Pascal is compiled into P (pseudo)-code. Machine dependencies are generally isolated in the P-code interpreter that is required for each target machine. Although Pascal had been criticized for its many dialects and lack of a useable standard version, UCSD Pascal appeared to becoming a de facto standard within the microcomputer community. Pascal has some features that make it attractive for this application. It has very good control features and the record construct is well suited for the implementation of system structures such as activation records. The Pascal system has a stack-like heap on which occurrences of activation records can be added or removed dynamically. In order to acquire a suitable target machine for the project, a purchase requisition was issued for a 16-bit microcomputer system supporting UCSD Pascal. At that time, the Intel 8086, Motorola 68000 and Zilog 28000 16-bit CPU chips were available and board-level microcomputers based on these chips were starting to appear. We expected that these would be the prime contenders. However, after the bids were evaluated, Qupro Data Systems Ltd of Kitchener, Ontario best met the specifications with their Q-Engine-a product based on the Western Digital Pascal Microengine*. The 16-bit Qupro Q-Engine differs from other microcomputers in that its instruction set corresponds to that of the UCSD P-machine-i.e. it is a hardware implementation of a P-code interpreter. Because of this, it is able to execute UCSD Pascal compiled into P-code significantly faster than other machines in its price range. The Q-Engine was acquired with 64K bytes of RAM and dual 8” diskette drives. Figure 3 contains a photograph of the Q-Engine connected to a Lektromedia multi-media student terminal. The Q-Engine memory was later upgraded to 128K bytes when it became evident that 64K was too limiting for most applications. Development work on the prototype delivery system continued until the end of 1982. The development involved both the NRC laboratories and General Computing Systems under contract to NRC. IMPLEMENTATION The current NATAL mainframe implementations are based on a two-step compiler structure. In general, in a two-step structure, the compiler is divided into two parts: a front-end processor and a back-end processor as illustrated in Fig. 4. The front-end processor translates the high level language source program to an intermediate language program of an abstract machine. The
*Trademark
of Western
Digital
Corp.
c. s. hIAN
364
Fig. 3. Delivery
intermediate modes:
language
program
Interpretation. Native code generation, Microcoding.
is then processed
generating
target
et (II.
system
hardware.
by either
machine
one of the following
three common
code.
One of the major advantages of such a division is in the area of portable design. In the interest of portability, the abstract machine is designed to be machine independent so that the major machine dependent part of the compiler can be included in the back-end processor. With this approach, in order to port the compiler to a new machine, only the back-end processor would require major modifications, whereas the front-end could be ported with minimal effort. Among the three common modes of the back-end processor, the interpretive approach was chosen for our NATAL implementations. This is primarily due to the dynamic nature of NATAL variables and the display sublanguage. An outline of the NATAL compiler structure is shown in Fig. 5. The CHECK processor is responsible for translating NATAL source to an Intermediate Language Code (ILC) program. Since NATAL supports separate compilation, a linker (the PREPARE processor) is necessary to link the separately compiled ILC modules into an executable course file (CRS file). The CRS file is then loaded and interpreted by a NATAL INTERPRETER. The prototype is a NATAL interpreter implemented on a microcomputer. Since the CRS files on mainframe versions of NATAL are in binary format which inherently carry many system dependencies such as word-length, data structure, disk structure, and the implementation language used for the interpreter, they cannot be used directly for interpretation on a microcomputer. A
Fig. 4. A two-step
compiler
structure.
A prototype microcomputer-based
implementation
of NATAL
365
Fig. 5. NATAL compiler structure.
program was devised to convert the mainframe CRS files to a form more suitable to the target microcomputer hardware configuration and programming system. The output of the conversion program is in ASCII format. These ASCII files are transferred to the target microcomputer through an asynchronous communication line and rebuilt back to binary format by a receiving program at the microcomputer site. The various stages of course preparation and delivery are summarized in Fig. 6. In the following, we shall present a brief description of the various modules of the prototype implementation, and discuss the compatibility and differences from the NATAL DEC system-10 implementation, the implementation problems encountered and possible solutions, and finally the results of the implementation. conversion
Description of the prototype implementation The prototype consists of seven major modules: main, globals, stack, ioproc, vaproc, file and sysfun. Some of these modules are also divided further into submodules. The primary objective of such a design is to provide ease in system reconfiguration. For example, to adapt the system to support a new terminal, only the low level I/O submodule requires major modification; in addition, if the terminal does not have graphic capability, the whole submodule of system graphic functions is removed from the system. A brief description of each module is presented below: Main module. This is the main program module which contains the central interpreter routine. The program first prompts the user for a course name. It then loads the entry pms group (preprocessed module segment group) in core and calls the central interpreter procedure. A pms is the ILC produced by the NATAL CHECK processor for a single NATAL source routine. All the pms’s necessary to form a course are packed together into groups called pms groups by the NATAL PREPARE processor. The entry pms group is the pms group that contains the entry procedure which is the starting procedure of a NATAL program. The system normally maintains one pms group (or a few more depending on the availability of physical memory) in core. If a subsequently called pms is not in one of the pms groups currently residing in core, the system will bring in the corresponding pms group from disk. This mechanism is similar to a virtual memory system. It allows the system to support very large NATAL courses. The central interpreter procedure is only a simple looping routine. Its primary function is to obtain the next opcode and select the appropriate module interface routine to be called. Globals module. This is the module that contains the interface routines which are required by more than one other module. Of particular importance are the BRINGPMS, DECODE and ASSIGN routines. BRINGPMS loads a pms group into memory. DECODE retrieves the value of a NATAL variable. ASSIGN sets a value to a NATAL variable. Stack module. This module contains most routines required to process opcodes relating to routine and condition block invocations and terminations. Zoproc module. This module is responsible for those opcodes that interact with the terminal. It is subdivided into two submodules; one consisting of low level input/output routines and the other routines dealing with the processing of display sublanguage commands and the opcode response. Most of the terminal dependent input/output routines are isolated in the low level I/O submodule so that when the system is adapted to support a new terminal, only this submodule will be affected significantly. Vaproc module. This is the module that is responsible for operations that involve NATAL variables, such as arithmetic and relational operations, conditional and unconditional branches, and do blocks. c At R,4D
COURSE
PREPERATION
FOR
TO
FILES
-
preparation
MICROCOMPUTER’
COURSE
COMPUTER
stages of course
DOWNLOADING
OF
COMPUTER
DEUVERY
POSTPROCESSING
MAINFRAME
COURSE
Fig. 6. Various
ON
MAINFRAME
LINE
COMMUNICATION
and delivery.
I
I
I
SYSTEM
LINKAGE NATAL
DELIVERY WITHOUT
COURSES
MAINFRAME
MICRONATAL
DISKETTES
BY TO
ON
NATAL
COURSE
MICRO CWPUT COURSE FILE BUILDER
1 -MICROCOMPUTER
A prototype microcomputer-based
implementation
of NATAL
367
File module. This module contains all the routines necessary to support NATAL files. $~-fun module. This module contains most of the NATAL system functions. It is divided into
two sub-modules; one dealing with general system functions and the other with graphics functions. For terminals without graphic capabilities, the graphic submodule is empty. Compatibility and d@erences from DEC system-10 implementation
The original goal was to maintain source level compatibility between the prototype and the DEC system-10 implementations, i.e. a NATAL program that runs on the DEC system-10 installation will be able to run on the microcomputer without any modification to the NATAL source program. However, due to limited resources of a microcomputer system, the goal has been achieved reasonably well but not completely. The major differences between the two implementations are listed below: Mixed mode arithmetic and relational operations: only limited conversions are provided. Condition blocks: operations or procedure calls with actual parameters involving variables of types numeric, string, numeric vector and bit vector are not allowed. File system: record key values are restricted to 32766, and record length is also shorter on the prototype. NATAL files of the underlying Pascal operating system. They are stored collectively in two Pascal files, one for directory information and the other for data. As a consequence, the system file handling utilities such as file copying and directory viewing cannot be used on individual NATAL files. A special utility program has therefore been created for these purposes. The program allows one to list the NATAL file directory on the system, to read the content of a NATAL file, to transfer, to rename, and to delete a NATAL file. In addition, the program also includes the function of translating a NATAL file into an ASCII file and vice versa. System functions: the system functions CA, EVAL, INTERVAL, LMATCH, PMATCH, SYMB and CHAR have not been implemented. Support features: checkpoint/restart has not been included, and record and proctor were implemented in a different format. Features related to multi-user environment: as mentioned earlier, the prototype is intended for a single-user delivery station, so these features were not considered in the implementation. Implementation problems
In order not to “re-invent the wheel”, efforts have been made to follow the design of the NATAL DEC system-10 implementation as much as possible. However, due to the differences between the two computers and implementation languages used, many problems have been encountered during the implementation. At the earlier stage of the development, many of the problems were primarily due to the limited 64K bytes of memory. These problems were subsequently resolved with the upgrading of memory to 128K bytes. The few outstanding problems were mainly attributed to the slow disk accessing of the microcomputer system. The operations that have a major effect on system performance are garbage collection, pms group swapping, and NATAL file accessing. Garbage collection. In the DEC system-10 implementation, the collection process amounts to creating a disk file containing a new reordered NATAL stack with all the garbage removed. This file is then read back in the top of the existing stack. In the prototype implementation, since disk accessing is relatively slow, an alternative IN MEMORY collection scheme has been used. In the current running prototype version, collection is performed only on the top activation record of the stack. However, with some elaborate effort, the concept could be extended to cover the whole NATAL stack. This IN MEMORY collection scheme works well when the collection is due to a “memory low” situation. Nevertheless, the collection task becomes formidable when the call is to reorganize a split stack caused during the execution of a condition block. This is the reason why the current prototype cannot support the full capability of the NATAL ON CONDITION feature. The garbage collection problem is closely related to the storage management scheme used for the run-time system. To alleviate the problem, one alternative solution is to use a different memory management scheme. Due to the dynamic nature of NATAL variables, an appropriate combination of a stack-based technique with a heap-based technique could well ease the problem rather than a strictly stack-based technique as used in the current implementation[3].
368
c. s. &MN et ui.
Pms group swapping. Pms group swapping is a consequence of the segmentation scheme devised to support large NATAL courses. The swapping is hardly noticeable on the DEC system-10 computer; however it has a significant effect on the microcomputer. The problem could be eased with more memory to support several pms groups in core. Another possible solution is the addjtion of an optional function to the NATAL PREPARE processor to allow the course author to group pms’s instead of leaving the grouping to be performed automatically by the processor. With this option, a course file could be built by the author in an optimum structure that minimizes the occurrences of pms group swapping. iVATAL.file accessing. This is an operation that depends on the disk access capabilities provided by the underlying operating system. Similar to pms group swapping, the system performance couid be enhanced with more memory to support buffering. Results
The current prototype provides support for three types of terminals, namely, the Lektromedia LEK 304 multi-media terminal, the Telidon colour graphics terminal and the VT100 terminal (partial support). The size of the system, in terms of lines of source programs, breaks down as follows: Main module: 4X0 lines Globals module: 1320 lines Stack module: 720 lines Ioproc module: 3.50 lines for the low level submodule, and 1580 lines for the other Vaproc module: 1130 lines File module: 1170 lines Sysfun module: 1270 tines for general system function submodule, and 760 for the graphic function submodule. The run-time code size (supporting only one pms group in core) is about 73K bytes for the LEK 304 version and 8OK bytes for the Tehdon version. Tests run on the enhanced version (the 128K bytes version) have shown performance comparable to the DEC system- 10 implementatjon except for courses requiring extensive file I/Q or numerical computation. In order to enhance the run-time performance, more efficient opcodes have been introduced to the IL instruction set for the prototype implementation. These include 3-address opcodes for arithmetic and relational operations, branch on true, compare and branch and a new opcode format that includes an additional operand for destination. A local peephole optimizer has been introduced in the postprocessing phase. Data collected indicated that the size of the ILC code area is reduced by an average of 1376after the optimization. As to execution time, it is difficult to obtain data for programs running in interactive mode. However, a simple test program without user interaction indicated an improvement of 25y0 on execution time.
TRIAL
APPLICATIONS
Although the prototype delivery system just described is not a final version in polished form that could be released for general use, it has found use in a few trial applications that tested its capabilities under actual field conditions. Early interest in the system came from the Solar Energy Program within NRC. At the time, they were using a NATAL program entitled CAISSE {Computer-Aided Information System on Solar Energy) to inform the public about the potential benefits of solar energy through multi-media interaction on a Lektromedia LEK 304 terminal. Because this formed part of a travelling exhibit, portability was an important feature. Despite the limitations imposed by the 64K memory of the Qupro machine, a version of the delivery system was configured to support those NATAL features required for CAISSE. Although the technical
A prototype
microcomputer-based
implementation
369
of NATAL
content of CAISSE became outdated for its original purpose. it continued to serve as an in-house demonstration facility. A second application of the system was by the Children’s Hospital of Eastern Ontario Department of Language/Speech Pathology in conjunction with Pressman Associates. They had adapted a series of tests entitled the Auditory Skills Battery to NATAL for the automated assessment of auditory discrimination skills in children[4]. The tests used a Lektromedia 421 Portable Learning Assessment Terminal, functionally equivalent to the LEK 304. As in the previous application, the NATAL program made use of slide and audio presentation with touch-screen input. Another application currently underway by Pressman Associates involves an automated psychological test for the measurement of stress and Type A behaviour and its link to heart disease[5]. This application required a configuration of the delivery system supporting only alphanumeric I/O on a DEC VT-100 terminal. In each of the cases listed above, the NATAL program was initially authored and tested on the DEC system- 10 NATAL installation and subsequently transferred to the Qupro machine. Because of the prototype status of the Qupro version, each transfer invariably uncovered software bugs in the implementation that had to be corrected before the NATAL program would execute correctly on the Qupro system. Because each of these applications involved using the microcomputer exclusively for delivering a particular program or set of related programs, it was feasible to “customize” the configuration for that purpose. Although this customization approach is not suitable in a general CAL environment where a variety of courses using NATAL in different ways are encountered, it does offer benefits in terms of improved performance and reduced memory requirements for the class of applications amenable to this approach. For this reason, it is important that a microcomputer implementation of NATAL be highly modular to facilitate reconfiguration for special applications. FUTURE
DIRECTIONS
During the course of the prototype development, there has been considerable outside interest in a microcomputer-based implementation of NATAL, generally referred to as micro-NATAL. This interest has been expressed both by industry as potential suppliers of micro-NATAL products and by organizations in the private, public and academic sectors as potential users in various applications related to education and training. A general specification for microcomputer-based implementations of a NATAL system providing facilities for both course preparation and course delivery is a current goal of the Information Science Section at NRC. The experience gained in developing the prototype on the Qupro machine and recent progress in microcomputer technology have helped in deciding on a suitable course of action in order to achieve this goal. Work has begun this year in the NRC laboratories on an implementation in the C language. It is intended that this will form the basis for collaboration with industry on the creation of a wide range of application-oriented products for commercial distribution. Figure 7 summarizes the anticipated overall progression of micro-NATAL technology in going from the original NATAL specification through to microcomputer-based products.
CAL COMMUNITY
I I N STRUCTIONAL
MICRO -NATAL
I
TECHNOLOGY ___~___ MICRO
DEVELOPMENT
Fig. 7. Micro-NATAL
technology
flow.
-
NATAL
370
C. S. F%AN et al.
REFERENCES J. W., Henneker W. H. and Hlady A. M., NATAL-74 concept to reality. Proceedings-Third Canadian Symposium on Instructional Technology, 233-240 (1980). Honeywell Information Systems: NATAL-II national author language. Language Specification Manual. Order Number ZB07 (1981). Phan C. S., An efficient memory management scheme for micro-NATAL run-time system. National Research Council of Canada Report ERB-962 (1983). Pressman D. E.. Cunnineham S. J.. Pressman I. S.. Brahan J. W. and Henneker W. H.. Computer evaluation of language skills in childrei. National Research Council of Canada Report ERB-945 (1982). Pressman I. S. and Pressman D. E., Applications of CAL to patient testing and screening. Comput. Educ. 8, 435440 (1984).
1. Brahan 2. 3. 4. 5.