QUAESTIONES

INFORMATICAE

Vol. 1 No. 2 September, 1979

Quaestiones lnformaticae An official publication of the Computer Society of South Africa

'n Amptelike tydskrif van die Rekenaarvereniging van Suid-Afrika

Editors: Dr. D. S. Henderson, Vice Chancellor, Rhodes University, Grahamstown, 6140, South Africa. Prof. M. H. Williams, Department of Computer Science and Applied Maths, Rhodes University, Grahamstown, 6140, South Africa.

Editorial Advisory Board PROFESSOR D. W. BARRON Department of Mathematics The University Southampton S09 5NH England

PROFESSOR K. GREGGOR Computer Centre University of Port Elizabeth Port Elizabeth 6001 South Africa

PROFESSOR K. MACGREGOR Department of Computer Science University of Cape Town Private Bag Rondebosch 7700 South Africa

PROFESSOR G. R JOUBERT Department of Computer Science University of Natal King George V A venue Durban 4001 South Africa

Subscriptions Annual subscriptions are as follows:

Individuals Institutions

SA R2 R4

us $3 $6

MR. P. P. ROETS NRIMS CSIR P.O. Box 395 PRETORIA 0001 South Africa

PROFESSOR S.H. VON SOLMS Department of Computer Science Rand Afrikaans University Auckland Park Johannesburg 2001 South Africa

PROFESSOR G. WIECHERS Department of Computer Science University of South Africa P.O. Box 392 Pretoria 0001 South Africa

MR P. C. PIROW Graduate School of Business Administration, University of the Witwatersrand P.O. Box 31170 Braamfontein 201 7 South Africa

llK £1.50 £3.00

Quaestlones lnformatlcae Is prepared for publication by SYSTEMS PUBLISHERS (PTY) LTD·

for the Computer Society of South Africa.

The Impact of Microc_omputers in Computer Science Kenneth J. Danhof and Carol L. Smith

Department of Computer Science, Southern llhn01s Umvers1ty,

Carbondale, llhn01s 62901 USA

Abstract Tlns paper considers the emergmg role of the microcomputer laboratory ma computer science department The components for a particular laboratory are suggested These mclude the microcomputers themselves, supportmg penpheral hardware and the development system with its support.mg software packages It is suggested that such a microcomputer laboratory will come to play as important a role m computer science departments as the mim-computer laboratory now plays An mtroductory computmg systems course which has been developed m conJunctlon with such a microcomputer laboratory is descnbed m some detail The course is based on the premise that smce microcomputers are qmte mexpensive, they can be made rather freely available to students \Starting with a naked piece of hardware, the students develop therr own computmg systems (mcludmg loaders, text editors and assemblers) m a hands-on envrronment The microcomputers are both a pedagogical tool and an obJect of study Other computer science courses which might also use such a laboratory are suggested F mally such a laboratory can rather naturally support research m a computer science department As an example of this, a particular multi­microprocessor configuration currently bemg studied is descnbed Some results arid future directions of this research are noted

1. Introduction This paper discusses vanous possibilities regardmg the utilizat10n of microprocessors as teachmg and research aids m computer science Some general remarks are made m this openmg section, later sections descnbe specmc applications and activities relatmg to the role of a microcomputer laboratory m a computer science department Microprocessors and microcomputer systems are bnngmg about a rather pervasive revolution withm the general field of computers and computer applications Surpnsmgly, this revolution has impacted rather mmimally on computer science departments and therr teachmg and research act1V1ties We believe that this is now begmnmg to change and that a microcomputer laboratory will eventually be a vital component m most computer science departments Such a laboratory will play as important a role as the typical mmicomputer laboratory now plays Moreover, such a microcomputer laboratory will be affordable m many cases where a mmicomputer laboratory is not A microcomputer laboratory pro

1vides a means of bnngmg the latest technological

developments mto a department and tends to naturally mtroduce an understandmg of and an appreciation for computer

hardware where none may have previously existed Fmally such a laboratory can greatly m~ease hands-on access by students and faculty simply because several or even many microcomputers can be made available at relatively low cost

