The Best of Creative Computing Volume 2 (published 1977)

Page 28 << PREVIOUS >> NEXT Jump to page:
Go to contents Go to thumbnails
This book is also available for the Kindle

Beyond BASIC (Loaders, Systems Software, Operating Systems, Interpreters)

graphic of page


We have talked about compilers, assemblers, source programs, and object
programs. How do these programs get into the machine? One (horrible) alternative
is for an operator to load the binary instructions through the console of the
machine, one word at a time by setting switches or entering them through a small
calculator-like keyboard.

Preferably, the program could be punched onto paper tape or cards before hand
and then simply read into the machine. The capability to "read" a program into
memory requires that another program already must be in memory to cause the
reading to take place! Such a program, called a "loader," must include all of
the many detailed instructions required to read a card, for instance, and then
move all of the 80 characters or other binary information read from the card
into designated locations in memory. In fact, all input and output operations
are fairly complicated at the machine language level and the manufacturer
usually provides "utility" programs so that the programmer doesn't have to write
these himself.  For the same reason, a
"Library" of other useful routines is generally available including such things
as math functions.


Compilers, assemblers, loaders and utilities are collectively referred to as
"systems software" and are usually written by the manufacturers "systems
programmers". The using programmer is, in contrast, referred to as an
"applications programmer" and his "applications programs" are the programs
written to solve the user's problem.

Starting with a program written in BASIC, there are many steps required before
the output is available. First, a loader must be in the machine. (Loading the
loader is itself a job to be done by the operator!) Then the BASIC compiler can
be loaded in, the source program read, and the translated object program
produced as output. Now the object program is read in (again by a loader) and
then executed producing the final results. Input/output utilities and math
routines may well have been required and loaded in along with the object deck.

The smallest mini (or micro) computers are often operated in just this fashion,
with the operator handling many separate programs and manually controlling the
sequences of loading and execution. This job, too, is one in which the computer
can lend a hand.


The most important of "systems" programs is one called an "operating system"
(sometimes "executive," "monitor," "control program") which takes over these
tasks of scheduling, allocating space in memory, calling other systems programs,
etc. With an operating system (OS), the using programmer can simply state the
kind of job he wants to do (using a special "job control language" requiring a
card or statement of the beginning of his program), and the OS will handle many
of these details for him. Here, then, we have another form of computer language,
that which is used to talk with the operating system.

With an OS in control of the computer, our sequence of events is simplified. The
source program deck, written in BASIC, together with a job control card, may be
all that the user must place in the input card reader. After reading the job
control card, the OS will call in the BASIC compiler (probably stored on a disc
file), load it, translate the source program to a machine language program, load
the machine language program together with all required utility and 

'Hardware math instructions are normally limited to add, subtract, multiply, and
divide. Trig functions, square roots, etc , require programs that compute these
higher math functions using the basic instructions.


Library programs, and finally execute the object program. What we have described
here can be called a "Compile-and-Go" scheme, in which the system does not have
to stop between the translation and execution phases.


Our brief tour of systems software has omitted one important type of program,
the "interpreter," which is particularly important to BASIC users. The use of a
BASIC compiler to first translate a BASIC program into machine language for
later execution is one method available for the BASIC user to execute his
programs. It may be the only method, depending on the computer and its available
systems software. Frequently, however, a BASIC interpreter may be available to
execute BASIC programs, either in addition to a compiler or in place of it.

An interpreter differs from a compiler in one major area: an interpreter does
not translate the source program, but rather it effectively executes it
directly. Each line of a BASIC program is examined by the interpreter to
determine what actions will be required to execute (or, more accurately,
evaluate) the statement. The interpreter then performs those actions by
immediately executing the appropriate portions of its own program, and then
moves on to the next source BASIC statement. This is in contrast to the compiler
process in which the entire BASIC program is translated to a unique set of
machine language instructions which are then executed after the compiler has
finished its job.

To illustrate how the two systems differ, let's consider how they would process
the BASIC statement:

LET X = 2+3

A compiler would produce as its output a machine language program consisting of
several instructions, which when executed later would calculate the desired
result and assign it to the variable X. An interpreter, on the other hand, would
produce as its output the new value of X which is 5; no instructions or new
program would be produced by the interpreter.

What differences does the user see between a compiler and an interpreter? Not
many. Both methods ultimately produce the same end results. If the program is to
be executed many times, there is a benefit to using the compiler method; in this
method, it is possible to obtain a copy of the object program produced by the
compiler, on punched cards or tape for instance. Then when the user
"Where did you learn to debug a program, HaverStraw?"

Page 28 << PREVIOUS >> NEXT Jump to page:
Go to contents Go to thumbnails
This book is also available for the Kindle