This is Info file gforth.info, produced by Makeinfo version 1.68 from
the input file gforth.texi.

INFO-DIR-SECTION GNU programming tools
START-INFO-DIR-ENTRY
* Gforth: (gforth).             A fast interpreter for the Forth language.
END-INFO-DIR-ENTRY

   This file documents Gforth 0.4.0

   Copyright (C) 1995-1998 Free Software Foundation, Inc.

   Permission is granted to make and distribute verbatim copies of
this manual provided the copyright notice and this permission notice
 are preserved on all copies.

   Permission is granted to copy and distribute modified versions of
this      manual under the conditions for verbatim copying, provided
also that the      sections entitled "Distribution" and "General Public
License" are      included exactly as in the original, and provided
that the entire      resulting derived work is distributed under the
terms of a permission      notice identical to this one.

   Permission is granted to copy and distribute translations of this
manual      into another language, under the above conditions for
modified versions,      except that the sections entitled
"Distribution" and "General Public      License" may be included in a
translation approved by the author instead      of in the original
English.


File: gforth.info,  Node: Fully Relocatable Image Files,  Next: Stack and Dictionary Sizes,  Prev: Data-Relocatable Image Files,  Up: Image Files

Fully Relocatable Image Files
=============================

   These image files have relocatable data addresses, and tokens for
code addresses. They can be used with different binaries (e.g., with and
without debugging) on the same machine, and even across machines with
the same data formats (byte order, cell size, floating point format).
However, they are usually specific to the version of Gforth they were
created with. The files `gforth.fi' and `kernl*.fi' are fully
relocatable.

   There are two ways to create a fully relocatable image file:

* Menu:

* gforthmi::            The normal way
* cross.fs::                    The hard way


File: gforth.info,  Node: gforthmi,  Next: cross.fs,  Prev: Fully Relocatable Image Files,  Up: Fully Relocatable Image Files

`gforthmi'
----------

   You will usually use `gforthmi'. If you want to create an image FILE
that contains everything you would load by invoking Gforth with `gforth
OPTIONS', you simply say
     gforthmi FILE OPTIONS

   E.g., if you want to create an image `asm.fi' that has the file
`asm.fs' loaded in addition to the usual stuff, you could do it like
this:

     gforthmi asm.fi asm.fs

   `gforthmi' works like this: It produces two non-relocatable images
for different addresses and then compares them. Its output reflects
this: first you see the output (if any) of the two Gforth invocations
that produce the nonrelocatable image files, then you see the output of
the comparing program: It displays the offset used for data addresses
and the offset used for code addresses; moreover, for each cell that
cannot be represented correctly in the image files, it displays a line
like the following one:

          78DC         BFFFFA50         BFFFFA40

   This means that at offset $78dc from `forthstart', one input image
contains $bffffa50, and the other contains $bffffa40. Since these cells
cannot be represented correctly in the output image, you should examine
these places in the dictionary and verify that these cells are dead
(i.e., not read before they are written).

   There are a few wrinkles: After processing the passed OPTIONS, the
words `savesystem' and `bye' must be visible. A special doubly indirect
threaded version of the `gforth' executable is used for creating the
nonrelocatable images; you can pass the exact filename of this
executable through the environment variable `GFORTHD' (default:
`gforth-ditc'); if you pass a version that is not doubly indirect
threaded, you will not get a fully relocatable image, but a
data-relocatable image (because there is no code address offset).


File: gforth.info,  Node: cross.fs,  Prev: gforthmi,  Up: Fully Relocatable Image Files

`cross.fs'
----------

   You can also use `cross', a batch compiler that accepts a Forth-like
programming language. This `cross' language has to be documented yet.

   `cross' also allows you to create image files for machines with
different data sizes and data formats than the one used for generating
the image file. You can also use it to create an application image that
does not contain a Forth compiler. These features are bought with
restrictions and inconveniences in programming. E.g., addresses have to
be stored in memory with special words (`A!', `A,', etc.) in order to
make the code relocatable.