2 Background Much of the discuss10n here stems from drrect expenences m the development of a microcomputer laboratory m the Computer Science Department at Southern Illmois Umversity This laboratory was mitiated by a grant from the National Science Foundat10n m 1977 (Grant No SER77-02523) The grant was m response to a proposal seekmg aid m the development of an mtroductory computmg systems course which would be taught with heavy support from a microprocessor laboratory The proposed course was descnbed m some detail m Danhof and Smith r21 It was felt that m such a course students would be able

to develop therr own small computmg systems m an unlimited hands-on envrronment usmg the latest technology The grant provided funds for both the acqmsition of the necessary eqmpment and for the development of the course

3 The Laboratory The particular laboratory at Southern Illm01s Umvers1ty 1s centered around 30 microcomputers Half of these are Motorola M6800's and the remamder are Intel 8085 s (These are probably the two most widely used 8 bit microprocessors available today) These computers are qmte basic machmes consistmg of chips mounted on open boards Each has 1/4K to 1/2K of RAM memory Simple momtor programs ( operatmg systems) provide a basic programmmg capability at the machme language level (I/0 is made m terms of hexadecimal digits)

\Ten of these microcomputers are set up as permanent base stat10ns m the laboratory, the remammg computers are available for check out by students Among the ten permanent microcomputers are two ( one M6800 and one 8085) which each have 16K of memory and are mterfaced with CRTs and the umversity s mam computer These two can be used for runnmg large programs and for systems software development work A number of software development support packages are mamtamed on the umversity's mam computer These mclude cross assemblers, compilers and simulators and can be used to develop resident system software for the microprocessors Object code can be transmitted drrectly from the umversity s mam computer to the CRTs and thereby to the microcomputers themselves Fmally, floppy disl( and cassette storage capability exists for tne microcomputers The hardware costs for settmg up the laboratory descnbed above would be about $12,000 (Individual microcomputers with power supplies are figured at $300 each) There are additional personnel costs mvolved m settmg up the support system and m the mamtenance of the facility In the present case, the development of a retargetable PL/M compiler and two cross assemblers requrred the part-trme efforts of one faculty member and four graduate students over a penod of two years The extent of such

costs clearly depends on the degree to wlnch the software is developed locally Most of the requrred software can be obtamed drrectly from the manufacturers The actual costs for replacement and mamtenance of malfunct10nmg eqmpment will probably never exceed $1,000 per year These costs should be compared with a $30 000 -$50,000 m1tial outlay for a mm1computer laboratory and annual mamtenance costs of $5,000 to $10,000 thereafter A microcomputer laboratory of tlns configurat10n can rather easily support 60-80 students m the type of course descnbed m section 4 below With careful schedulmg, the laboratory could probably support 100 actively mvolved students and some concurrent research act1V1t1es as well We beheve that microcomputer laboratones wdl eventually become at least as unportant as mm1computer laboratones currently are for the support of teachmg and research m computer science departments The arguments advanced on behalf of the departmental mllllcomputer (1t provides a hands-on facility that can be modified by the students, 1t mtroduces the latest technology mto the department - see Lewis and Doerr [ 5]) apply equally well to the microcomputer Moreover the microcomputer laboratory will be affordable m many mstances where the mm1computer laboratory 1s not

4 The Course This section descnbes a Computmg Systems Fundamentals course which has been developed m conjunction with the microprocessor laboratory The course 1s reqmred of all undergraduate computer science majors and presupposes at least one prev10us high-level programmmg language course, a background course m assembly language programmmg 1s also desrrable The course can be taken concurrently with a data structures course and 1s prereqms1te to courses m computer architecture and systems programmmg The five levels found m computmg systems (as set forth m Tanenbaum [7]) provide the framework for the course

High Level Assembly Operatmg Machrne Mtcropro-Language Language

Level - Level Systems Language grammmg

Level - Level - Level (5) ( 4) (3) (2) (1)

