INMC 80 News

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 use it.

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.