File: gforth.info,  Node: Stack and Dictionary Sizes,  Next: Running Image Files,  Prev: Fully Relocatable Image Files,  Up: Image Files

Stack and Dictionary Sizes
==========================

   If you invoke Gforth with a command line flag for the size (*note
Invoking Gforth::.), the size you specify is stored in the dictionary.
If you save the dictionary with `savesystem' or create an image with
`gforthmi', this size will become the default for the resulting image
file. E.g., the following will create a fully relocatable version of
gforth.fi with a 1MB dictionary:

     gforthmi gforth.fi -m 1M

   In other words, if you want to set the default size for the
dictionary and the stacks of an image, just invoke `gforthmi' with the
appropriate options when creating the image.

   Note: For cache-friendly behaviour (i.e., good performance), you
should make the sizes of the stacks modulo, say, 2K, somewhat
different. E.g., the default stack sizes are: data: 16k (mod 2k=0); fp:
15.5k (mod 2k=1.5k); return: 15k(mod 2k=1k); locals: 14.5k (mod
2k=0.5k).


File: gforth.info,  Node: Running Image Files,  Next: Modifying the Startup Sequence,  Prev: Stack and Dictionary Sizes,  Up: Image Files

Running Image Files
===================

   You can invoke Gforth with an image file IMAGE instead of the
default `gforth.fi' with the `-i' flag (*note Invoking Gforth::.):
     gforth -i IMAGE

   If your operating system supports starting scripts with a line of the
form `#! ...', you just have to type the image file name to start
Gforth with this image file (note that the file extension `.fi' is just
a convention). I.e., to run Gforth with the image file IMAGE, you can
just type IMAGE instead of `gforth -i IMAGE'.

`#!'       -         gforth       ``hash-bang''
   an alias for `\'


File: gforth.info,  Node: Modifying the Startup Sequence,  Prev: Running Image Files,  Up: Image Files

Modifying the Startup Sequence
==============================

   You can add your own initialization to the startup sequence through
the deferred word

`'cold'       -         gforth       ``tick-cold''

   `'cold' is invoked just before the image-specific command line
processing (by default, loading files and evaluating (`-e') strings)
starts.

   A sequence for adding your initialization usually looks like this:

     :noname
         Defers 'cold \ do other initialization stuff (e.g., rehashing wordlists)
         ... \ your stuff
     ; IS 'cold

   You can make a turnkey image by letting `'cold' execute a word (your
turnkey application) that never returns; instead, it exits Gforth via
`bye' or `throw'.

   You can access the (image-specific) command-line arguments through
the variables `argc' and `argv'. `arg' provides conventient access to
`argv'.

`argc'       - addr         gforth       ``argc''
   contains the number of command-line arguments (including the command
name)

`argv'       - addr         gforth       ``argv''
   contains a pointer to a vector of pointers to the command-line
arguments (including the command-name). Each argument is represented as
a C-style string.

`arg'       n - addr count         gforth       ``arg''
   returns the string for the Nth command-line argument.

   If `'cold' exits normally, Gforth processes the command-line
arguments as files to be loaded and strings to be evaluated.  Therefore,
`'cold' should remove the arguments it has used in this case.


File: gforth.info,  Node: Engine,  Next: Binding to System Library,  Prev: Image Files,  Up: Top

Engine
******

   Reading this section is not necessary for programming with Gforth. It
may be helpful for finding your way in the Gforth sources.

   The ideas in this section have also been published in the papers
