Skip to main content
© Niklas 'Tanis of TCB' Malmqvist

Some dozens make a long dozen,
but they won't make  thirteen.  
          Some wise guy

                        STRENGTH IN FORTH

                           part twelve


I  decided  to give part twelve of this  FORTH-course  the  above 
title after many deliberations.  I thought it was getting time to 
give you an overall view on the FORTH-system.  That means we have 
to  put things together,  which have been scattered all over  the 
course  and we have to explain things we left in the darkness  of 
'coming  soon'.  This time we are going to discuss three  smaller 
subjects: a) how a FORTH-system could look like; b) how a word is 
placed in the dictionary and c) how it is searched for. I hope, I 
can  manage to put it all into a First Word file of 32K.  At  the 
end of this part you will find the solutions to part eleven,  but 
there will not be any new exercises, as the  subject of this part 
isn't fit for it.
It may have occurred to you,  that FORTH has many faces, although 
you   will  recognise a FORTH-system at the moment you  see  one. 
What I do not mean with the word "system" here,  is what could be 
better described as the "package" you get when you buy a FORTH or 
when  you  get one of the many FORTHs,  available in  the  Public 
Domain.  In  this last department - as far as I know - are  three 
FORTH-packages  which  use a 16-bit  stack.  Those  are  COMFORTH 
(september-87-version),VOLKSFORTH  vs  3.8  and  ST-FORTH.  There 
happens  to be only one PD-FORTH which uses 32-bit  stacks.  This 
FORTH  is called UNIX-FORTH-83.  It is not available in  any  PD-
library in the Kingdom of The Netherlands.  This is due, I think, 
to   the fact  that three files of the version  which  circulates 
among  ST-owners,  are irrepairably damaged.  These files can  be 
well  left  out  and  yet you will  have  a  perfectly  operating 
FORTH. One of my FORTH pen-diskfriends - I don't own a modem - is 
constantly  working to enrich this UNIX-FORTH with new items. The 
other day he has develloped a marvelous editor and he now is busy 
all  day   programming a GEM-library.  This 32-bit FORTH  can  be 
obtained  by modem-owners through the BBS ST HAARLEM  phone  023-
340077.   In the commercial war-zone there is a fight between  at 
least  one (1 !) 16-bit and two (2 !) 32-bit  FORTHs,  which  are 
called ST-FORTH - same name as the one PD - 32-FORTH and  4*FORTH 
respectivily. All FORTHs mentioned here are  very well documented 
except  for  the UNIX-FORTH.  But I am working to  overcome  this 
shortcomings. I've just finished a Glossary of all the words used 
in the Kernel.  This Glossary contains a description - in  ASCII-
order  - of the stackaction,  the name of the word,  the use  and 
further  details of all( minus 6) Kernel words.  As soon as  I've 
completed this huge task by adding all user-words of the Utility- 
and Assembler-files,  you will hear from me. I will - of course - 
see to it,  that this Glossary will be PD.  Soon there will be  a 
pre-release  to give some smarter guys than me an opportunity  to 
comment to that Glossary.   It must be said,  that a FORTH with a 
32-bit stack does not quite match the  83-Standard.  I think it a 
minor  difference  for the user.  Instead of using  the  optional 
Double  Number Set in the 16-bit configuration to  handle  larger 
numbers (larger than 16 bit can hold),  the 32-bit FORTH provides 
facilities to meet with explicit 16-bit values. So, it is in some 
respect the other way round.  All these FORTHs provide a Kernel - 
the naked system - some editing facilities and an Assembler.  And 
often  much  more !!  But we are not really interested  in  these 
elements.  Here and now I will link your attention on the  memory 
allocation  of FORTH when the system has been installed  in  your 
ST.  I will not mention absolute memory-addresses,  as these  may 
vary widely,  depending on the system in use, nor is it to you to 
take the given description as a  prescription to which a FORTH is 
pinned down.  At the end of my description of a  FORTH-system,  I 
hope  you'll be able to 'decode' any FORTH in  the  future.


