Global Amiga Experience/globalamigaexperience.iso/compressed/development/heliosdemodisk3.dms/heliosdemodisk3.adf/Tutorials/ForthLanguage.doc

Text File | 1994-12-18 | 35.6 KB | 704 lines

     ******************************************************
     FORTH as an example of threaded interpretive languages
     ******************************************************

     The HeliOS language is a member of the family of computer languages
     known as "threaded interpretive languages".

     The most well known of these languages is FORTH, and HeliOS contains
     many features which it shares with FORTH.

     In fact, HeliOS was originally designed as a Super-FORTH system for
     the Amiga, and although it has now developed many unique features,
     most of the old standard FORTH functions are still implemented.

     All HeliOS users will benefit from a knowledge of FORTH, so we include
     here a brief "History and Discussion" of this interesting language.

     *******************
     FORTH and the Amiga
     *******************

     This is a general discussion on "what FORTH is" and "why we should use
     it on an Amiga", for those who are unfamiliar with the language.

     The Amiga is probably the ultimate "value for money" computer so far
     produced for domestic use, and irrespective of price many of us feel
     it to have a special character which sets it apart from all its
     commercial rivals.  It is above all an enthusiast's machine, with
     unique hardware capabilities, effective multi-tasking, and a lot of
     thoughtfully evolved support system software.

     With such a multi-faceted machine as the Amiga there is always the
     feeling that there is much untapped potential still to be explored.

     If we are really keen to use all the fascinating special features of
     the Amiga we inevitably have a fair amount of learning to do.  Worse
     still there is no common programming language/environment available
     on the Amiga which allows the ordinary non-expert computer enthusiast
     to experiment and learn the machine in an interactive way whilst also
     supplying the necessary speed and power.

     BASIC is never going to allow you to exploit the Amiga to its full
     capability, and C is hardly user-friendly or interactive or fast or
     compact or.......

     What we need for creative Amiga programming is a comfortable fully
     interactive language with efficient support for all aspects of Amiga
     software functionality.

     FORTH based languages are all wonderfully interactive in use, which
     makes them ideal for creative programming, so FORTH is certainly worth
     exploring as potentially an ideal Amiga programming language in spite
     of the usual claims that "C" is the only "serious" Amiga language.

     HeliOS is a FORTH based language which is very fast and efficient: it
     is fully Amiga compatible because it has been totally dedicated to and
     developed for the Amiga.

     *************************
     A little history of FORTH
     *************************

     Perhaps we can have a look at the pedigree of FORTH and the other
     members of its computer language "family".

     In the late 1960s Charles Moore, a truly original and innovative
     thinker, introduced a computer language which embodied a radically
     new approach to software design.

     He called his new language FORTH, for a slightly picturesque reason:

     "I was working on an IBM 1130, a "third generation" computer. The
     result seemed so powerful that I considered it a "fourth generation
     computer language". I would have called it FOURTH, except that the
     1130 permitted only five character identifiers. So FOURTH became
     FORTH, a nicer play on words anyway."

     Moore was unhappy with the software tools available to him at that
     time, which in many cases were the already outmoded products of early
     computer development work.  The software industry seemed ripe for a
     new outlook based on the experience gained in early years of explosive
     commercial progress.

     Like all idealists Moore may have thought that the world of computing
     would welcome a new and better approach, or perhaps he took pleasure
     in pure creativity independent of any reliance on traditional methods.
     Certainly he made no attempt to embody traditional practices in his
     new language and undoubtedly this originality was a liability in what
     is still a very conservative industry.

     Moore set out to achieve two broadly compatible aims.

     Firstly, he wanted to make communication with a computer more natural
     and intuitively satisfying: he wanted to write better software faster
     and more enjoyably.

     Secondly, he tried to satisfy the technical criteria of elegance,
     speed, compactness, efficiency, and portability.

     Moore was a rare blend of enthusiast, perfectionist, and philosopher,
     and sadly enough his FORTH language has largely remained the province
     of precisely that kind of computer enthusiast.

     The computing industry is organised in a way which tends, inevitably,
     to resist change and unfortunately FORTH never made a breakthrough into
     general usage.  Amazingly enough the computer languages in general use
     today suffer from the same ridiculous limitations as were apparent to
     Charles Moore in the late 1960s; indeed the very same languages are
     still in use fundamentally unchanged.  FORTH is still as unique today
     as it was in 1970, still an "odd man out", and still very well worth
     investigating if you are prepared to try something different.

     FORTH gained some credibility when it became the adopted language of
     the scientific Astronomical community and has been widely used in
     observatories for critical software systems used in the precise
     tracking control of telescopes.

     Although FORTH is not a common programming tool on today's powerful
     home computers, this is not because it is outmoded, but because the
     computer "marketplace" is dominated by stale commercial conservatism.

     FORTH is still a contender on the fringe of the software industry,
     especially among high performance software enthusiasts, and manages to
     keep currently available implementations on most microcomputers.

     Unfortunately, as we shall see later, some of these "domestic" versions
     of FORTH have hardly done justice to the true power of the language.

     FORTH is such an unusual but ultimately natural way of communicating
     with a computer that those of us who advocate its use tend to become
     extremely enthusiastic about it.  We also sometimes find it hard to
     convey to others its subtleties and advantages. In Moore's own words
     again:

      "FORTH provides a natural means of communication between man
     and the smart machines he is surrounding himself with. This requires
     that it share characteristics of human languages, including
     compactness, versatility, and extensibility. I cannot imagine a better
     language for writing programs, expressing algorithms, or understanding
     computers."

     One of the prime features designed into FORTH by Moore was simplicity
     and an excellent immediate interpretive mode of operation.  He always
     sought simple and elegant solutions and had a strong intrinsic belief
     in the value of being able to interact directly with the computer at
     the keyboard.

     **********************************
     Why is FORTH different and better?
     **********************************

     We need a fast, efficient, interactive and humanly readable language
     to help us tame the problems associated with using a complex machine
     to the limits of its capabilities.

     FORTH allows easy one-to-one communication with the computer in real
     time - it is wonderfully "interactive" and this means that it can
     also be FUN to use!  You can PLAY with the computer at the keyboard
     using FORTH with a freedom which you could never achieve using any
     other programming language.

     When faced with the Amiga, which is not exactly a simple machine, one
     sometimes feels in real need of a tool to simplify and facilitate
     interactive communication, instead of relying on the tedious process
     of using a compiled language such as "C".

     Certainly there would be many more creative and original software
     innovations if it were made easier to experiment at the keyboard.

     Obviously a machine like the Amiga has so many possibilities that we
     must in some way simplify and classify our aims.  We have to use the
     very best methods available to us if we are to exploit its special
     hardware to the full.  Certainly we need to experiment and "play"
     if we are to learn the full potential of the computer, but it is
     no use having easy to use "interactive" tools if they are ultimately
     not also powerful enough to exploit all aspects of the computer.

     Many easy-to-use BASIC languages allow you to do some things quite
     easily, but at the expense of speed and without the full freedom to
     explore every aspect of the Amiga's capability.

     FORTH is much more powerful than BASIC, it is fully interactive as
     well as being a compiler, it is capable of direct hardware control
     as well as high level operating system programming, and it has all
     the capabilities of both "C" and "Assembler" built into one system.

     Furthermore, FORTH is the most suitable computer language available
     for learning and experimenting because it uses a very intuitive and
     flexible linguistic approach to computer communication: using FORTH
     you teach your computer to speak YOUR language!

     If we are looking for tool to enable us to experiment, to learn, and
     above all to enjoy ourselves; perhaps FORTH may be an answer, and
     anyway it is doubtful that any of us will end up feeling that "C" is
     more fun.


     ***************
     Reputations....
     ***************

     In spite of its reputation for compactness and speed, and in spite of
     its cult status with those who have grown to appreciate its subtlety,
     FORTH has retained an ill deserved reputation for incomprehensibility.
     You may have read journalistic accounts of FORTH's peculiar and maybe
     "difficult" style of source code but don't be put off by these ill
     founded rumours - they are just simply not true!

     The fact that FORTH has been criticised over "legibility" is an amazing
     state of affairs when you consider that this kind of accusation is
     rarely, if ever, levelled at "C", which really is an extremely poorly
     designed language in terms of source code readabilty.

     The problem is that FORTH is DIFFERENT and UNIQUE, and those familiar
     with what have become "conventional" concepts find it hard to change
     and appreciate what are actually rather superior characteristics.

     Many journalists are quick to dismiss anything which is different,
     simply because they have little time to assess anything which requires
     learning new concepts.  Obviously FORTH is VERY different from the
     commonly encountered languages like "C" or BASIC and as a result it
     is simply dismissed as a curiosity.

     FORTH has very often suffered from misleading and offputting publicity
     concerning its use of reverse polish notation, but in reality a little
     understanding of the underlying principles of FORTH programming soon
     makes the whole system seem most natural and even obvious.

     Try FORTH without prejudice, and try to forget most of what you may
     already know about BASIC and "C": FORTH is a whole new world!

     *****************
     Past incarnations
     *****************

     Perhaps you may have come across FORTH in one of its early incarnations
     on the popular 8-bit micros, and it must be said here that many of these
     primitive implementations did it little justice and were often virtually
     unusable.

     Those brave enough to try FORTH on these systems have suffered at the
     hands of some terrible implementations which turned FORTH into a very
     frustrating experience.  These inadequte FORTH implementations made the
     language practically unusable except as a mildly interesting curiosity.

     Many of the commercially available 8-bit FORTHS were quite unworthy of
     the name, so if you have had experience with these unfortunate offerings
     then you should at least be prepared to give FORTH another chance.

     **************
     FORTH concepts
     **************

     FORTH is user-extensible computer language which is super-fast and
     very memory efficient, easily customisable to individual taste, and
     above all simple and fun to use.  The concepts and ideas behind FORTH
     are outstandingly well thought out and it remains to this day a truly
     excellent software tool if rightly used: FORTH is full of innovative
     and powerful new techniques.

     If you take time off to study the operation of the ingenious FORTH
     interpreter, you will see how FORTH threads together fast specialised
     machine code routines to produce a high level interactive language
     with a minimum of "overhead".  FORTH allows you to associate human
     language words with computer routines in a simple and direct way.

     You will also see how FORTH code is not only very nearly as fast as
     "pure" machine code, but is, incredibly enough, actually more compact
     in many cases than a corresponding assembly language program.

     It is worth looking at the unique features of FORTH which allow us to
     customise the language itself to our own requirements: using FORTH as
     a basis you can literally build our own required new features into a
     really usable and powerful programming toolkit.

     The real power of FORTH lies in this extendable construction and the
     ease with which high level FORTH code can be translated into machine
     code if required.

     FORTH is subtle but not over-complicated in the inner details of its
     implementation and this means that it is possible to learn easily how
     to ideally maximise the efficiency of your code.  To use FORTH really
     productively it is well worth learning how the language works at the
     innermost level, and this will be well within the capabilities of most
     enthusiasts.

     FORTH allows the user get to grips with its inner workings in a way
     which is impossible with other languages, and this gives a freedom to
     FORTH programmers to use very powerful and ingenious methods usually
     not available in languages other than assembler.

     Knowledge is power!

     ******************************
     FORTH's unique use of language
     ******************************

     The basic component of FORTH programming is the "word".

     A FORTH word is a coded function with a name which, when passed to
     the interpreter, will generate a particular software command.

     Each word can either consist of a pure machine language routine or be
     built up from a sequence of other previously defined FORTH words.

     FORTH programming consists largely of the process of defining, refining,
     and combining words into ever more complex and powerful programs.

     FORTH is by its very nature extensible and malleable, and it has been
     justly said that programming in FORTH consists in remodelling the very
     language itself.

     Writing FORTH programs is really a matter of building a communication
     channel between you and the computer, and in the process you actually
     "teach" the machine to respond to "words" of your choice.

     One interesting result of the way FORTH works is that the language
     can itself be built up in many different ways: all FORTH systems are
     NOT equal!

     If we want an ideal FORTH system modelled especially for use on the
     Amiga, we must concentrate on those factors which promote superior
     performance in terms of speed, compactness, versatility, and creative
     useability.  Above all we want to fully exploit all the features of
     the Amiga without any restrictions imposed by the language itself.

     Let us explore generally the basic nature of FORTH and the essential
     features which distinguish FORTH systems of differing capabilities.

     Like all computer languages FORTH comprises a system for translation
     of human language - words - into the numerical symbolic language which
     the CPU of the computer employs.

     FORTH optimises the human language side of the equation more than any
     other computer language and all aspects of FORTH programming revolve
     around the definition and use of words - human language words which
     each user can choose and modify as desired.

     You can literally make FORTH source code read like English sentences,
     choosing your own words for every software function and your own style
     of parameter passing.

     A good FORTH programmer hardly needs many source code comments because
     the language itself can be virtually as clear and explicit as written
     English - at least to his/her self! (well - theoretically anyway!)

     As we shall see later this ideal state of lucidity is not so easy to
     achieve in "standard" FORTH, so we need to construct an enhanced FORTH
     vocabulary which makes code not only much more readable but also much
     more efficient in terms of both compactness and speed.

     The size and quality of the set of pre-defined words which you get in
     any FORTH system determines the ability of that system crucially.

     We need to avoid where possible having to use words which contribute
     nothing to the logical task in hand; in particular we must try to avoid
     strings of words where one word will suffice.

     Think of your FORTH system as an "alien" who you need to teach how to
     help you: if the version of FORTH you use has an excellent vocabulary
     already you will need to spend less time struggling to express yourself.

     It is interesting to note that the natural sequence of human thought,
     and its expression in language, tends to come up with very well
     structured formalisations if left to express itself freely.  We all
     think differently, but we all think efficiently in our own way: we
     need a freedom to express our own ideas in OUR way rather than being
     restricted by someone else's preconceived system.

     In an ideal computer language we would look for a true reflection of
     this natural information flow with as few as possible grammatical or
     formal impositions which do not contribute to the main logical sequence.
     If your code becomes incomprehensible and convoluted, particularly to
     an unfamiliar reader, this can be a fair indication that your program
     will prove both slow and inefficient when executed.

     We ought to at least attempt to avoid extraneous functions which need
     to be inserted simply to comply with the needs of the programming
     environment rather than the logic of the problem being solved.

     A very real advantage of FORTH's free use of language is that it is
     much easier to learn and develop a software system which is expressed
     entirely in your own words, using expressions which have memorability
     and meaning for you, than it is to try to learn someone else's
     formulations.  It is a wonderful asset to any programmer to be able
     express ideas in your own way.

     It is even better when you can get instant feedback from the computer
     so that you can see at once whether or not your ideas are working out.

     This is especially true of machines like the Amiga where sheer size
     and complexity can make learning new software systems quite arduous,
     and even more so if you have to wait for a long process of compilation,
     linking, and loading before finding that you have made some obscure
     syntactical error.

     FORTH is ideal because not only can you express yourself in your own
     language very freely, but you get an instant response from the Amiga
     on a word-by-word basis if required.

     *********************
     Human versus computer
     *********************

     We have just said that FORTH make uniquely excellent use of human
     language and allows the programmer great freedom of expression and
     interactivity.

     Let us now see things from the computer's point of view.

     Another side of the human/machine relation is the unwanted imposition
     by the high level computer language of artificial logical processes
     on the way the computer's CPU carries out its work.

     There is usually a natural and efficient way for the processor to carry
     out any particular software task, and to the extent that a high level
     language forces the CPU to deviate from optimum machine code processes
     the language becomes slow and inefficient.

     Not many high level languages come anywhere near optimising their final
     machine code constructs, mainly because they lean quite heavily towards
     cushioning the end user from "bothering" with CPU operations.

     FORTH was written for people who understand how computers work and who
     do concern themselves with the nature of CPU operations!

     As we have seen, FORTH was conceived initially as a super software tool
     designed by a computer professional for his own use: it does assume a
     little more knowledge of what is going on behind the scenes than other
     languages.  FORTH requires more from the programmer but gives a lot in
     return because you have more control over low level processes.

     FORTH has been likened to a high level assembler, and from the point
     of view of the CPU FORTH code is very efficient.  It is actually quite
     simple to write pure machine code directly from the high level HeliOS
     interpreter/compiler, and converting individual time-critical routines
     into fast machine code is very easy.

     ********************
     Having it both ways?
     ********************

     All the above seems to be saying, apparently paradoxically, that FORTH
     not only optimises the human side of the equation but also the machine
     side.  Can this really be so?  Amazingly enough it can, but of course
     there are, inevitably in this imperfect world, one or two compromises.

     You gain power over the CPU only under threat of severe punishment if
     you make a mistake.  You need to be very careful what you are doing,
     and you will end up understanding intimately how the computer works
     whether you like it or not!  FORTH gives you extreme power but very
     little cushion against any errors you may make: you are controlling
     the computer at a very low level and with very high efficiency.

     At least, though, you do get to know your mistakes at once rather than
     waiting half an hour or so to have them compiled and linked before all
     is revealed!  You may not be protected from the inevitable consequences
     of faulty code, but you can at least be reassured that the CPU is not
     wasting valuable time checking for all your possible errors.  You will
     also only write optimised code if you learn to think in a way consistent
     with the logic of the computer, and FORTH is very much a transparent
     link between man and machine - a double edged sword.

     *******************
     FORTH functionality
     *******************

     Now let us have a very brief look at how the language functions.

     The first thing you must realise is that a FORTH system can be built
     and configured in many different ways and in general the main three
     performance criteria of program size, speed, and code portability tend
     to be somewhat mutually exclusive.

     All software involves a trade-off between various conflicting factors,
     and different strategies are required when designing a FORTH system
     for modern 16-bit computers as against the tiny machines on which many
     early FORTH systems were developed.

     FORTH belongs to the general category of what are called "threaded
     interpretive languages", otherwise abbreviated to "TIL", and these
     essentially use a system of pointers and stacks to control the complex
     threading together of code "units" (words) which themselves consist of
     further threaded sub-sections.

     The lowest level FORTH code units are machine coded functions, and are
     very fast: the highest level FORTH commands can be composed of many
     threaded sub-levels, and can be very slow and inefficient.  The way
     a FORTH system is designed and built has huge effects on performance,
     because the core command set of any FORTH can consist of fast low
     level functions or slow high-level "compound" functions.

     The machine code functions within a FORTH system are the "Workers",
     and they are controlled by the higher level functions.  A cunningly
     devised FORTH system can contain very few of these "workers", but can
     put them to a very varied and ingenious use.  The problem is that if
     you only have a few "workers" running around doing all the work, the
     system can get rather slow.

     It is possible to have a special "Worker" for every function, so that
     every job gets done very quickly and efficiently: this type of system
     consumes more memory and is harder to port from machine to machine,
     but it is lightning fast!  HeliOS is a FORTH based system with more
     pure machine code "Workers" than any other FORTH on any computer.

     Higher level FORTH words usually consist of instructions to tell other
     instructions to tell "worker" routines to do something.  This means
     that in FORTH you get a hierarchical "nesting" of levels of command
     and execution, with machine coded "worker" routines combined with
     high level "instructional" routines.

     There is no limit on "nesting" or combination of levels, high or low
     level constructs being easily and freely combined, and it is not even
     necessarily obvious to what extent any FORTH function combines high
     and low level code.  This leaves a great freedom for FORTH systems to
     vary in character, and it is true to say that designing a good FORTH
     is something of an art form: all FORTHs are different and individual.

     To a great extent your programming efforts will build upon the basis
     provided by a set of central core routines in your FORTH system which,
     as we have said, may be written in high or low level FORTH code.

     For speed it is vital that these central core routines be  written in
     fast machine code rather than high level FORTH.

     This distinction must be fully appreciated, so always bear in mind
     that any complex FORTH word can be written at various levels, from
     pure machine code to densely nested high level structures built upon
     very few machine code building blocks.

     The FORTH interpreter glides gracefully between the pure machine code
     and a form of vectored execution of listed code subsections.

     These code subsections can themselves be more lists of further nested
     subsections, and the inner interpreter will thread everything together
     effortlessly without you having any indication whether it is whizzing
     through pure fast machine code or churning its way up and down many
     levels of convoluted vector list nestings.

     All this means that you need to know what you are doing with FORTH:
     the language will allow you to write very good or very bad code!

     Interestingly, self-reference, recursion, and all the subtle concepts
     currently popular in Artificial Intelligence can be implemented very
     easily and well in FORTH, possibly rather more efficiently, in fact,
     than in specialised "AI" languages such as "LISP".

     ************************
     Implementations of FORTH
     ************************

     One result of the way threaded interpreters work is that FORTH can run
     with surprisingly few distinct machine code routines, which makes it
     very easy to produce in readily machine-portable form.

     FORTH can be built like an inverted pyramid on a foundation of a very
     small number of machine code routines, but in these circumstances the
     language will run relatively slowly.  Faster FORTH systems will use
     more pure machine coded core functions, as we said above.

     This means that there can be a huge difference in speed performance
     between two FORTH systems which, in terms of the functions provided,
     appear to be identical.

     Remember that FORTH high level code is very compact, so although it
     runs more slowly than a heavily machine coded FORTH system, a high
     level FORTH encoded system will be incredibly memory efficient.

     This feature can be put to good service if used judiciously and can
     enable you to combine extremely fast code in time-dependent routines
     with extremely compact code in memory critical areas.

     It is worth mentioning here that most implementations of FORTH are
     based on an early version of the language intended for use on small
     computers, with easy portability from one machine to another and very
     thrifty memory usage the major design criteria.

     With these aims in view, this type of implementation carries a very
     bare minimum of machine-specific machine language code, building the
     majority of its functions by using FORTH code to build on other FORTH
     code. This is a very memory efficient system and is amazingly compact
     and easy to port between machines. It is actually a triumph of design
     for the specific purpose for which it was written and can be used in
     incredibly tiny memory spaces as well as being easily adapted to any
     type of programming application.

     This memory economy and portability may seem quite a good idea, but on
     an Amiga we are looking for speed mainly, we have plenty of available
     memory space, and portability is not generally an issue.

     Since all FORTH functions can be coded in high level compiled FORTH
     code or pure machine code, the extent to which the designer of a FORTH
     system uses fast machine code in the main core routines determines the
     speed and efficiency of programs written using that implementation.

     For our Amiga FORTH we certainly require a tightly written fast machine
     code implementation which doesn't worry too much about using up a few
     extra bytes in the quest for speed.

     It was for reasons of memory economy on tiny machines that the original
     FORTH "virtual memory" disk-based source code editing and storage system
     was used in many early FORTHs.  This system imposed very severe source
     code format restrictions which many FORTH enthusiasts became accustomed
     to, making them unwilling to move on to more freely expressive systems.

     The old ingenious but often crude system traditionally incorporated only
     a primitive source code editing facility, and has been an anachronism
     which has crippled many versions of FORTH, especially on 8-bit computers.

     On the Amiga this kind of "primitive" system is totally unacceptable
     and must be avoided at all costs.  It is absolutely essential to have
     a good, fast, full-featured source code editor which is totally memory
     resident if you are going to manage any kind of really efficient code
     development.

     The use of source code "screens" in FORTH, which you may see mentioned
     in books, is another throwback to the old disk buffering systems, and
     should be avoided at all costs since it places unnecessary constraints
     on the formatting of your source code.

     It is best to employ a system which accepts source code text in free
     format so that you can write your programs in a style which you find
     comfortable and readable to suit your own taste.

     *******************************************
     FORTH program structure and Amiga specifics
     *******************************************

     In its purest form the code of your FORTH's core consists of a series
     of tightly written machine code routines threaded together using a very
     short connecting routine which hardly compromises performance at all.

     Obviously, however, every subdivision of the overall program carries
     this small connective overhead, so the optimum strategy is to avoid
     lots of short routines patched together every time we do a commonly
     needed task.  Ideally we should have a predefined pure machine code
     routine for every important and commonly used function to cut down
     language overheads to a minimum.  Obviously this takes extra memory
     space, but this is a commodity which we can, within reason, afford to
     trade off in our quest for speed.

     In particular, internal housekeeping tasks such as stack handling need
     to be kept as short as possible, and the "traditional" FORTH method of
     using combinations of very few primitive functions is not ideal.

     Whilst traditional FORTH's very few stack control words may be patched
     together to create very powerful compound words, this can cause a very
     significant and unnecessary loss of speed.  We can afford the memory to
     have a comprehensive fast-coded set of system routines pre-prepared,
     and again these should be part of an efficiently machine-coded FORTH
     core.

     Incidentally it is perhaps worth pointing out here that the excessive
     combination of primitive FORTH words produces code which is unreadable,
     inefficient and hard to debug.  It has often seemed to be a masochistic
     obsession of FORTH programmers to write long convoluted sections of
     code which do nothing other than rearrange the system stack using
     totally confusing and unreadable combinations of a few stack control
     primitives!

     It sometimes seemed as though stack management was the essence of FORTH
     programming, whereas in truth stack manipulation is literally a waste
     of CPU time and should be kept to a bare minimum.

     Don't be tempted into seemingly "clever" juggling with multiple items
     on the stack; keep stack usage simple, fast, and elegant, and you will
     find that a prime source of confusion and error will be eradicated.

     FORTH systems which only provide a very austere and crude set of core
     functions require a lot of extension work to create all the tools
     required for serious programming.  Even if you are prepared and able
     to write these extensions yourself, or even if the extensions are made
     available in the form of FORTH source libraries, the bad news is that
     these will be compiled as high level constructs and will carry a very
     significant speed penalty over low level core machine code routines.

     This penalty will overspill into all your subsequent code, so remember
     that high performance really starts with the quality of your basic
     system and the low level routines with which you construct your more
     magnificent creations.

     Remember that high level FORTH code is by nature very compact indeed
     and even an unexpanded Amiga A500 is a HUGE computer for a FORTH
     environment.  Forget traditional FORTH purist ideas concerning the
     "elegance" of managing complex tasks using a tiny array of words.

     Build yourself a really comprehensive set of fast software tools and
     indulge yourself in the luxury of a language to a large extent
     designed by you with your own specific needs in mind. Design your low
     level system well and your high level constructions will be fast and
     easy to write.

     ***************
     Further reading
     ***************

     We cannot here go into a full and detailed discussion of the actual
     coding and function of all the many standard FORTH words.  Many good
     FORTH textbooks are now available which cover this subject admirably,
     and two books by Leo Brodie, "Starting FORTH" and "Thinking FORTH",
     stand out as being particularly well-informed and instructive.