`ANS fig/GNU/??? Forth' (in German) by Bernd Paysan, presented at the
Forth-Tagung '93 and `A Portable Forth Engine' by M. Anton Ertl,
presented at EuroForth '93; the latter is available at
`http://www.complang.tuwien.ac.at/papers/ertl93.ps.Z'.

* Menu:

* Portability::
* Threading::
* Primitives::
* Performance::


File: gforth.info,  Node: Portability,  Next: Threading,  Prev: Engine,  Up: Engine

Portability
===========

   One of the main goals of the effort is availability across a wide
range of personal machines. fig-Forth, and, to a lesser extent, F83,
achieved this goal by manually coding the engine in assembly language
for several then-popular processors. This approach is very
labor-intensive and the results are short-lived due to progress in
computer architecture.

   Others have avoided this problem by coding in C, e.g., Mitch Bradley
(cforth), Mikael Patel (TILE) and Dirk Zoller (pfe). This approach is
particularly popular for UNIX-based Forths due to the large variety of
architectures of UNIX machines. Unfortunately an implementation in C
does not mix well with the goals of efficiency and with using
traditional techniques: Indirect or direct threading cannot be expressed
in C, and switch threading, the fastest technique available in C, is
significantly slower. Another problem with C is that it is very
cumbersome to express double integer arithmetic.

   Fortunately, there is a portable language that does not have these
limitations: GNU C, the version of C processed by the GNU C compiler
(*note Extensions to the C Language Family: (gcc.info)C Extensions.).
Its labels as values feature (*note Labels as Values: (gcc.info)Labels
as Values.) makes direct and indirect threading possible, its `long
long' type (*note Double-Word Integers: (gcc.info)Long Long.)
corresponds to Forth's double numbers(1). GNU C is available for free
on all important (and many unimportant) UNIX machines, VMS, 80386s
running MS-DOS, the Amiga, and the Atari ST, so a Forth written in GNU
C can run on all these machines.

   Writing in a portable language has the reputation of producing code
that is slower than assembly. For our Forth engine we repeatedly looked
at the code produced by the compiler and eliminated most
compiler-induced inefficiencies by appropriate changes in the source
code.

   However, register allocation cannot be portably influenced by the
programmer, leading to some inefficiencies on register-starved
machines. We use explicit register declarations (*note Variables in
Specified Registers: (gcc.info)Explicit Reg Vars.) to improve the speed
on some machines. They are turned on by using the configuration flag
`--enable-force-reg' (`gcc' switch `-DFORCE_REG'). Unfortunately, this
feature not only depends on the machine, but also on the compiler
version: On some machines some compiler versions produce incorrect code
when certain explicit register declarations are used. So by default
`-DFORCE_REG' is not used.

   ---------- Footnotes ----------

   (1) Unfortunately, long longs are not implemented properly on all
machines (e.g., on alpha-osf1, long longs are only 64 bits, the same
size as longs (and pointers), but they should be twice as long
according to *note Double-Word Integers: (gcc.info)Long Long.). So, we
had to implement doubles in C after all. Still, on most machines we can
use long longs and achieve better performance than with the emulation
package.


File: gforth.info,  Node: Threading,  Next: Primitives,  Prev: Portability,  Up: Engine

Threading
=========

   GNU C's labels as values extension (available since `gcc-2.0', *note
Labels as Values: (gcc.info)Labels as Values.)  makes it possible to
take the address of LABEL by writing `&&LABEL'.  This address can then
be used in a statement like `goto *ADDRESS'. I.e., `goto *&&x' is the
same as `goto x'.

   With this feature an indirect threaded NEXT looks like:
     cfa = *ip++;
     ca = *cfa;
     goto *ca;
   For those unfamiliar with the names: `ip' is the Forth instruction
pointer; the `cfa' (code-field address) corresponds to ANS Forths
execution token and points to the code field of the next word to be
executed; The `ca' (code address) fetched from there points to some
executable code, e.g., a primitive or the colon definition handler
`docol'.

   Direct threading is even simpler:
     ca = *ip++;
     goto *ca;

   Of course we have packaged the whole thing neatly in macros called
`NEXT' and `NEXT1' (the part of NEXT after fetching the cfa).

