|
PROPOSAL FOR A COURSE IN ELEMENTARY COMPUTING.
The phenomenal rate of growth of electronic computing and its
applications, and of its involvement in everyone's daily life, has been
widely commented upon, documented, welcomed, and deprecated; it nevertheless
remains a fact. In its train comes a need for people with a sufficient
knowledge of the power and of the potential of computers to be able to use them -
and, if need be, to control them - with insight and wisdom. There is, in
particular, a requirement for people in each of three fairly well defined
categories :
- - computer specialists, who require detailed and extensive knowledge
to an advanced level in a wide variety of computing topics;
- - potential heavy users ( traditionally from the fields of science,
engineering, and commerce ), who maintain their own speciality
but require considerable expertise in some aspects of computing; and
- - others, who may not themselves be directly involved with computers
at all, but who could benefit from a good general knowledge of
computers if only as a guard against over-enthusiastic members
of the first two groups.
While this classification is certainly not exhaustive, it is not unrealistic
as a first approximation, and serves to draw attention to a need for
University courses appropriate to each of the three categories.
It seems likely that, at least for the time being, the requirements
of the first group are adequately catered for by the establishment of degree
courses in Computer Science at several other New Zealand Universities. In
this University, the second group are already served by courses administered
by their own faculties; in addition, the Computer Centre is developing
courses designed to be offered in conjunction with these to allow a student
to build up a degree heavily biased towards computing and its applications.
The proposal put forward in this paper is for a course directed towards the
third group, for whom there is at present no provision except for the
occasional series of lectures on elementary
programming; it should also serve as a valuable background for students
intending to continue to the more advanced computing courses, and - not least -
for the student who is simply curious about computers and wants to find out
more.
- 2 -
It would be premature at this juncture to attempt to lay down a
definitive syllabus for such a course - the proposals set out below are
rather intended to illustrate what could be done, and to provide a starting
point for discussion - but there are nevertheless a few points of a general
nature which should be taken into account when the syllabus is designed.
Perhaps the most obvious of these arises from the constitution of the
"third group" itself: about the most positive statement which can be made is
that the group is heterogeneous. The implications of this non-statement on
the problem of the syllabus are, on the one hand, that it must start from
scratch, and, on the other, that it will not be possible to assume any degree
of knowledge or experience in any field. It may indeed be desirable, to avert
the danger of discouraging a considerable proportion of potential candidates
for the course, to emphasise that neither a knowledge of, nor
marked ability in, mathematics will be required; evidently, formal mathematical
discussions of the course topics will not be possible.
This leads on to another important question. One of the functions of
the mathematical analyses which have just been vetoed is to provide insight
into the behaviour of the various entities to which they are applied: if the
mathematics must go, where will the insight come from? It is an essential
feature of this proposal that a more qualitative, but equally valid, insight
results from extensive practical experience, and that the course should
therefore have a very pronounced practical bias: in Science Faculty terms,
it should resemble Chemistry more closely than Mathematics.
A third point which can usefully be considered within the context so
far established is that of the aims of the course; in other words, what
direction should the course take in order best to suit the requirements of
the "third group"? This is clearly very much a matter for debate, but it is
at least arguable that the course would perform a valuable service if it
could succeed in removing the mystery from computing. To the large majority
of students, even ( or perhaps especially ) after learning to use a high-
level computer language, the inner workings of a computer, a compiler, or an
operating system still savour of the black arts; any course which aimed to
- 3 -
dispel the spurious mystique which surrounds such topics could be very
worthwhile
OUTLINE OF A POSSIBLE COURSE.
As an illustration of one possible syllabus for the sort of course
proposed above, I put forward the suggestions which follow. These are to
be taken as an expression of personal preference, and reflect my belief that
the best way to organise such a course is to concentrate on the development
of a central theme in an orderly manner, so that each topic is seen as a
reasonable development from topics previously discussed. The central theme
underlying the proposals below is the description of the mechanical - as
opposed to the human - activities in a conventional computer system; it is
also possible to discern a strong "second subject" in the progressive
development of the idea of a data structure. In accordance with my
interpretation of orderly development, the course starts with hardware and
proceeds through stages of increasing sophistication to operating systems.
This is by no means the only possible mode of organisation; for example,
a case can be made out for starting with a high-level language, and
then working "outwards" from that, but in my experience this approach can
create problems.
The emphasis throughout the lecture part of the course is on how
things work; in particular, it is not intended for
those who simply require to learn to use a programming language.
Any student taking the course must, of course, expect to become familiar
with a selection of programming languages, but any formal tuition needed
should be given in the practical part of the course. This would occupy about
half the total time of the course ( in parallel with the lecture series )
and could be organised as a programming workshop, in which the students
could work an set assignments or their own projects with a demonstrator
available for such help or advice as may be necessary.
- 4 -
A SYLLABUS.
The Components of a Computer System.
A brief outline of the topics treated in the course, showing how
they are related. This introduction should answer questions such as: what
is the distinction between hardware and software? what is a low-level
language? why does the data follow the programme in a load-and-go compilation?
what sort of thing does an operating system do?
Hardware.
NOT an advanced treatmant of machine design and Boolean Algebra: the
object is to show that a computer can be constructed from simple components.
Two-state devices. Representatations of many-state systems (letters of the
alphabet) by several two-state device; coding and decoding. Numbers -
integers only. Electrical representation of binary signals, realisation of
simple Boolean functions ( AND, OR, NOT - switches rather than transistors ).
Passive and active storage devices - cores and registers. Stepwise execution
of a simple machine instruction: addressing, operation codes, clock pulses,
machine registers. Implementation of simple arithmetic functions. Mention
of fabrication techniques and computer generations.
Programming workshop: using a very simple machine code as implemented
in ( for example ) the Olivetti Programma 101 machine. This is a one-
instruction, one-address code without indexing or indirection, but including
arithmetic operations and unconditional and conditional branches, and
gives a convincing illustration of the disciplines of machine-language
programming while eliminating many of the more tedious minutiae.
Low-level languages.
Machine language and assemblers. One-pass assemblers. Symbolic
addresses and two-pass assemblers. Maintenance and use of the name table:
arrays. Indexing and indirection. Linear search and hash table techniques
for the name table: linked structures.
Programming workshop: using a symbolic assembler; writing a symbolic
- 5 -
assembler. ( Input and output via subroutine calls; we haven't yet discussed
hardware interrupts. )
Macros and Subroutines.
Distinction between the two, and when to use which. Macro libraries;
macro expansion as string processing; strings. Subroutine linkage and
parameter passing; subroutine libraries; relocation. Recursive calls:
dyamic storage allocation, stacks. Pure procedures.
Programming workshop: ( Still with the symbolic assembler ) define
and use macros and subroutines. Some string processing examples. Implement
a recursive subroutine.
High-level languages.
Illustrations from a variety of high-level languages ( Fortran, Cobol,
Algol, PL/I, Snobol, Lisp etc, as available ) stressing the data structures
and programme atructures provided by each. Compilers, interpreters. Syntax:
methods of specification; importance; syntax recognisers: distinction from
semantics. Compiling techniques: simple arithmetic; Polish notations; more
complicated examples.
Programming workshop: have a go at as many languages as possible.
( This section of the course will certainly be the longest by a considerable
margin, so the preceding statement is not as absurd as it sounds. )
Operating systems.
The need for operating systems. Input-output systems: overlapping,
interrupts. Keeping the processor busy: dual programming, multiprogramming.
Use of backing store: paging, segmentation, virtual memory. Problems:
resource allocation, priorities, the deadly embrace. Security: disc and
tape file management techniques. ( This topic might be worth a section of
its own. ) Time sharing.
Programming workshop: Interrupts ( using the assembler ). Computer
system simulations, to experiment with variations in the job mix.
- 6 -
REQUIREMENTS OF THE COURSE.
It is evident that any student pursuing an intensive practical
course in computing on the lines described above ( but not necessarily
organised in the way suggested ) will require quite a lot of computer time
and supporting software. It would certainly be feasible in principle to
provide these services through the university's B6700 machine; much of the
requisite software already exists, including such items as assemblers and
simulators for simple machines. It is nevertheless by no means obvious that
this is the best solution to the problem; the problems attendant upon running
batches of students' work are well-known, and the requirement for even more
software and corresponding job streams would not help. A less concrete, but
nonetheless real, objection is that the students would always be aware that
they were not dealing with a real machine - that they were, in fact,
protected from the real machine by a cotton-wool of software. These
difficulties are not insuperable, and a viable course could be constructed
using the B6700; the point is that there is a better way.
The alternative is to provide a much simpler computer which the
students could progamme directly. A minicomputer with 8K of core storage
would be adequate as the machine itself, and a mark-sense reader and a
teletype or similar device would be suitable as basic peripherals. In
addition, to allow students to choose one from several programmes to execute,
to permit the development of a reasonably realistic operating system for
demonstration purposes, and to provide protection against the inevitable
corruption of programmes in core ( particular when using the assembler ),
a single disc drive would be required as backing store. The cost would be
in the region of $10000 to $15000; the extent of the necessary software
development would depend on the suitability of the software provided by
the computer manufacturer.
Alan Creak.
12-v-1974
|