Dunng the course students are exposed to each of these five levels and the vanous level traversals The course 1s designed so that students start with a stnpped down piece of hardware (the microcomputers at level 2) and proceed to personally develop a farrly sophisticated computmg system This 1s done m the context of four course modules as descnbed below \ In Module I, students are mtroduced to the machmes (M6800 and 8085) and therr mstruct10n sets Students famlhanze themselves with the mstruct10ns the addressmg modes, etc by executmg short programs on the microcomputers Vanous standard programmmg constructs (block moves, procedure calls, etc ) are unplemented m each of the two mstruction sets The last chapter of Module I discusses the architecture of each of the microprocessors This allows for a consideration of the m1cromstruct10n levels on the two machmes Fmally, I/0 1s considered from a hardware pomt of view !Jn particular, the I/0 mterface deVIces available m the Motorola and Intel systems are studied / At this pomt, students have begun to program at the assembly language level (level 4 ), but they must still hand load the resultmg cross-assembled object code for execut10n on the microcomputers This motivates Module II which mtroduces students to loaders

Smee many microcomputers provide a cassette tape mterface capability, cassette PUNCH and LOAD routmes are mvestigated as case studies Particular attent10n 1s paid to the actual I/0 process settmg up the senal mterface chip and subsequent software mteraction with tlns deVIce With this background, students are asked to develop therr own loader which can accept assembled object code from the supportmg development system Note that at this pomt further hand loadmg becomes unne~ssary Module II also studies a text editor as an add1t10nal example of a systems I/0 program Students are then asked to wnte a simple text editor ( consistmg of a basic mput mode with lun1ted ed1tmg capability) These text editors will later be used to mput assembly language programs to the microcomputers from a CRT In Module III students are mtroduced to level 5 through PL/M- a language developed by Intel to support software development The particular compiler used 1s PL/M STAR, a retargetable compller developed m conjunction with the microcomputer laboratory which can generate assembly level code for either the M6800 or the 8085 (see Marks, Tondo and Smith [6]) The basic project here 1s wntmg an assembler for one of the two machmes These are subset assemblers and students are given a general framework for the design of therr particular assembler Tlns mcludes an mdication of the vanous structures and procedures needed m each of the two passes of the assemblers It should be noted that upon completion of tlns assembler project, the assembler can be complled, assembled and loaded mto a microcomputer as a resident assembler The students will have constructed therr own small computmg systems m that they can enter assembly language programs from a tefffilllal ( usmg therr text editors) and then have these programs assembled and executed by the microcomputer The microcomputer system 1s now a stand alone system, freed from the larger development system The final component of the course, Module IV, begms with a discussion of mterrupts and mterrupt I/0 After a look at the mterrupt capab1hties of each of the two computers, an mterrupt dnven application 1s studied as a specruc example The application selected 1s one requrrmg parallel I/0, so that parallel mterface devices are also considered at this pomt Although the course covers a considerable amount of matenal, we have found 1t possible to get through the bulk of this matenal ma 15 week semester ( with three meetmgs per week) We have found that students tend to be more stunulated and productive when creatmg software for therr own real machme as opposed to a simulated machme Student feedback has been very positive

5 Other Courses Although we have thus far utilized the microprocessor laboratory only m conjunct10n with the course descnbed m section 4 above, 1t 1s clear that tlns laboratory can and will play a complementary role m support of several other courses m the computer science cum cul um As the use of microprocessors becomes more pervasive and therr cost contmues to decrease, programmed logic will tend to supplant traditional combmational and sequential cITcmts Consequently microprocessors wdl come to play an mcreasmgly unportant ( and perhaps dommatmg) role m courses on logical design Microcomputer systems are becommg sufficiently widespread that we see them becommg objects of study m therr own nght and new courses dealing solely with such systems are developmg In addition the study of microcomputer system configurations 1s becommg a natural component m computer architecture courses Fmally, as the cost of microcomputer systems contmues to

39

Common Memory (Globals)

Arbitrator <:::;;>r;o Processor

Local Memory

Figure 1

Local Memory

decrease, we rrught expect to see an mcrease m therr use m computer scrence for teachmg support Movmg beyond the kmd of course descnbed m sect10n 4 above, we might, for example see students developmg their own small op~ratmg systems for rrucroprocessor based systems m an operatmg systems course

