Last month, I explained how it was possible to extend the language to include almost any facility you might want. We went on from there to look at FORTH's basic conditional operators and the way that branching and looping structures are set up. This month, we will look at conditional loops in FORTH and the significance and use of the language's two stacks. I will also outline the language's assembler mode and introduce some new words.

Before we start, however, let me remind you that where necessary, FORTH words are enclosed in square brackets — [ ] — to make them stand out clearly. (Those familiar with FORTH may have been having a quiet chuckle at our use of quotes to indicate reserved words, the quote symbol itself being a reserved word! We are now substituting square brackets, and anything enclosed by these should be taken as being FORTH and not text. Ed.) In addition, wherever I show a dialogue with the computer, the computer's responses and prompts are underlined.

Conditional Loops

In FORTH

Last month we saw how to construct conditional branches (BASIC's IF...THEN...ELSE) and finite loops (FOR ...NEXT in BASIC). While you can do an awful lot of programming with just these two structures, they are sometimes very limited and force you into rather involved bits of code. In particular, you may wish to loop an unknown number of times until an event takes place, or you may wish to loop while a set of circumstances are true (or false).

While these two conditional loops are very similar,  they have the fundamental   difference that,

You will probably have guessed that FORTH also provides these structures. An example of the first type, in which a function must be repeated until a condition occurs, is the processing of a string of input items, BASIC has to resort to conditional GOTOs to handle this case, but FORTH provides:

As an example, let's define HEXPFIINT to input decimal data from the keyboard and print its hexadecimal equivalent. The loop is to finish after inputting (and converting) decimal 100. The answer is:

However, back to the example:

This structure tests <condition>, and executes <operation> if the TOS is '1'. The PEND then loops back to WHILE to repeat the test again; Fig. 2 shows the operation of the function. Notice another difference between this and BEGIN... END; <operation> is PERFORMed if <condition> is TRUE, but END repeats <operation> if <condition> is FALSE. You have to watch your test very carefully.

Although MMSFORTH uses WHILE...PERFORM...PEND, other versions of the language use functionally identical constructions such as BEGIN...WHILE...REPEAT or BEGIN...IF...WHILE.

Repeating the HEXPRIN example above using this con-struction is easy:

'Why two versions of the indefinite loop?', you say. Most of the time, either would be perfectly acceptable but if data must be processed until an appropriate result emerges, use BEGIN...END. At other times, the input data controls the need for further processing - in such cases, the second construction is better. The second version of HEXPRINT is more suitable.

Just like the looping and branching structures we looked at last month, BEGIN, END, WHILE, PERFORM and PEND are Defining Words that can only be used within colon definitions. If you try to use them in FORTH`s immediate mode, you will get an error message.

I hope that it goes without my saying that all these conditional and looping structures can be nested pretty well as much as you like. Next month's article, will contain a FORTH program called "HANOI" which gives examples.

Since two of FORTH's major advantages are its running speed and the very free access it gives to the computer's operations, there is very little need to use assembly language segments in FORTH programs.

FORTH words are defined in assembler terms in a way that is very similar to a colon definition. For example an MMSFORTH segment to whiteout the screen is:

As soon as you ENTER, this is assembled and the new FORTH word WHITEOUT gives access to the code. You can try it out instantly by typing WHITEOUT, or you can incorporate the new word into any additional 'conventional' FORTH words.

I won't go into any more detail on FORTH assembly programming, but it is worth noticing three things about the definition above:

We know by now that FORTH is a stack-based system. In fact, it actually uses two stacks. The most important one for the programmer is the PARAMETER STACK - that's where data goes and is operated on.

The second stack is the RETURN STACK and holds the return ad- dresses, loop counters, etc that the system needs as it goes up and down the dictionary. In effect, it is equivalent to the  single stack  assembly-language

Although the return stack is normally transparent to the programmer, it is possible to push and pop data onto and off it. The [<R] word takes the top item off the parameter stack and moves it to the return stack, while [R>] moves a word in the opposite direction. In both cases, the word is removed from the source stack. When we studied the DO...LOOP last month we met [I which copied the loop index on to the parameter stack. In fact, [I] can be used at any time and will put a copy of the top , number on the return stack on to the parameter stack, without altering the return stack. If you like, [I] is equivalent to:

It would, however, be pretty clumsy programming to get yourself into this position.

Just as in assembly programming, you must be very careful how and when you move data to or from the return stack, since it is very easy to corrupt return addresses and so crash the system. As a general rule, if you take something off the return stack you must replace it within the same word and vice-versa.

We have now met many of the common 'standard' FORTH words, but there are a few more which can provide some very useful functions:

[1+] This word simply adds 1 to whatever number is TOS; it has a counterpart, [2+] which adds 2. Their advantages are that they take up slightly less memory and run slightly faster than the equivalent [1+] and [2+1].

[2*] You will not be surprised to read that this word doubles the TOS. [8*], [16*] and [64*] act in much the same vein. Once again, they economise (slightly) on memory and run time, although you would be very hard-

ABS This word simply converts the TOS to its absolute value tie it makes negative numbers positive).

FILL This word is very useful for loading blocks of memory with any given value. It sets the <TOS> bytes of memory starting at <2OS> to the value that is third on stack. For example, to draw a narrow line along the top edge of the TRS-80 screen, you could use:

MAX The FORTH word, MAX, takes the top two numbers on the stack and replaces them with the larger; the smaller is DROPped. If the numbers have the same value, one is discarded.

MIN This word works much like MAX, except that it leaves the smaller tie most negative) on the stack. Together, MAX and MIN provide an easy way of inputting a number and forcing it to lie in a given range:

MINUS MINUS simply changes the sign of the TOS. It effectively has the colon definition:

MOD If you want to divide 2OS by TOS and leave the remainder, then MOD is your word. For instance, to see if a number is divisible by 64:

NOT NOT simply reverses the truth value of TOS, leaving '1' if the TOS was zero. It has exactly the same effect as [0=].

SPACE To output a space to the screen, use SPACE. On its own, that is not a lot of use, 'but its extension SPACES will output <TOS>    spaces.    The   colon

In next month's article, I will give a listing for a FORTH version of the classic computer task of solving the 'Towers of Hanoi' problem. Before then, however, let's take a look at some of the essential differences between programming in FORTH and 'conventional' high-level languages.

Variables. A key feature of FORTH programming is that variables are held in the stack and not in named locations. Nevertheless, life can get very complicated if you are trying to juggle more than four or five numbers on the stack and a few carefully chosen variables can make a program much easier to write and to follow.

However, good FORTH programs use relatively few variables and these are largely used to store the numbers not being manipulated at a given time. Furthermore, the variables actually saved by name will almost certainly be only those which hold the information which the program is manipulating, rather than all the other needed to control the program.

Think about the BASIC programs you write. You will probably find that the majority of the variables are dummies, loop counters, buffers, etc; in FORTH programs, numbers in this class will generally exist only as transient data on the stack(s).

Techniques. Remember that FORTH is a structured programming language and that, to make a program easy to follow, word definitions should be kept short (seldom more than two or three lines long). When taken together, these two aspects of the language make it very difficult to avoid top-down programming, I am glad to say.

Start to write a FORTH program with a   single   word   which   will

That defines a simple program which sets itself up (via INIT), converts something to something else 10 times and then goes to see (vi, MORE?) whether any more conversions are needed.

Having set up the outline of the program, you can go on to define the new words you used, eg:

What does that word do? First of all it throws a line; having done so, it asks a question. The next word KEY, is another standard FORTH word — it puts the ASCII value o the next key to be pressed on top o the stack. The input value is compared with 'Y' (ASCII 89), and NOT reverses the truth test value so that response of 'Y' leaves '0' on the stack to force a jump back to BEGIN.

Easy isn't it? Obviously, you would also define INIT and CONVERT and any new words you might use in them, and so on.

Up to this point, you should have been working with pencil and paper, because your draft program will have its highest level word ['PROGRAM'] at the top, and it: most fundamental words at the bottom. You must, however, enter the program from the bottom, because each word must have access to all. the words it uses before it can be compiled itself. It is thus virtually impossible to write any practical FORTH program at the keyboard, which is probably not a bad thine since it forces you to think about what you want to do. The ease with which working BASIC program can be written directly from the terminal is one of the reasons that there are so many badly-structured BASIC programs about!

With a large and/or complicated program, it is not necessary to prepare it all before you start to enter it to the system - sometimes, you won't even be able to. Because the language is so modular, it is easy to use dummy words in some places while you are developing other parts of the program. The dummies do not need to do any processing, but should show that they have been called and, if  appropriate, input   suitable data

As you enter your program, FORTH's highly interactive nature lets you test each word in isolation. Because it is so easy to test every detail of the program, debugging time is usually very much shorter than it is with BASIC. On the other hand, effective FORTH programming demands a much more careful design approach than you can get away with in BASIC. On balance, once you are used to the language, it is much quicker to design and fully debug programs than it is with more traditional languages.

Remember then, that while it is

Layout. Any sensibly-sized program will normally occupy several screens of source code. However, because this code will be compiled, you do not have to concern yourself with RAM space and run-time as you do with BASIC. Indeed, the program will be much easier to follow if you:

Because MMSFORTH holds two screens in memory at once. I find it easiest to develop a program in pairs of screens, arranging the definitions of group-related words into the two screens in memory at any given time.

The listing in next month's article will demonstrate the application of these principles.