First of all I'll better draw a memory-allocation map of a FORTH-
system,  based  on  UNIX-FORTH-83.  Just for illustrating  a  few 
points, eh !!

    ?                                     ?
   /|\                                   /|\
    |              video ram              |
|                                             |
|                 Free Memory                 |
|   ^                                     ^   |
|        v                           v        |
|                                             |
|        ^            Here           ^        |
|                                             |
|           Applications Dictionary           |
|¯ ¯ ¯ ¯ ¯ ¯ ¯ ¯ ¯ ¯ ¯ ¯ ¯ ¯ ¯ ¯ ¯ ¯ ¯ ¯ ¯ ¯ ¯|
|                                             |
|              Kernel or Nucleus              |       
|                 Dictionary                  |
|                                             |
|                                             |
|                                             |
|_up0___^___________User Area_________^___up0_|
| rp0   v          Return Stack       v   rp0 |
|                                             |
|                                             |
| sp0   v         Parameter Stack     v   sp0 |
|                                             |
|                                             |
|                                             | 
|                                             |
|      v                               v      |
|                  Free Memory                |
|                                             |
|       |                             |       |
|       v          Used by GEM        v       | 
|                                             |
|                                             |    

I told you once, I could do some nice painting....Well....?!
To give you an idea about the amount of space my configuration of 
this UNIX-FORTH uses to settle down,  imagine HERE is at  address 
427152,  ORIGIN at 327680 and SP0 at 326684.  The v- and  ^-signs 
are to be considered as arrows, maybe  pointing up,  maybe  down. 
Let's  begin  where each carreer  the  bottom.  And 
secondly,  let's give GEM,  what it belongs:  the memory-space in 
the deep dungeons of your ST.  All memory up to Next-Free-Memory, 
not  used  by GEM,  may be used by you.  Climbing up  our  Social 
Memory  Staircase we arrive at Parameter Stack and Tib.  On  both 
sides of these words are sp0 and 'tib.  If we should  investigate 
these  two  little  words,  which we will,  we  are  to  discover 
something strange.  Both words are user-variables. They hold some 
value,  where variables are made for, and they both hold the same 
value. That value is a memory-address. This address now indicates 
the  start of the Parameter Stack (hold by sp0),  the so   called 
bottom of the stack,  and the start of the Terminal Input  Buffer 
(hold by 'tib) as well.  As you can see the arrows point down  in 
the stack area and up in the buffer area. The meaning of this is, 
that  putting  values on the stack will cause the stack  to  grow 
downwards.  Every  next value is put at a lower address than  its 
predecessor. This movement is closely watched by another pointer-
word {SP@).  We used this word in one of the first issues of this 
course.   It  will  print  the  address  of  the  next  available 
stackspace,  when used as {SP@} {.}.  If we were able to increase 
the pointer, held in {SP@}, FORTH would think that the next value 
was  to  be put at that higher address and  would  overwrite  the 
value already there.  Putting values onto the stack and  DROPping 
them  again  is made possible by increasing  and  decreasing  the 
address held in that Stack Pointer.  So,  if you get the  message 
Stack  Empty,  then  it is not to inform you that  there  are  no 
values in the address space of the Parameter Stack,  but to  tell 
you that the Stack Pointer points to the bottom of the stack.  In 
the case of the Terminal Input Buffer  the terminal input  starts 
at the bottom,  called Tib and moves upwards. This buffer is only 
a minor one.  Mostly it is as large as 80 bytes.  Still higher we 
see a similar situation.  This time the Return Stack and the User 
Area  are involved.  The functions of the Return Stack have  been 
explained  earlier.  As  you can see it grows downward  to  lower 
memory-addresses.  Starting at up0 and moving to higher memory is 
the User-Area. Here live those mysterious user-variables. Now the 
time  has come to throw some light on those  peculiar  creatures, 
which  you  met  frequently,   but  which  I  nevertheless   left 
unexplained.  A user-variable is a system variable.  This  means, 
that the value linked to such a variable - a number or an address 
- is of high importance for the welfare of the system. Many user-
variables  are initialised on a cold start of  the  FORTH-system, 
and  should  not  be  used for plain  variables  in  an  ordinary 
application. Only if you intend to make system modifications, you 
are  allowed to modify user-variables or to create new  ones.  It 
should be perfectly clear,  that user-variables are  specifically 
not  intended to be used and certainly not by the user  In  UNIX-
FORTH  the  User  Area is exactly 1024  bytes  high.  That  means 
whereas for a 32-bit FORTH every value counts 4 bytes,  that  256 
different  user-variables can be hold in this  residence.  That's 
fair enough !   Let's look still closer by creating a fancy user-
variable.  We  need the word {NUSER}.  100 {NUSER} IPL  OK  .  We 
created  a new word {IPL}.  So {NUSER} is a  defining  word.  Two 
things  happened.  First:  the name of the new user-variable  was 
placed  in the DICTIONARY as usual. Secondly: space was allocated 
(4 bytes),  in a separate User Area,  in which the value of {IPL} 
will  have to be stored at a later date.  This value will not  be 
100,  as you might have expected.  It could be 100,  but it  will 
never be that 100 we used to define the variable {IPL}.  That 100 
is an offset. Hundred times 4 bytes are added to the address held 
in  {UP0}  - the start of the User Area - and then  4  bytes  are 
allocated  to  hold the value of {IPL}.  This last value  is  not 
initialised.  If you execute {IPL},  you will get the address  in 
the User Area in which is stored the value of {IPL}. If you {IPL} 
{?},  then  the  value  at {IPL}'s address in the  User  Area  is 
displayed  at  your screen.  At this moment it can  be  anything. 
It  is not said,  that your system provides the word  {NUSER}.  I 
used it from that UNIX-FORTH.  Two more additional words  may  be 
used  to  define  a user-variable  in  that  system:  {USER}  and 
{TUSER}.  The  basic  word is {USER}.  {NUSER}  and  {TUSER}  are 
basically equivalent,  but their names are chosen merely for  the 
sake of easy understanding. To get the same result with {USER} as 
with  {NUSER} I should have entered 100 {4*} {USER} IPL.  May  be 
that  100 {USER} IPL will do in other systems.  Some very  common 
user-variables are:

 Name  |  contains             Name | contains
UP0     start of User Area     SP0     start of parameter stack
RP0     start of return stack  DP      first free dictionary byte
FENCE   barrier for forgetting CONTEXT vocabulary searched first
CURRENT voc for definitions    STATE   compile or interprete ?
BASE    for numeric in- output DPL     numeric input punctuation
LAST    nfa of latest def.     HLD     points to last char in PAD

and there are several more.


The  next  station  we  will visit on our  race  to  the  top  is 
{ORIGIN}. Here is the start of the Kernel, the Nucleus, the Root. 
All  addresses in a FORTH-system are derived from {ORIGIN}, which 
on  execution  gives  the address of  the  beginning  of  FORTH's 
precompiled portion of the dictionary.  Going up we meet {FENCE}. 
As  you just saw,  {FENCE} is a user-variable.  Its value  is  an 
address between {ORIGIN} and {HERE},  between start and finish of 
all the code compiled in the dictionary,  the Root as well as the 
applications' part.  This address acts like a barrier.  When  you 
instruct {FORGET} to forget a word,  {FORGET} will do the job, if 
it can find that word between {FENCE} and {HERE}.  If the word to 
{FORGET} is situated beneath {FENCE}, there will be a message and 
the system will {ABORT}. The dictionary part between {ORIGIN} and 
{FENCE}  is a restricted area for {FORGET}.  You may  change  the 
barrier-address in {FENCE} to a higher or a lower address: {HERE} 
{FENCE} {!} will store the address of the first free space in the 
dictionary in {FENCE}. As long as you will be programming in this 
new configuration,  only the words you will enter afterwards, can 
be forgotten.  This method is recommended if you want to add some 
application  to the dictionary for good.  In this case  you  will 
have to save this configuration to disk,  of course. Most systems 
provide words to do so:  {SAVE-SYSTEM} or the like. Of course you 
can  act  like this:  {ORIGIN} {FENCE} {!} OK and  then  {FORGET} 
{ORIGIN} OK.  It won't harm anybody personally,  except you !  If 
you  fully  back-upped your system,  then you  may  recover  your 
FORTH.  Otherwise  you are through and done !!   As you can  see, 
{HERE} fluctuates.  It can go up, it can go down on the rhythm of 
adding to and deleting words from the dictionary. And with {HERE} 
{PAD}  moves  up and down in the same  rhythm.  {PAD}  is  simply 
defined  as :  PAD   HERE 50 + ;  in this  UNIX-FORTH.  {PAD}  is 
really a scratch-pad.  It allows two different kinds of  use.  It 
may be used as a scratch-pad for numeric output conversion.  As a 
numeric pad {PAD} stores its data downwards. If the scratching is 
done with text,  then {PAD} stores the data upwards.  The  FORTH-
dictionary  may grow until the end of 'normal' memory is  reached 
and  the video-ram begins.  How much room there is left for  your 
own applications depends on the system you use.  ( And the  Atari 
you can afford !!)

The second item we were to discuss in this issue, was the item of 
how  FORTH  places  a  word in  the  dictionary.  I've  told  you 
something about it,  but not those very intimate details.  So  if 
you are over eightteen,  keep on reading,  otherwise ask your dad 
or mum. First lesson: every FORTH has his own way ! I told you so 
in  part  10 of this course.  Then we were  discussing  the  word 
{MBUF}.  So look back and read it again.  It was said there, that 
my magnificent 1STWORD-drawing of an dictionary-entry was not the 
one and only permitted.  Several differently constructed  entry's 
are  possible.  But there are always a number of  elements  which 
can't  be  left  out  in any entry.  Every word  has  to  have  a 
christian  name.  Christianed  or not.  Some  FORTH's  have  some 
limitations on the length of the name:  a maximum of 4 characters 
e.g.  Others don't care what length, as long as a particular name 
doesn't  exceed 31 characters.  Some of those  will place only  a 
limited amount of that 31 characters in the NAMEFIELD, others are 
more  tolerant and will take them all 31.  So there has to  be  a 
namefield. The startaddress of this field is shorthened to {NFA}. 
In  this namefield the first byte helds the number of  characters 
stored in the namefield. Secondly there has to be PARAMETERFIELD, 
even  if  it  hasn't  been initialised.  In this  field  data  is 
stored.  The startingaddress of this area is shortened to  {PFA}. 
The  data  in the parameterfield can be a number ( all  data  are 
numbers of course,  but I mean a real number,  a value),  or they 
can  be addresses.  The third field is  called  LINKFIELD.  {LFA} 
stands for the startaddress of this field.  For the simple-minded 
Dutch: not only is it  a field that by means of an address stored 
in  that  place links the whole dictionary together,  but  it  is 
really  a "link" (for simple-minded English-speaking  "tricky"  ) 
field.  More later !! The fourth (beautiful word !!) field is the 
CODEFIELD  or COMPILATIONFIELD.  I prefer  codefield,  because  I 
can't type very fast.  The short form for the startingaddress  of 
the codefield is {CFA}.  This field holds a pointer to the  start 
of  some  code.  To  what code depends  on  the  action,  that  a 
particular  word has to perform.  Don't think that a  computer  - 
even loaded with FORTH -  has a basketful of such codes: NO ! 
FORTH  has some words to switch from namefield to  linkfield  and 
from  codefield to parameterfield etc.  A list is to be found  at 

This  four  fields are used to make a word and  with  many  words 
together a dictionary in each FORTH. In the middle of two fields, 
or in the front of all four,  or at the  back will be inserted  a 
byte !  In this byte resides the immediate bit,  or not,  if  the 
word is not immediate.  Which bit will be honoured with this task 
is  of no importance.(For instance in that UNIX-FORTH it  is  the 
sixth  one,  but  it  could  as  well  have  been  the  fifth  ). 
Principally it is of no importance either,  in which order  those 
four fields are grouped. In the WYCOVE-FORTH the linkfield is the 
second  one after the namefield has been set up,  as it  is  FIG-
FORTH.  In UNIX-FORTH the linkfield is the first field,  standing 
in front of the namefield.  So we have a name,  data and specific 
code which can handle the data.  As I said the most tricky  field 
is the linkfield.  This field 'chains' the dictionary. But not in 
the way you thought it would do. Suppose our dictionary has grown 
to  some  extend  of 1000 words and we  want  a  particular  word 
executed. So
{."} Linkfield {"} Linkfield OK

will  print out at your screen "Linkfield".  It was done  by  the 
word {."}.  Before FORTH can execute that word, FORTH has to look 
it  up in the dictionary.  And FORTH has to find the right  word, 
not some ' this will also do'-word.  So FORTH has to  investigate 
the  whole dictionary,  if a word happens to be deep  in  FORTH's 
dungeons ?? NO !! Perhaps you would, FORTH won't. In this respect 
FORTH is a junk,  he uses HASH.  This HASH-function is that  very 
tricky  way in which FORTH succeeds to minimalise the  amount  of 
dictionary-words  to find its way through,  to come to the  right 
desired  word  and  that beyond any  doubt.  It  depends  on  the 
'depth' of the HASH-function,  but at any 'depth' it will save an 
enormous  amount  of searching in the dictionary and  thus  time, 
time and time again.  Simply said,  the hash-function divides all 
words  that will be entered in the dictionary  into  groups.  How 
many groups depends.  My lovely UNIX-FORTH has four groups, but a 
FORTH like 4*FORTH has some 16 (!).  The forming of the groups is 
simply  done by looking at the first character of the  word.  And 
{HASH} - in UNIX-FORTH - is a normal word. Or should better I say 
spell ?


Problably  the  supersonic  speed at  which  FORTH  searches  the 
dictionary for a particular word,   have struck you.  Partly it's 
the language's speed itself. For a (much greater) part it is - as 
I described above - the {HASH}-trick that does it. This trick has 
a  double  effect.  At  first it works when  you  enter  a  word, 
afterwards - when there is a search for a word - it makes use  of 
the  information  that  {HASH}  provided  and  that  was   stored 
in.....the LINKFIELD !!    The dictionary is not really a  simple 
chain  of  words,  one after another as they have  been  entered. 
Actually the dictionary is splitted up in vocabularies ( See part 
11).  A  vocabulary consists of a group of words that for some  - 
most logical - criterion has been brought together:  the  Editor, 
the Assembler.  But such a vocabulary itself isn't a compact list 
of all the words belonging to itself too.
Vocabularies can be into  two very different states. A vocabulary 
can be the {CONTEXT} vocabulary.  That means that the search  for 
words  starts  in  this  vocabulary.   As  all  vocabularies  are 
connected  - similar as the words are linked -,  a search  for  a 
word will continue in the next linked vocabulary, if a word can't 
be found in the {CONTEXT} vocabulary.  In the other situation the 
vocabulary   is  indicated  as {CURRENT}.   It  means  that   new 
definitions  are placed in that vocabulary.  And as we  mentioned 
above, at the creation of new entries {HASH} gets  the lead.

So let's reveal {HASH}'s secret in the UNIX-FORTH. Assuming, that 
EDITOR is the {CONTEXT} vocabulary,  {EDITOR} {DEFINITIONS}  will 
make  it  the  {CURRENT} one,  in which new  definitions  can  be 
placed.  Because  {HASH} is part of {CREATE} (and that  last  one 
part of the  {:}-word), we can study the mechanism by which a new 
word  is placed in the {CURRENT} vocabulary  best,  by  analysing 
{CREATE}. First of all, {CREATE} has to accept a namestring. That 
will be the name of the new word.  This string will be moved then 
to   the  buffer  called  {WORD}.   {WORD}  always   leaves   the 
startingaddress  of  that string on the stack.  This  address  is 
going to be {DUP}ed first and one of the two stringaddresses will 
be  used to check if the name of the new word you want to  create 
already exists. If, then a message is given: .....isn't Unique or 
the  like.  The  next thing to do,  is to 'even' the  address  of 
{HERE},  then  the  address  of {HERE} is  put  onto  the  stack. 
Remember {HERE} is at the top of the dictionary !! At the address 
of  {HERE},  {CREATE} puts a zero.  So {CREATE} keeps that  place 
occupied, because {CREATE} will use this place within a second or 
less  to store the linkaddress.  What is to come now  ,  is  very 
important  for to understand what follows afterwards.  You  know, 
yes you know,  that when {CREATE} put that occupying zero at  the 
address  of {HERE},  {HERE} was incremented ( with  4,  as  UNIX-
FORTH's numbers counts 4 bytes = 32 bits),  to form a new-{HERE}. 
This  new-{HERE} is {DUP}ed,  one is put onto the stack and  with 
the help of {!} the other one in {LAST}.  This is done because in 
this  UNIX-FORTH  the  namefield comes after  the  linkfield  and 
{CREATE}  is  going  to use this  new-{HERE}  as  the  {NFA}.  So 
recapitulating: on the stack are two items: on top the old-{HERE} 
and beneath the {NFA} of the namestring of the new word.  We say: 
the new word is called {PIPO}.  Now {CREATE} {SWAP}s the items on 
the stack.  The stringaddress is on top now.  The use of  {COUNT} 
{HERE} takes care of a stack on which the items are well fit  for 
the work {PACK} has to do.  This word is a character-moving word. 
{PACK} gets the namestring - the countbyte as well - and puts  it 
on  the  address of new-{HERE} and in one go {PACK}  places  this 
new-{HERE}-address on the stack.
On   the  stack  are  old-HERE -  {LFA} - and new-HERE -   {NFA}. 
{CREATE}  now puts the address of {CURRENT} on top of the  stack. 
The pointer to the vocabulary into we want to place the new  word 
PIPO  is hided in that address. The stack shows {LFA} -  {NFA}  - 
vocabulary-pointer,  all prepared well for {HASH}.  {HASH}  takes 
the voc-pointer and puts it into the D1-register van de 68000-mc.
The  stringaddress  goes to A0.  This register  -  that  is,  the 
address  in the register - is incremented with one to  jump  over 
the countbyte.  You know,  strings do have countbytes; they count 
the  characters of the string.  We are at the first character  of 
the name of the word. It was getting time !! That first letter is 
the 'p'.  And this 'p' is bytemoved to register D0. As a register 
counts 32 bits,  the rest - 24 - has to be turned to zeroes. This 
D0-register now looks like:
0 0 0 0 0 0 0 0- 0 0 0 0 0 0 0 0- 0 0 0 0 0 0 0 0-0 1 1 1 0 0 0 0 
This configuration is ANDed  with 3,  binary 11.  Three,  because 
UNIX-FORTH  has  four - 0 1 2 3 - threads.  The  meaning  of  the 
thread-word  will  be  explained in  a  moment.  Let's  take  the 
contents of register D0. We only take the right byte: 0 1 1 1 0 0 
0 0.  This is the binary code for lowercase 'p'.  The other three 
bytes  on  the  left side are always  zero.  The  rightmost  byte 
changes  if  the first letter of the new word  changes.  In  this 
rightmost  byte the only important bits are those  two  rightmost 
bits,  as  these bits are the ones that may be changed by  ANDing 
with 3.  The number 3 itself also consists of 32 bits, but the 30 
leftmost  ones  are  always  zero  and  in  this  context  of  no 
importance.  These two rightmost bits of the first letter of  the 
new word in register D0 can look like the following:
                      0 0     0 1     1 0     1 1  
ANDing with 3         1 1     1 1     1 1     1 1
Result                0 0     0 1     1 0     1 1
The result in decimal:  0 1 2 or 3. Thus in D0 stands,  depending 
on  the first letter 0 1 2 of 3.  By adding D0 twice  to  itself, 
the D0-register will show  0 4 8 of 12.  All characters that  can 
serve  as  the first character of a FORTH-word are  divided  into 
four  groups in this simple way !!  The  characters   d h l p are 
part  of  the group of 0, a e i n in the contrary  belongs  to 4. 
All characters belonging to the  same group are called a  THREAD. 
So there can be 4 threads or 10 or 16. You should experiment with 
the ANDing, to see how you will get 8 groups of characters. Let's 
stick  with 4 groups.  The result of the ANDing is added then  to 
the  voc-pointer.   In the  case of PIPO  the  result  was  0 and 
therefore   the voc-pointer remains   unchanged. Out   of    this 
pointer is   destilled  an  address. NOW  THIS  ADDRESS  IS   THE 
    So in voc-pointer+0  is  the 
linkaddress of the previous defined word beginning with  d h l  p 
or  another  character of this thread.  In voc-pointer+4  is  the 
linkaddress  of  the  group of a.o.  the characters  a e  i  n  . 
Etcetera.  After all that  the address of old-HERE is placed into 
this voc-pointer,  so the following word of the 0-thread can  use 
it  as  a  link.  Remember:  in the  voc-pointer  is  always  the 
linkaddress of the latest word of a specific thread that has been 
defined. We  have  the linkaddress of  the  previous  word.  This 
address  is  put into the address of  old-{HERE},  the  {LFA}  of 
{PIPO}. As each vocabulary has its own {CONTEXT}-address, it also 
has its own thread-addresses.  How vocabularies are chained is in 
relation  to  {CREATE}  of  no  importance;   that  subject  gets 
important when a particular word has to be searched by {FIND}. At 
last  we  have got so far,  that we  can  gladly  announce,  that 
{CREATE}  has done the job it was hired for.  The only  remaining 
thing for {CREATE} to do is to construct the immediate-byte.  But 
explaining  that  we would go to deep into  the  UNIX-FORTH.  The 
facts are that after the nfa of {PIPO} a so called flag-byte   is 
inserted and initialised to zero.  Is an IMMEDIATE word involved, 
then the word {IMMEDIATE} will set one of the bits into the flag-
byte.  In  all  other cases all bits will be zero.  At  last  the 
codefield   and  the parameterfield are installed.  And  so  dear 
countrymen and lovers an entry has become something like this:

                       |     LFA      |
                       |              |
                       |     NFA      |
                       |              |
                       |  FLAG BYTE   |  
                       |              |
                       |     CFA      |
                       |              |
                       |     PFA      |

We saw,  how {CREATE} made use of {HASH} to build 4 little 'sub'-
vocabularies  into a vocabulary.  Each 'sub' is a linked list  of 
those  words that have the two same rightmost bits of  the  first 
character of their name in common state. As the words provided to 
do the search- part of FORTH's job, make use of that same {HASH}, 
the  word  asked  for  can be found -  in  the  most  unfriendish 
circumstances  - by searching 25 % of ALL words.  This  increases 
the  searching speed with 300 % at worst  conditions.  And  these 
last seven sentences will have to form the third item of which  I 
promised  to  tell  you  about:  searching  the  dictionary.  But 
Statistics gives Bytes 33K and that's too much. I hope things are 
clear now, although I doubt it.
                                      With doubtful greetings !

 {N>LINK} changes nfa to lfa ******* {L>NAME} changes lfa to nfa
 {NAME>}     "    nfa to cfa ******* {LINK>}     "    lfa to cfa
 {BODY>}     "    pfa to cfa ******* {>BODY}     "    cfa to nfa
 {>NAME}     "    cfa to nfa ******* {>LINK}     "    cfa to lfa


This is going to be the most very special EXTRAS ever written  in 
this course,  because somebody has to stop Richard Karsmakers for 
going on and on about that booklet of mr.  Tolkien,  The Lord  of 
the Rings. I hope this will reach him before it's too late. Do me 
a  favour,  dear  Richard  and  read  The  Chronicals  of  Thomas 
Covenant.  There are six (6) volumes, over 2300 pages of the most 
marvelous  story I ever happened to read.  The author's  name  is 
Stephen Donaldson.  The volumes are published by Ballantine Book, 
U.S.A. The title of the first volume of the first episode is Lord 
Foul's Bane. Every episode counts three volumes and there are two 
episodes. Especially for Dutch readers it's be written here, that 
the  translation into Dutch of most volumes has been done by  Max 
Schuchart,  who was honoured with the Nyhoffprijs for translation 
(  in  magnificant DUTCH ) of The Lord Of The  Rings.  The  Dutch 
title of the first volume of  'De kronieken van Thomas  Covenant' 
is De Vloek van Heer Veil.  Published by Sirius en Siderius,  Den 
Haag,  ISBN 906441033x.  If you liked The Lord Of The Rings,  you 
are going to swallow the epos of Thomas Covenant. And in the case 
of you,  Richard,  it will purify your thoughts - nobody has been 
named SAG in that epos.  I can testify about the healing power of 
this  book,  because I didn't SENT(!!) a very angry letter to  ST 
  for two reasons.  The first one is called Thomas  Covenant. 
The  other  one is,  because I felt writing angry  and  ferocious 
letters  is the easiest thing a man can do not to solve the  real 
problem;  if there is one.  The last - milder - letter you  wrote 
about  the SAG,  was a wise decision.  You,  Stefan and  all  the 
others involved in ST NEWS in which way whatsoever,  you,  - we - 
have  to write a better worldwide diskmagazine,  not to  fight  a 
personal local war. So read it (THEM books, I mean !!).


1.  As  you might have expected,  {:} is an immediate  word.  The 
    reason why ? Well {:} has to be executed immediately to 
2.  Each  'plain'  defining word adds something  specific  to all  
    the  words it defines. They become 'family' Each word entered 
    into a vocabulary gets some mark, one could say. If the  word 
    {PIPO}  has  been  marked  as  belonging  to  the  {CLOWNS}-
    vocabulary, it has something in common with all words entered 
    in that vocabulary. In this way there is some agreement.
3.  In {PIPO}, of course. Just look 7 lines higher. 
4.  In  that  case only the {I-CRY}-word that  had  been  defined 
    last,  would have been used in other words,  that would  make 
    use of {I-CRY}.  Only all the older words than that last  {I-
    CRY}, would make use of that first one.
5.  This answer should be the opposite of the answer to  exercise 
    4.  If the two {YOU-CRY}  had been defined into  a  different 
    vocabulary,  each  execution of {YOU-CRY} in the  appropriate 
    vocabulary would result in a different response. 
6.  This definition is the usual definition of {WHILE}.  There is 
    nothing special about it.  Or  it  should be the simple  fact, 
    that  there is little or no difference between these two loop-
    starting words.

The text of the articles is identical to the originals like they appeared in old ST NEWS issues. Please take into consideration that the author(s) was (were) a lot younger and less responsible back then. So bad jokes, bad English, youthful arrogance, insults, bravura, over-crediting and tastelessness should be taken with at least a grain of salt. Any contact and/or payment information, as well as deadlines/release dates of any kind should be regarded as outdated. Due to the fact that these pages are not actually contained in an Atari executable here, references to scroll texts, featured demo screens and hidden articles may also be irrelevant.