6 A Multiprocessor Configuration The laboratory descnbed m section 3 provides a natural envrronment for the study of multiprocessmg systems This fmal section reports bnefly on the development of one such system It should be noted that several groups are currently studymg multiprocessor configurat10ns (see e g [1], [3], [ 4]) Included among these are hierarchical (tree-like) conftgurat10ns, peer-structure arrangements and rmgs of rrucroprocessors To a large extent, an optimal configurat10n might be determmed by the structure of the algonthms to be executed Ideally we rrught want a flexible configurat10n with allocation of procedure-to-processor problems handled by the operatmg system We are mvestlgatmg a system with basic structure as md1cated m Figure 1

40

In this system µP1 µ,PN represent the workmg processors Each_ can mdependently execute procedures lntercommumcatlon between processors, 1/0 and access to global vanables 1s handledthrough common memory by way of the Arbitrator The Arbitrator handles all requests for access to common memory breaks ties m case two such requests occur simultaneously and ensures that no one processor 1s locked out of common memory over a penod of time Blocks of data can be passed between common memory and a particular local memory via the Arbitrator Parallel mterface deVIces are used _m a handshakmg mode to effect such transferals Tn-state bus transceivers are used to guarantee that only one µ,P, has access to the common data bus atany time At present four workmg processors are bemg used to test the configuration on vanous algonthms The data currently bemg generated md1cates that the multiprocessor 1s qmte efficrent as long as the rate at which common memory 1s accessed IS not excessively high In any event, the system 1s very cost efficient We are currently plannmg to mcorporate a Drrect Memory Access (DMA) techmque m the system to Improve the rate of data transfer between common and local memones Further work wtll begm the design of an operatmg system and seek to determme the maximum ( optimal) number of processors per arbitrator

References [1] CHRISTOPHER, T et al (1978) Umprogrammmg a

Network Computer, Eighth Intematwnal Conference on Parallel Processing, Traverse City, Michigan, August 1978

[2] DANHOF, K J and SMITH, CL (1977) The Pedagogical Impact of Microprocessor Based Computmg Systems, Proc Computer Science and Engineering Conference, Wtlhamsburg Va, June 1977

[3] FULLER, SH et al (1978) Mult1m1croprocessors An Overview and a WorkmgExample,Proc ofthe!EEE 66,2

[ 4] HARRIS J A and SMITH, D (1977) Hierarchical Multiprocessor Organ12ations, Proc of the Fourth Annual Symposium on Computer Architecture, 41-48

[5] LEWIS, T G and DOERR, J W (1976) Mmicomputers Structure and Programming, Hayden Book Company, Inc , Rochelle Park N J

•[6] MARKS, J, TONDO, CL and SMITH, CL (1979) PL/M STAR Users Manual Release 2 Computer Science Department, Southern Illmms Umvers1ty at Carbondale, Carbondale Ilhnms

[7] TANENBAUM, AS (1976) Structured Computer Orgamzatwn Prentice-Hall, Englewood Chffs, New Jersey

Notes for Contributors

The purpose of this Journal will be to publish original papers in any field of computing. Papers submitted may be research articles, review articles, exploratory articles or articles of general interest to readers of the Joumal. The preferred languages of the Journal will be the congress languages of IFIP although papers in other languages will not be pecluded.

Manuscripts should be in double-spaced typing on one side only of A 4 paper and submitted to Dr. D. S. Henderson or Prof. M . H. Williams at

Rhodes University Grahamstown 6140 South Africa

Form or manuscript Manuscripts should be in double-space typing on one side only of

sheets of A4 size with wide margins. The original ribbon copy of the typed manuscript should be submitted. Authors should write concisely.

The first page should include the article title ( which should be brief), the author's name, and the affiliation and address. Each paper must be accompanied by a summary of less than 200 words which will be printed immediately below the title at the beginning of the paper, together with an appropriate key word list and a list of relevant Computing Review categories.

Tables and figures Illustrations and tables should not be included in the text, although the

author should indicate the desired location of each in the printed text Tables should be typed on separate sheets and should be numbered consecutively and titled.