* Menu:

* Scheduling::
* Direct or Indirect Threaded?::
* DOES>::


File: gforth.info,  Node: Scheduling,  Next: Direct or Indirect Threaded?,  Prev: Threading,  Up: Threading

Scheduling
----------

   There is a little complication: Pipelined and superscalar processors,
i.e., RISC and some modern CISC machines can process independent
instructions while waiting for the results of an instruction. The
compiler usually reorders (schedules) the instructions in a way that
achieves good usage of these delay slots. However, on our first tries
the compiler did not do well on scheduling primitives. E.g., for `+'
implemented as
     n=sp[0]+sp[1];
     sp++;
     sp[0]=n;
     NEXT;
   the NEXT comes strictly after the other code, i.e., there is nearly
no scheduling. After a little thought the problem becomes clear: The
compiler cannot know that sp and ip point to different addresses (and
the version of `gcc' we used would not know it even if it was
possible), so it could not move the load of the cfa above the store to
the TOS. Indeed the pointers could be the same, if code on or very near
the top of stack were executed. In the interest of speed we chose to
forbid this probably unused "feature" and helped the compiler in
scheduling: NEXT is divided into the loading part (`NEXT_P1') and the
goto part (`NEXT_P2'). `+' now looks like:
     n=sp[0]+sp[1];
     sp++;
     NEXT_P1;
     sp[0]=n;
     NEXT_P2;
   This can be scheduled optimally by the compiler.

   This division can be turned off with the switch `-DCISC_NEXT'. This
switch is on by default on machines that do not profit from scheduling
(e.g., the 80386), in order to preserve registers.


File: gforth.info,  Node: Direct or Indirect Threaded?,  Next: DOES>,  Prev: Scheduling,  Up: Threading

Direct or Indirect Threaded?
----------------------------

   Both! After packaging the nasty details in macro definitions we
realized that we could switch between direct and indirect threading by
simply setting a compilation flag (`-DDIRECT_THREADED') and defining a
few machine-specific macros for the direct-threading case.  On the
Forth level we also offer access words that hide the differences
between the threading methods (*note Threading Words::.).

   Indirect threading is implemented completely machine-independently.
Direct threading needs routines for creating jumps to the executable
code (e.g. to docol or dodoes). These routines are inherently
machine-dependent, but they do not amount to many source lines. I.e.,
even porting direct threading to a new machine is a small effort.

   The default threading method is machine-dependent. You can enforce a
specific threading method when building Gforth with the configuration
flag `--enable-direct-threaded' or `--enable-indirect-threaded'. Note
that direct threading is not supported on all machines.


File: gforth.info,  Node: DOES>,  Prev: Direct or Indirect Threaded?,  Up: Threading

DOES>
-----

   One of the most complex parts of a Forth engine is `dodoes', i.e.,
the chunk of code executed by every word defined by a
`CREATE'...`DOES>' pair. The main problem here is: How to find the
Forth code to be executed, i.e. the code after the `DOES>' (the
DOES-code)? There are two solutions:

   In fig-Forth the code field points directly to the dodoes and the
DOES-code address is stored in the cell after the code address (i.e. at
`CFA cell+'). It may seem that this solution is illegal in the Forth-79
and all later standards, because in fig-Forth this address lies in the
body (which is illegal in these standards). However, by making the code
field larger for all words this solution becomes legal again. We use
this approach for the indirect threaded version and for direct
threading on some machines. Leaving a cell unused in most words is a
bit wasteful, but on the machines we are targeting this is hardly a
problem. The other reason for having a code field size of two cells is
to avoid having different image files for direct and indirect threaded
systems (direct threaded systems require two-cell code fields on many
machines).

   The other approach is that the code field points or jumps to the cell
after `DOES'. In this variant there is a jump to `dodoes' at this
address (the DOES-handler). `dodoes' can then get the DOES-code address
by computing the code address, i.e., the address of the jump to dodoes,
and add the length of that jump field. A variant of this is to have a
call to `dodoes' after the `DOES>'; then the return address (which can
be found in the return register on RISCs) is the DOES-code address.
Since the two cells available in the code field are used up by the jump
to the code address in direct threading on many architectures, we use
this approach for direct threading on these architectures. We did not
want to add another cell to the code field.


File: gforth.info,  Node: Primitives,  Next: Performance,  Prev: Threading,  Up: Engine

Primitives
==========

* Menu:

* Automatic Generation::
* TOS Optimization::
* Produced code::


File: gforth.info,  Node: Automatic Generation,  Next: TOS Optimization,  Prev: Primitives,  Up: Primitives

Automatic Generation
--------------------

   Since the primitives are implemented in a portable language, there
is no longer any need to minimize the number of primitives. On the
contrary, having many primitives has an advantage: speed. In order to
reduce the number of errors in primitives and to make programming them
easier, we provide a tool, the primitive generator (`prims2x.fs'), that
automatically generates most (and sometimes all) of the C code for a
primitive from the stack effect notation.  The source for a primitive
has the following form:

FORTH-NAME	STACK-EFFECT	CATEGORY	[PRONOUNC.]
[`""'GLOSSARY ENTRY`""']
C CODE
[`:'
FORTH CODE]

   The items in brackets are optional. The category and glossary fields
are there for generating the documentation, the Forth code is there for
manual implementations on machines without GNU C. E.g., the source for
the primitive `+' is:
     +    n1 n2 -- n    core    plus
     n = n1+n2;

   This looks like a specification, but in fact `n = n1+n2' is C code.
Our primitive generation tool extracts a lot of information from the
stack effect notations(1): The number of items popped from and pushed
on the stack, their type, and by what name they are referred to in the
C code. It then generates a C code prelude and postlude for each
primitive. The final C code for `+' looks like this:

     I_plus:	/* + ( n1 n2 -- n ) */  /* label, stack effect */
     /*  */                          /* documentation */
     {
     DEF_CA                          /* definition of variable ca (indirect threading) */
     Cell n1;                        /* definitions of variables */
     Cell n2;
     Cell n;
     n1 = (Cell) sp[1];              /* input */
     n2 = (Cell) TOS;
     sp += 1;                        /* stack adjustment */
     NAME("+")                       /* debugging output (with -DDEBUG) */
     {
     n = n1+n2;                      /* C code taken from the source */
     }
     NEXT_P1;                        /* NEXT part 1 */
     TOS = (Cell)n;                  /* output */
     NEXT_P2;                        /* NEXT part 2 */
     }

   This looks long and inefficient, but the GNU C compiler optimizes
quite well and produces optimal code for `+' on, e.g., the R3000 and the
HP RISC machines: Defining the `n's does not produce any code, and
using them as intermediate storage also adds no cost.

   There are also other optimizations, that are not illustrated by this
example: Assignments between simple variables are usually for free (copy
propagation). If one of the stack items is not used by the primitive
(e.g.  in `drop'), the compiler eliminates the load from the stack
(dead code elimination). On the other hand, there are some things that
the compiler does not do, therefore they are performed by `prims2x.fs':
The compiler does not optimize code away that stores a stack item to
the place where it just came from (e.g., `over').

   While programming a primitive is usually easy, there are a few cases
where the programmer has to take the actions of the generator into
account, most notably `?dup', but also words that do not (always) fall
through to NEXT.

   ---------- Footnotes ----------

   (1) We use a one-stack notation, even though we have separate data
and floating-point stacks; The separate notation can be generated
easily from the unified notation.


File: gforth.info,  Node: TOS Optimization,  Next: Produced code,  Prev: Automatic Generation,  Up: Primitives

TOS Optimization
----------------

   An important optimization for stack machine emulators, e.g., Forth
engines, is keeping  one or more of the top stack items in registers.
If a word has the stack effect IN1...INX `--' OUT1...OUTY, keeping the
top N items in registers
   * is better than keeping N-1 items, if X>=N and Y>=N, due to fewer
     loads from and stores to the stack.

   * is slower than keeping N-1 items, if X<>Y and X<N and Y<N, due to
     additional moves between registers.

   In particular, keeping one item in a register is never a
disadvantage, if there are enough registers. Keeping two items in
registers is a disadvantage for frequent words like `?branch',
constants, variables, literals and `i'. Therefore our generator only
produces code that keeps zero or one items in registers. The generated
C code covers both cases; the selection between these alternatives is
made at C-compile time using the switch `-DUSE_TOS'. `TOS' in the C
code for `+' is just a simple variable name in the one-item case,
otherwise it is a macro that expands into `sp[0]'. Note that the GNU C
compiler tries to keep simple variables like `TOS' in registers, and it
usually succeeds, if there are enough registers.

   The primitive generator performs the TOS optimization for the
floating-point stack, too (`-DUSE_FTOS'). For floating-point operations
the benefit of this optimization is even larger: floating-point
operations take quite long on most processors, but can be performed in
parallel with other operations as long as their results are not used.
If the FP-TOS is kept in a register, this works. If it is kept on the
stack, i.e., in memory, the store into memory has to wait for the
result of the floating-point operation, lengthening the execution time
of the primitive considerably.

   The TOS optimization makes the automatic generation of primitives a
bit more complicated. Just replacing all occurrences of `sp[0]' by
`TOS' is not sufficient. There are some special cases to consider:
   * In the case of `dup ( w -- w w )' the generator must not eliminate
     the store to the original location of the item on the stack, if
     the TOS optimization is turned on.

   * Primitives with stack effects of the form `--' OUT1...OUTY must
     store the TOS to the stack at the start.  Likewise, primitives
     with the stack effect IN1...INX `--' must load the TOS from the
     stack at the end. But for the null stack effect `--' no stores or
     loads should be generated.


File: gforth.info,  Node: Produced code,  Prev: TOS Optimization,  Up: Primitives

Produced code
-------------

   To see what assembly code is produced for the primitives on your
machine with your compiler and your flag settings, type `make engine.s'
and look at the resulting file `engine.s'.


File: gforth.info,  Node: Performance,  Prev: Primitives,  Up: Engine

Performance
===========

   On RISCs the Gforth engine is very close to optimal; i.e., it is
usually impossible to write a significantly faster engine.

   On register-starved machines like the 386 architecture processors
improvements are possible, because `gcc' does not utilize the registers
as well as a human, even with explicit register declarations; e.g.,
Bernd Beuster wrote a Forth system fragment in assembly language and
hand-tuned it for the 486; this system is 1.19 times faster on the
Sieve benchmark on a 486DX2/66 than Gforth compiled with `gcc-2.6.3'
with `-DFORCE_REG'.

   However, this potential advantage of assembly language
implementations is not necessarily realized in complete Forth systems:
We compared Gforth (direct threaded, compiled with `gcc-2.6.3' and
`-DFORCE_REG') with Win32Forth 1.2093, LMI's NT Forth (Beta, May 1994)
and Eforth (with and without peephole (aka pinhole) optimization of the
threaded code); all these systems were written in assembly language. We
also compared Gforth with three systems written in C: PFE-0.9.14
(compiled with `gcc-2.6.3' with the default configuration for Linux:
`-O2 -fomit-frame-pointer -DUSE_REGS -DUNROLL_NEXT'), ThisForth Beta
(compiled with gcc-2.6.3 -O3 -fomit-frame-pointer; ThisForth employs
peephole optimization of the threaded code) and TILE (compiled with
`make opt'). We benchmarked Gforth, PFE, ThisForth and TILE on a
486DX2/66 under Linux. Kenneth O'Heskin kindly provided the results for
Win32Forth and NT Forth on a 486DX2/66 with similar memory performance
under Windows NT. Marcel Hendrix ported Eforth to Linux, then extended
it to run the benchmarks, added the peephole optimizer, ran the
benchmarks and reported the results.

   We used four small benchmarks: the ubiquitous Sieve; bubble-sorting
and matrix multiplication come from the Stanford integer benchmarks and
have been translated into Forth by Martin Fraeman; we used the versions
included in the TILE Forth package, but with bigger data set sizes; and
a recursive Fibonacci number computation for benchmarking calling
performance. The following table shows the time taken for the benchmarks
scaled by the time taken by Gforth (in other words, it shows the speedup
factor that Gforth achieved over the other systems).

     relative      Win32-    NT       eforth       This-
       time  Gforth Forth Forth eforth  +opt   PFE Forth  TILE
     sieve     1.00  1.39  1.14   1.39  0.85  1.58  3.18  8.58
     bubble    1.00  1.31  1.41   1.48  0.88  1.50        3.88
     matmul    1.00  1.47  1.35   1.46  0.74  1.58        4.09
     fib       1.00  1.52  1.34   1.22  0.86  1.74  2.99  4.30

   You may find the good performance of Gforth compared with the systems
written in assembly language quite surprising. One important reason for
the disappointing performance of these systems is probably that they are
not written optimally for the 486 (e.g., they use the `lods'
instruction). In addition, Win32Forth uses a comfortable, but costly
method for relocating the Forth image: like `cforth', it computes the
actual addresses at run time, resulting in two address computations per
NEXT (*note Image File Background::.).

   Only Eforth with the peephole optimizer performs comparable to
Gforth. The speedups achieved with peephole optimization of threaded
code are quite remarkable. Adding a peephole optimizer to Gforth should
cause similar speedups.

   The speedup of Gforth over PFE, ThisForth and TILE can be easily
explained with the self-imposed restriction of the latter systems to
standard C, which makes efficient threading impossible (however, the
measured implementation of PFE uses a GNU C extension: *note Defining
Global Register Variables: (gcc.info)Global Reg Vars.).  Moreover,
current C compilers have a hard time optimizing other aspects of the
ThisForth and the TILE source.

   Note that the performance of Gforth on 386 architecture processors
varies widely with the version of `gcc' used. E.g., `gcc-2.5.8' failed
to allocate any of the virtual machine registers into real machine
registers by itself and would not work correctly with explicit register
declarations, giving a 1.3 times slower engine (on a 486DX2/66 running
the Sieve) than the one measured above.

   Note also that there have been several releases of Win32Forth since
the release presented here, so the results presented here may have
little predictive value for the performance of Win32Forth today.

   In `Translating Forth to Efficient C' by M. Anton Ertl and Martin
Maierhofer (presented at EuroForth '95), an indirect threaded version of
Gforth is compared with Win32Forth, NT Forth, PFE, and ThisForth; that
version of Gforth is 2%-8% slower on a 486 than the direct threaded
version used here. The paper available at
`http://www.complang.tuwien.ac.at/papers/ertl&maierhofer95.ps.gz'; it
also contains numbers for some native code systems. You can find a
newer version of these measurements at
`http://www.complang.tuwien.ac.at/forth/performance.html'. You can find
numbers for Gforth on various machines in `Benchres'.


File: gforth.info,  Node: Binding to System Library,  Next: Cross Compiler,  Prev: Engine,  Up: Top

Binding to System Library
*************************


File: gforth.info,  Node: Cross Compiler,  Next: Bugs,  Prev: Binding to System Library,  Up: Top

Cross Compiler
**************

   Cross Compiler

* Menu:

* Using the Cross Compiler::
* How the Cross Compiler Works::


File: gforth.info,  Node: Using the Cross Compiler,  Prev: How the Cross Compiler Works,  Up: Cross Compiler

Using the Cross Compiler
========================


File: gforth.info,  Node: How the Cross Compiler Works,  Next: Using the Cross Compiler,  Up: Cross Compiler

How the Cross Compiler Works
============================


File: gforth.info,  Node: Bugs,  Next: Origin,  Prev: Cross Compiler,  Up: Top

Bugs
****

   Known bugs are described in the file BUGS in the Gforth distribution.

   If you find a bug, please send a bug report to
<bug-gforth@gnu.ai.mit.edu>. A bug report should describe the Gforth
version used (it is announced at the start of an interactive Gforth
session), the machine and operating system (on Unix systems you can use
`uname -a' to produce this information), the installation options (send
the `config.status' file), and a complete list of changes you (or your
installer) have made to the Gforth sources (if any); it should contain
a program (or a sequence of keyboard commands) that reproduces the bug
and a description of what you think constitutes the buggy behaviour.

   For a thorough guide on reporting bugs read *Note How to Report
Bugs: (gcc.info)Bug Reporting.


File: gforth.info,  Node: Origin,  Next: Word Index,  Prev: Bugs,  Up: Top

Authors and Ancestors of Gforth
*******************************

Authors and Contributors
========================

   The Gforth project was started in mid-1992 by Bernd Paysan and Anton
Ertl. The third major author was Jens Wilke.  Lennart Benschop (who was
one of Gforth's first users, in mid-1993) and Stuart Ramsden inspired us
with their continuous feedback. Lennart Benshop contributed
`glosgen.fs', while Stuart Ramsden has been working on automatic
support for calling C libraries. Helpful comments also came from Paul
Kleinrubatscher, Christian Pirker, Dirk Zoller, Marcel Hendrix, John
Wavrik, Barrie Stott, Marc de Groot, and Jorge Acerada. Since the
release of Gforth-0.2.1 there were also helpful comments from many
others; thank you all, sorry for not listing you here (but digging
through my mailbox to extract your names is on my to-do list).

   Gforth also owes a lot to the authors of the tools we used (GCC, CVS,
and autoconf, among others), and to the creators of the Internet: Gforth
was developed across the Internet, and its authors have not met
physically for the first 4 years of development.

Pedigree
========

   Gforth descends from bigFORTH (1993) and fig-Forth. Gforth and PFE
(by Dirk Zoller) will cross-fertilize each other. Of course, a
significant part of the design of Gforth was prescribed by ANS Forth.

   Bernd Paysan wrote bigFORTH, a descendent from TurboForth, an
unreleased 32 bit native code version of VolksForth for the Atari ST,
written mostly by Dietrich Weineck.

   VolksForth descends from F83. It was written by Klaus Schleisiek,
Bernd Pennemann, Georg Rehfeld and Dietrich Weineck for the C64 (called
UltraForth there) in the mid-80s and ported to the Atari ST in 1986.

   Henry Laxen and Mike Perry wrote F83 as a model implementation of the
Forth-83 standard. !! Pedigree? When?

   A team led by Bill Ragsdale implemented fig-Forth on many processors
in 1979. Robert Selzer and Bill Ragsdale developed the original
implementation of fig-Forth for the 6502 based on microForth.

   The principal architect of microForth was Dean Sanderson. microForth
was FORTH, Inc.'s first off-the-shelf product. It was developed in 1976
for the 1802, and subsequently implemented on the 8080, the 6800 and the
Z80.

   All earlier Forth systems were custom-made, usually by Charles Moore,
who discovered (as he puts it) Forth during the late 60s. The first full
Forth existed in 1971.

   A part of the information in this section comes from `The Evolution
of Forth' by Elizabeth D. Rather, Donald R. Colburn and Charles H.
Moore, presented at the HOPL-II conference and preprinted in SIGPLAN
Notices 28(3), 1993.  You can find more historical and genealogical
information about Forth there.

