The “Let’s write an Interpreter” section.
All microcomputer users should, at some stage in their programming experience,
try to design a programming language, and then implement it on their system. This is a
very good programming excercise, and will also, it is to be hoped, teach them not to
moan quite so much about the shortcomings of the work of others.
The first step, in all cases, is to specify what the language is. Pilot is
used for writing conversational programs, used in education. A considerable amount of
information about using Pilot can be found in a series in Computer Age; just as well,
really, as I have no expertise in the field of educational methods. A program in Pilot
consists of a series of lines. Each line consists of a label, or an instruction, or
both. An instruction consists of the following parts:
1/ A valid Pilot op-code, consisting of one or two capital letters.
2/ An optional condition code, the possible forms these can take will be described
later. If the condition is not met, then the line will not be executed.
3/ A separator, consisting of a colon followed by a space.
4/ The “text field”, the contents of which vary, depending on the op-code type.
It is, of course, possible to state all the above with far greater precision
by using the “Backus-Naur Form” of syntax definition. The actual op-codes can also
best be defined in this way. BNF is splendad, but takes pages and pages, so we won’t
Some versions of Pilot get round the problems caused by the lack of line
numbers in the language by adding pseudo-line-numbers. Of course, this is a shameful
cop out, and we will have none of it. This will mean that the editor will not be as
wonderful as the one the Nascom BASIC has. For a really good description of why it is
easier to write an editor if the language has line numbers, see P.J.Brown’s book,
“Writing Interactive Compilers and Interpreters” at your library. Or buy it, if you
have that much money, and are that interested.
Another thing we are going to do that Brown advises against, is store our
language in the same form that it is written. This will save the effort of writing a
translator, of the type the Nascom BASIC uses to convert reserved words into single
byte tokens. Pilot is particularly suited to this storage format, because it has such
short op-codes. There’s a catch, of course. The section of the program that actually
runs the Pilot program becomes slightly more complex. With other languages, this can
be a major problem......
The op-codes allowed in this version
of Pilot are as follows:
A = Accept input from keyboard.
C = Calculate.
E = End subroutine.
J = Jump to label indicated.
M = Match the contents of the text field with
the contents of the input buffer.
P = Precondition, or defined process, instructions. PR, in Common Pilot.
R = A remark.
S = Stop.
T = Type, similar to PRINT in BASIC.
U = The equivalent of GOSUB.
V = Call machine code subroutine. (This is
dreadfully non-standard, but handy.)
Purely for the sake of simplicity, I have ignored the standard form of Pilot,
which may well result in my system being ignored. Not to worry, I can always claim
that I am really writing about how to write an interpreter! In Brown’s book, ignoring
language standards is described as the fourth deadly sin.