Illustrations should also be supplied on separate sheets, and each should be clearly identified on the back in pencil with the Author"s name and figure number. Original line drawings (not photoprints) should be submitted and should include all relevant details. Drawings, etc .• should be about twice the final size required and lettering must be clear and .. open .. and sufficiently large to permit the necessary reduction of size in block-making.

Where photographs are submitted. glossy bromide prints are required. If words or numbers are to appear on a photograph, two prints should be sent. the lettering being clearly indicated on one print only. Computer programs or output should be given on clear original printouts and preferably not on lined paper so that they can be reproduced photographi­cally.

Figure legends should be typed on a separate sheet and placed at the end of the manuscript

Symbols Mathematical and other symbols may be either handwritten or

typewritten. Greek letters and unusual symbols should be identified in the margin. Distinction should be made between capital and lower case letters between the letter O and zero; between the letter l the number one and prime; between K and kappa. '

References References should be listed at the end of the manuscript in alphabeti­

cal order of author's name, and cited in the text by number in square brackets. Journal references should be arranged thus:

l . ASHCROFT, E. and MANNA, Z. ( 1972). The Translation of 'GOTO' Programsto'WHILE' Programs,inProceedingsoflFIP C<?_ngress 71, North-Holland, Amsterdam, 250-255.

2. BO~, C. and JACO PINI, G. ( 1966). Flow Diagrams, Turing Machines and Languages with only Two Formation Rules Comm. ACM, 9, 366-371. '

3. GINSBURG, S. (1966). Mathematical Theory of Context-free Languages, McGraw Hill. New York.

Proofs and reprints Galley proofs will be sent to the author to ensure that the papers have

been correctly set up in type and not for the addition of new material or amendment of texts. Excessive alterations may have to be disallowed or the cost charged against the author. Corrected galley proofs together with th~ ?ri~nal ~script, must be returned to the editor with~ three days to rrunuruze the nsk of the author's contribution having to be held over to a later issue.

~ifty reprints of each article will be supplied free of charge. Additional copies may be purchased on a reprint order form which will accompany the proofs.

Only original papers will be accepted, and copyright in published papers will be vested in the publisher.

Letters A section of" Letters to the Editor" ( each limited to about 500 words)

will provide a forum for discussion of recent problems.

Hierdie notas is ook in Afrikaans verkrygbaar.

Questiones I nformaticae Partial proceedings of the first South African Computer Symposium on Research in Theory, Software, Hardware, organised by The Research Symposium Organising Committee of The Computer Society of South Africa. 4 & 5 September 1979, Pretoria.

Contents/lnhoud

Toepaslikheid van 'n analitiese model by die keuse van 'n leerstruktuur vir 'n teksverwerkingstelsel ..... 1 A. Penzhordn

Direct FORTRAN/IDMS interface (without the use of a DML) on the ICL 1904/2970 computers, using a geological data base as example .................................. . .. . ....... · .................. .

B.Day

Rekenaarondersteunde onderhoud van programmatuurstelsels ..................................... 12 E. C. Anderssen

Database design: choice of a methodology ..................................................... 16 M. C. F. King, G. Naude, S. H. von Solms

Design principles of the language BPL ................... : .. . . · ................................ 23 M. H. Williams

A high-level programming language for interactive lisp-like languages ............................ N/ A s.w. Postma

The sequence abstraction in the implementation of EMILY ...................................... 26 D. C. Currin, J.M. Bishop, Y. L Varol

Block-structured interactive programming system ....... . ..................................... N/ A C. S. M. Mueller

The management of operating systems state data ................•.............................. 30 T. Turton

From slave to servant ....................................................................... N/ A G. C. Scarrott

Teacher control in computer-assisted instruction ...... ~ ......................................... 34 P.Calingaert ·

The impact of microcomputers in computer science ............................................. 38 K. J. Danhof, C. L. Smith

Architecture of current and future products ........................ : ......................... NI A C. F. Wolfe

An algorithm for merging disk files in place ........................... · .... ---=-:- ••••••••••••••••••• 41 P.P.Roets

An algorithm for the approximation of surfaces and for the packing of volumes ..•.........•........ 44 A.H. J. Christensen

'I'he memory organisation of large processors •................................................ N/ A D. M. Stein