This is ../p/doc/info/gpc.info, produced by makeinfo version 4.0 from
gpc.texi.

INFO-DIR-SECTION GNU programming tools
START-INFO-DIR-ENTRY
* GPC: (gpc).                   The GNU Pascal Compiler.
END-INFO-DIR-ENTRY
INFO-DIR-SECTION Individual utilities
START-INFO-DIR-ENTRY
* GPC: (gpc)Invoking GPC.       The GNU Pascal Compiler.
END-INFO-DIR-ENTRY

   This file documents the GNU Pascal Compiler.

   Copyright (C) 1988-2002 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 "GNU General Public License", "The GNU
Project", "The GNU Manifesto" and "Funding for Free Software" 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 "GNU General Public
License", "The GNU Project", "The GNU Manifesto" and "Funding for Free
Software" and this permission notice, may be included in translations
approved by the Free Software Foundation instead of in the original
English.


File: gpc.info,  Node: Tree nodes,  Next: Parameter passing,  Prev: Language definition,  Up: Internals

Tree Nodes
==========

   If you want really to understand how the GNU Pascal language
front-end works internally and perhaps want to improve the compiler, it
is important that you understand GPC's internal data structures.

   The data structure used by the language front-end to hold all
information about your Pascal program are the so-called "tree nodes".
(Well, it needn't be Pascal source - tree nodes are language
independent.) The tree nodes are kind of objects, connected to each
other via pointers. Since the GNU compiler is written in C and was
created at a time where nobody really thought about object-orientated
programming languages yet, a lot of effort has been taken to create
these "objects" in C.

   Here is an extract from the "object hierarchy". Omissions are marked
with "..."; nodes in parentheses are "abstract": They are never
instantiated and aren't really defined. They only appear here to
clarify the structure of the tree node hierarchy. The complete list is
in `../tree.def'; additional information can be found in `../tree.h'.

     (tree_node)
     |
     |--- error_mark  { enables GPC to continue after an error }
     |
     |--- (identifier)
     |    |
     |    |--- identifier_node
     |    |
     |    \--- op_identifier
     |
     |--- tree_list  { a list of nodes, also used as a
     |                  general-purpose "container object" }
     |
     |--- tree_vec
     |
     |--- block
     |
     |--- (type)  { information about types }
     |    |
     |    |--- void_type
     |    |
     |    |--- integer_type
     |   ...
     |    |
     |    |--- record_type
     |    |
     |    |--- function_type
     |    |
     |    \--- lang_type  { for language-specific extensions }
     |
     |--- integer_cst  { an integer constant }
     |
     |--- real_cst
     |
     |--- string_cst
     |
     |--- complex_cst
     |
     |--- (declaration)
     |    |
     |    |--- function_decl
     |   ...
     |    |
     |    |--- type_decl
     |    |
     |    \--- var_decl
     |
     |--- (reference)
     |    |
     |    |--- component_ref
     |   ...
     |    |
     |    \--- array_ref
     |
     |--- constructor
     |
     \--- (expression)
          |
          |--- modify_expr  { assignment }
          |
          |--- plus_expr  { addition }
         ...
          |
          |--- call_expr  { procedure/function call }
          |
          |--- goto_expr
          |
          \--- loop_expr  { for all loops }

   Most of these tree nodes - struct variables in fact - contain
pointers to other tree nodes. A `tree_list' for instance has a
`tree_value' and a `tree_purpose' slot which can contain arbitrary
data; a third pointer `tree_chain' points to the next `tree_list' node
and thus allows us to create linked lists of tree nodes.

   One example: When GPC reads the list of identifiers in a variable
declaration

     var
       foo, bar, baz: Integer;

   the parser creates a chain of `tree_list's whose `tree_value's hold
`identifier_node's for the identifiers `foo', `bar', and `baz'. The
function `declare_vars()' (declared in `util.c') gets this tree list as
a parameter, does some magic, and finally passes a chain of `var_decl'
nodes to the back-end.

   The `var_decl' nodes in turn have a pointer `tree_type' which holds
a `_type' node - an `integer_type' node in the example above. Having
this, GPC can do type-checking when a variable is referenced.

   For another example, let's look at the following statement:

     baz := foo + bar;

   Here the parser creates a `modify_expr' tree node. This node has two
pointers, `tree_operand[0]' which holds a representation of `baz', a
`var_decl' node, and `tree_operand[1]' which holds a representation of
the sum `foo + bar'. The sum in turn is represented as a `plus_expr'
tree node whose `tree_operand[0]' is the `var_decl' node `foo', and
whose `tree_operand[1]' is the `var_decl' node `bar'. Passing this (the
`modify_expr' node) to the back-end results in assembler code for the
assignment.

   If you want to have a closer look at these tree nodes, write a line
`{$debug-tree="Foobar"}' into your program with `FooBar' being some
identifier in your program. (Note the capitalization of the first
character in the internal representation.) This tells GPC to output the
`identifier_local_value' tree node - the meaning of this identifier -
to the standard error file handle in human-readable form.

   While hacking and debugging GPC, you will also wish to have a look
at these tree nodes in other cases. Use the `debug_tree()' function to
do so. (In fact `{$debug-tree="Foobar"}' does nothing else than to
`debug_tree()' the `identifier_local_value' of the `Foobar' identifier
node.)


File: gpc.info,  Node: Parameter passing,  Next: GPI files,  Prev: Tree nodes,  Up: Internals

Parameter Passing
=================

   GPC supports a lot of funny things in parameter lists: `protected'
and `const' parameters, strings with specified or unspecified length,
conformant arrays, objects as `var' parameters, etc. All this requires
sophisticated type-checking; the responsible function is
`convert_arguments()' in the source file `gpc-typeck.c'. Every detail
can be looked up from there.

   Some short notes about the most interesting cases follow.

*Conformant arrays:*
     First, the array bounds are passed (an even number of parameters of
     an ordinal type), then the address of the array itself.

*Procedural parameters:*
     These need special care because a function passed as a parameter
     can be confused with a call to the function whose result is then
     passed as a parameter. See also the functions
     `maybe_call_function()' and `probably_call_function()' in `util.c'.

*Chars:*
     According to ISO-10206 Extended Pascal, formal char parameters
     accept string values. GPC does the necessary conversion implicitly.
     The empty string produces a space.

*Strings and schemata:*
     Value parameter strings and schemata of known size are really
     passed by value. Value parameter strings and schemata of unknown
     size are passed by reference, and GPC creates temporary variable
     to hold a copy of the string.

*`const' parameters:*
     If a constant value is passed to a `const' parameter, GPC assigns
     the value to a temporary variable whose address is passed.
     Exception: Small types (whose size is known and not bigger than
     that of a pointer) as well as all integer, real and complex types
     are really passed by value.

*Typeless parameters:*
     These are denoted by `var foo' or `var foo: Void' and are
     compatible to C's `void *' parameters; the size of such entities
     is _not_ passed. Maybe we will change this in the future and pass
     the size for `var foo' parameters whereas `var foo: Void' will
     remain compatible to C. (Same with `const' instead of `var'.)

*`CString' parameters:*
     GPC implicitly converts any string value such that the address of
     the actual string data is passed and appends a `Chr (0)'
     terminator.


File: gpc.info,  Node: GPI files,  Next: AutoMake,  Prev: Parameter passing,  Up: Internals

GPI files - GNU Pascal Interfaces
=================================

   This section documents the mechanism how GPC transfers information
from the exporting modules and units to the program, module or unit
which imports (uses) the information.

   A GPI file contains a precompiled GNU Pascal interface.
"Precompiled" means in this context that the interface already has been
parsed (i.e. the front-end has done its work), but that no assembler
output has been produced yet.

   The GPI file format is an implementation-dependent (but not _too_
implementation-dependent ;-) file format for storing GNU Pascal
interfaces to be exported - Extended Pascal and PXSC module interfaces
as well as interface parts of Borland Pascal units compiled with GNU
Pascal.

   To see what information is stored in or loaded from a GPI file, run
GPC with an additional command-line option `--debug-gpi'. Then, GPC
will write a human-readable version of what is being stored/loaded to
the standard error file handle. (See also: *Note Tree nodes::.) *Note:*
This will usually produce _huge_ amounts of output!

   While parsing an interface, GPC stores the names of exported objects
in tree lists - in `gpc-parse.y', the bison (yacc) source of GPC's
parser, search for `handle_autoexport'. At the end of the interface,
everything is stored in one or more GPI files. This is called in
`gpc-parse.y' - search for `create_gpi_files'.  (See also: *Note
Language definition::, for an introduction to `gpc-parse.y')

   Everything else is done in module.c. There you can find the source
of `create_gpi_files()' which documents the file format: First, a
header of 33 bytes containing the string `GNU Pascal unit/module
interface' plus a newline.

   This is followed by an integer containing the "magic" value 12345678
(hexadecimal) to carry information about the endianness.  Note that,
though a single GPI file is always specific to a particular target
architecture, the host architecture (i.e., the system on which GPC
runs) can be different (cross-compilers).  Currently, GPC is not able
to convert endianness in GPI files "on the fly", but at least it will
detect and reject GPI files with the "wrong" endianness. "Integer" here
and in the following paragraphs means a `gpi_int' (which is currently
defined as `HOST_WIDE_INT').

   The rest of the GPI file consists of chunks. Each chunk starts with
a one-byte code that describes the type of the chunk. It is followed by
an integer that describes the size of the chunk (without this chunk
header). The further contents depend on the type, as listed below.

   For the numeric values of the chunk type codes, please refer to
`gpi.h'. Chunk types denoted with `(*)' must occur exactly once in a
GPI file. Other types may occur any number of times (including zero
times). The order of chunks is arbitrary. "String" here simply means a
character sequence whose length is the chunk's length (so no terminator
is needed).

`GPI_CHUNK_VERSION' (String) (*)
     The version of the GPI file which is the same as the GPC version.
     If `USE_GPI_DEBUG_KEY' is used (which will insert a "magic" value
     at the beginning of each node in the node table, see below, so
     errors in GPI files will be detected more reliably), ` D' is
     appended to this version string. (Currently, `USE_GPI_DEBUG_KEY'
     is used by default.) Furthermore, the GCC backend version is
     appended, since it also influences GPI files.

`GPI_CHUNK_MODULE_NAME' (String) (*)
     The name of the unit/module.

`GPI_CHUNK_SRCFILE' (String) (*)
     The name of the primary source file of the unit/module.

`GPI_CHUNK_IMPORT'
     The name of an interface imported by the current interface. This
     chunk consists of a string followed by the checksum of the imported
     interface's nodes, so the chunk length is the length of the string
     plus the size of an integer. Again, no terminator of the string is
     needed.

     The checksum is currently a simple weighted sum over the contents
     of the `GPI_CHUNK_NODES' chunk's contents (see below). This might
     be replaced in the future by a MD5 hash or something else more
     elaborate.

`GPI_CHUNK_LINK' (String)
     The name of a file to link.

`GPI_CHUNK_LIB' (String)
     The name of a library to link (prefixed with `-l').

`GPI_CHUNK_INITIALIZER' (String)
     The name of a module initializer. For technical reasons, any such
     chunk must come _after_ the `GPI_CHUNK_MODULE_NAME' chunk.

`GPI_CHUNK_GPC_MAIN_NAME' (String)
     A `gpc-main' option given in this interface. (More than one
     occurrence is pointless.)

`GPI_CHUNK_NODES' (*)
     The exported names and the objects (i.e., constants, data types,
     variables and functions) they refer to are internally represented
     as so-called _tree nodes_ as defined in the files `../tree.h' and
     `../tree.def' from the GNU compiler back-end. (See also: *Note
     Tree nodes::.) The names are stored as `IDENTIFIER_NODE's, their
     meanings as `IDENTIFIER_GLOBAL_VALUE's of these nodes.  The main
     problem when storing tree nodes is that they form a complicated
     tree in memory with a lot of circular references so the storing
     mechanism must make sure that nothing is stored multiple times.

     The functions `load_node()' and `store_node_fields()' do the main
     work of loading/storing the contents of a tree node with
     references to all its contained pointers in a GPI file. Each tree
     node has a `TREE_CODE' indicating what kind of information it
     contains. Each kind of tree nodes must be stored in a different way
     which is not described here. See the source of these functions for
     details.

     As most tree nodes contain pointers to other tree nodes,
     `load_node()' is an (indirectly) recursive function. Since this
     recursion can be circular (think of a record containing a pointer
     to a record of the same type), we must resolve references to tree
     nodes which already have been loaded. For this reason, all tree
     nodes loaded are kept in a table (see `mark_node_loaded()').

     On the other hand, for `store_node_fields()' the (seeming)
     recursion must be resolved to an iterative process so that the
     single tree nodes are stored one after another in the file, and not
     mixed together. This is the job of `store_tree()'. It uses a hash
     table (see `get_node_id()') for efficiency.

     When re-exporting (directly or indirectly) a node that was imported
     from another interface, and a later compiler run imports both
     interfaces, it must merge the corresponding nodes loaded from both
     interfaces. Otherwise it would get only similar, but not identical
     items. However, we cannot simply omit the re-exported nodes from
     the new interface in case a later compiler run imports only one of
     them.  The same problem occurs when a module exports several
     interfaces. In this case, a program that imports more than one of
     them must recognize their contents as identical where they overlap.

     Therefore, each node in a GPI file is prefixed (immediately before
     its tree code) with information about the interface it was
     originally imported from or stored in first. This information is
     represented as a reference to an `INTERFACE_NAME_NODE' followed by
     the id (as an integer) of the node in that interface. If the node
     is imported again and re-re-exported, this information is copied
     unchanged, so it will always refer to the interface the node was
     originally contained it. For nodes that appear in an interface for
     the first time (the normal case), a single 0 integer is stored
     instead of interface `INTERFACE_NAME_NODE' and id (for shortness,
     since this information is implicit).

     This mechanism is not applied to `INTERFACE_NAME_NODE's since
     there would be a problem when the identifier they represent is the
     name of the interface they come from; neither to
     `IDENTIFIER_NODE's because they are handled somewhat specially by
     the backend (e.g., they contain fields like
     `IDENTIFIER_GLOBAL_VALUE' which depend on the currently active
     declarations, so storing and loading them in GPI files would be
     wrong) because there is only one `IDENTIFIER_NODE' ever made for
     any particular name. But for the same reason, it is no problem
     that the mechanism can't be applied to them.

     `INTERFACE_NAME_NODE's are a special kind of tree nodes, only used
     for this purpose. They contain the name of the interface, the name
     of the module (to detect the unlikely case that different modules
     have interfaces of the same name which otherwise might confuse
     GPC), and the checksum of that interface. The latter may seem
     redundant with the checksum stored in the `GPI_CHUNK_IMPORT'
     chunk, but in fact it is not. On the one hand, `GPI_CHUNK_IMPORT'
     chunks occur only for interfaces imported directly, while the
     `INTERFACE_NAME_NODE' mechanism might also refer to interfaces
     imported indirectly. On the other hand, storing the checksum in
     the `GPI_CHUNK_IMPORT' chunks allows the automake mechanism to
     detect discrepancies and force recompilation of the imported
     module, whereas during the handling of the `GPI_CHUNK_NODES'
     chunk, the imported modules must already have been loaded. (It
     would be possible to scan the `GPI_CHUNK_NODES' chunk while
     deciding whether to recompile, but that would be a lot of extra
     effort, compared to storing the checksum in the `GPI_CHUNK_IMPORT'
     chunks.)

     Finally, at the end of the `GPI_CHUNK_NODES' chunk, a checksum of
     its own contents (excluding the checksum itself, of course) is
     appended. This is to detect corrupted GPI files and is independent
     of the other uses of checksums.

`GPI_CHUNK_OFFSETS' (*)
     An offset table for the tree nodes. Each node in a GPI file is
     assigned a unique id (which is stored as an integer wherever nodes
     refer to other nodes). There are some special tree nodes (e.g.,
     `integer_type_node' or `NULL_TREE') which are used very often and
     have fixed meanings. They have been assigned predefined ids, so
     they don't have to be stored in the GPI file at all. Their number
     and values are fixed (but may change between different GPC
     versions), see `special_nodes' in `module.c'.

     For the remaining nodes, the `GPI_CHUNK_NODES' table contains the
     file offsets as integers where they are stored within the (only)
     `GPI_CHUNK_NODES' chunk. The offsets are relative to the start of
     that chunk, i.e. after the chunk header. After the table (but
     still in this chunk) the id of the node that contains the list of
     all exported names is stored as an integer. (Currently, this is
     always the last node, but for the file format definition, this is
     not guaranteed.)

`GPI_CHUNK_IMPLEMENTATION'
     This chunk contains no data (i.e., its size must be 0). Its only
     purpose is to signal that the module implementation or the
     implementation part of the unit has been compiled. (Stored, but not
     used currently.)

   That's it. Now you should be able to "read" GPI files using GPC's
`--debug-gpi' option. There is also a utility `gpidump.pas' in the
`utils' directory to decode and show the contents of GPI files. It does
also some amount of integrity checking (a little more than GPC does
while loading GPI files), so if you suspect a problem with GPI files,
you might want to run `gpidump' on them, discarding its standard output
(it writes all error reports to standard error, of course).

   If you encounter a case where the loaded information differs too
much from the stored information, you have found a bug -
congratulations! What "too much" means, depends on the object being
stored in or loaded from the GPI file. Remember that the order things
are loaded from a GPI file is the _reversed_ order things are stored
when considering _different_ recursion levels, but the _same_ order
when considering the _same_ recursion level.


File: gpc.info,  Node: AutoMake,  Next: File Layout,  Prev: GPI files,  Up: Internals

GPC's AutoMake Mechanism - How it Works
=======================================

   When a program/module/unit imports (uses) an interface, GPC searches
for the GPI file (see *Note GPI files::) derived from the name of the
interface.

   Case 1: A GPI file was found.

   Each GPI file contains the name of the primary source file (normally
a `.pas' or `.p' file) of the module/unit, and the names of all
interfaces imported. GPC reads this information and invokes itself with
a command like

     gpc foo.pas -M -o foo.d

   This means: preprocess the file, and write down the name of the
object file and those of all its source files in `foo.d'. GPC reads
`foo.d' and looks if the object file exists and if the source was
modified since the creation of the object file and the gpi file. If so,
GPC calls itself again to compile the primary source file. When
everything is done, the `.d' file is removed.  If there was no need to
recompile, all interfaces imported by the module/unit are processed in
the same way as this one.

   Case 2: No GPI file was found.

   In this case, GPC derives the name of the source file from that of
the interface by trying first `interface.p', then `interface.pas'. This
will almost always work with Borland Pascal units, but not always with
Extended Pascal modules. The programmer can override this assumption
using `uses ... in' or `import ... in'.

   All this is done by the function `gpi_open()' which uses some
auxiliary functions such as `module_must_be_recompiled()' and
`compile_module()'.

   Each time an object file is compiled or recognized as being
up-to-date, its name is stored in a temporary file with the same base
name as all the other temporary files used by GPC but the extension
`.gpc'. When the top-level `gpc' is invoked (which calls `gpc1' later
on), it passes the name of this temporary file as an additional command
line parameter to `gpc1'. After compilation has been completed, the
top-level `gpc' reads the temporary file and adds the new object files
to the arguments passed to the linker.

   The additional command `--amtmpfile' (not to be specified by the
user!) is passed to child GPC processes, so all compiles use the same
temporary file.

   The source for this is merely in `module.c', but there are also some
hacks in `gpc.c', additional command line options in `lang-options.h'
and `gpc-decl.c', and `gpc-defs.h' contains declarations for the
functions and global variables.


File: gpc.info,  Node: File Layout,  Prev: AutoMake,  Up: Internals

Files that make up GPC; Integrating GNU Pascal in GCC
=====================================================

   *Note:* This is not up to date.

  1. The GNU back end (gbe). Used to convert RTL into asm. Supposed to
     be language independent. Files are in the `..' directory (i.e.,
     the directory called `gcc'). It also uses files in the `../config'
     subdirectories etc.

     Unfortunately, some of them are not completely language independent
     and need patching for GPC. This patch (against different GCC
     versions) is in the `diffs' subdirectory. It affects these files:

          convert.c
          dbxout.c
          expr.c
          fold-const.c
          function.c
          optabs.c
          stor-layout.c
          toplev.c

  2. Pascal language implementation files hacked from GCC source. In the
     ideal world, we would optimize them so much for Pascal that their
     GCC roots would no longer be recognizable. ;-) These files are in
     the Pascal directory (i.e., the one called `p') and are the
     following:

          gpc.c         (gcc.c)
          gpcpp.c       (cccp.c)
          gpc-common.c  (c-common.c)
          gpc-decl.c    (c-decl.c)
          lang.c        (c-lang.c)
          gpc-lex.c     (c-lex.c)
          gpc-typeck.c  (c-typeck.c)
          gpcspec.c     (g77spec.c from GNU Fortran)

     Some are even reused unmodified and are still in the GCC source
     directory (`..'):

          c-aux-info.c
          c-iterate.c
          c-pragma.c

  3. GPC sources written from scratch. They are in the Pascal directory.

          gpc-defs.h
          gpc-options.h
          gpc.gperf (generates hash.h)
          gpi.h
          lang-options.h
          module.[ch]
          objects.[ch]
          parse.y (generates parse.[ch])
          util.[ch]



File: gpc.info,  Node: Contributors,  Next: Resources,  Prev: Internals,  Up: Top

Contributors to GNU Pascal.
***************************

Jukka Virtanen
     invented GNU Pascal in March 1988, implemented the ISO-7185 and
     most of the ISO-10206 standard, etc.

Dr. Peter Gerwinski (http://www.gerwinski.de/~peter/)
     added Borland Pascal related and other extensions to GNU Pascal in
     summer 1995, ported GPC to EMX, does most of the development of the
     compiler since 1996, created and maintains the WWW home page,
     maintains the GNU Pascal mailing list, does some other
     administrative stuff, etc.

Jan-Jaap van der Heijden
     ported GPC to DJGPP and to Microsoft Windows 95/NT, added ELF
     support in spring 1996, solved a lot of configuration and
     compatibility problems, created the GPC FAQ, etc.

Frank Heckenbach (http://fjf.gnu.de)
     rewrote and maintains the Run Time System since July 1997, wrote
     most of the standard units distributed with GPC (including BP
     compatibility units), wrote a large number of test programs,
     maintains the GPC To-Do list (*note To Do::) etc.

Prof. Abimbola A. Olowofoyeku ("The African Chief") (http://www.bigfoot.com/~african_chief/)
     created the original versions of many BP compatibility units in May
     1997, contributed code to other units and the Run Time System,
     helped porting GPC and the units to Cygwin and mingw, wrote a
     number of test programs, contributed a Delphi-compatible `SysUtils'
     unit (http://www.gnu-pascal.de/contrib/chief/), etc.

Nick Burrett
     fixed some bugs and cleaned up GPC in May 1998, etc.

Matthias Klose
     integrated GPC into EGCS and Debian GNU/Linux in May 1998, improved
     the installation process, etc.

Dominik Freche
     improved and extended the GPC manual in August - September 1999 and
     wrote conversion routines for Borland compatible 6 Byte floating
     point numbers in December 1999.

Alexey Volokhov
     improved the performance of GPC's module/unit support in June 1997.

Bill Currie
     implemented more Borland extensions into GPC in July 1997.

Eike Lange
     translated the GNU Pascal Coding Standards into German.

Mirsad Todorovac
     translated the GPC documentation into Croatian.

Russ Whitaker
     updated and maintains the GNU Pascal FAQ.  (*note FAQ::)

   The development of GNU Pascal profits a lot from independent
contributions (which are not part of the GNU Pascal distribution):

Anja Gerwinski
     set up the old archives for the GPC mailing list, in September
     1999.

Berend de Boer
     wrote a lot of useful documentation about Extended Pascal in 1995.

Markus Gerwinski (http://www.gerwinski.de/~markus/)
     created the drawing showing a Gnu with Blaise Pascal and helped to
     design the WWW home page in October 1996.

Nicola Girardi
     contributed a GPC unit (http://www.gnu-pascal.de/contrib/nicola/)
     for the `svgalib' graphics library for some platforms in February
     2000.

Eike Lange
     contributed `http://www.gnu-pascal.de/contrib/eike/' to access
     MySQL, GNU DBM and PostgreSQL databases in August 2000, and a unit
     (now part of GPC) and tools for internationalization in October -
     December 2001.

Eike Lange and Nicola Girardi
     together contributed a set of GTK units
     (http://www.gnu-pascal.de/contrib/nicola/) in February - May 2001.

Nicola Girardi
     wrote the GNU Pascal Coding Standards in English. Eike Lange
     translated them to German.

Prof. Phil Nelson
     created a bug reporting system for GPC in October 1996.

Robert Hoehne (http://www.tu-chemnitz.de/~sho/rho/)
     wrote RHIDE (http://www.tu-chemnitz.de/~rho/rhide.html), an
     integrated development environment for GNU compilers running under
     Dos (DJGPP) and Linux, and added support for GNU Pascal in autumn
     1996.

Sven Hilscher
     wrote a mostly BP compatible `Graph' unit for several platforms in
     December 1996, now part of the GRX library
     (http://www.gnu.de/software/grx/).

Dario Anzani ("Predator Zeta") (http://www.geocities.com/SiliconValley/Vista/6573)
     contributed documentation about the use of assembler in GNU Pascal
     in May 1997.  (*note Assembler::)

Lluis de Yzaguirre i Maura
     set up a HTML version of the GNU Pascal mailing list archives,
     *Note Mailing List Archives::, in September 1997.

Dieter Schmitz
     set up a German mailing list for GPC, *Note Mailing List::, in
     March 2001.

`(-:---------:-)'
     This space is reserved for _your_ name. ;-) Please contact us at
     the GPC mailing list, *Note Mailing List::, if you have something
     interesting for us.

   We thank everybody who supports us by reporting bugs, contributing
knowledge and good ideas, donating development tools, and giving us the
opportunity to test GPC on a large variety of systems. We are
particularly indebted (in alphabetical order, individuals first) to

Sietse Achterop, Jawaad Ahmad, Montaz Ali, Jamie Allan, Strobe Anarkhos,
John P. R. Archer, Geoffrey Arnold, Steven J. Backus, Geoff Bagley, Uwe
Bauermann, Silvio a Beccara, Ariel Bendersky, Pablo Bendersky, John
Blakeney, Nicolas Bley, Philip Blundell, Preben Mikael Bohn,
Ernst-Ludwig Bohnen, Nils Bokermann, J. Booij, Patrice Bouchand, Jim
Brander, Matthias Braun, Marcus Brinkmann, Steve Brooker, Doug
Brookmann, J. David Bryan, Kev Buckley, Jason Burgon, Ricky W. Butler,
Dr. E. Buxbaum, Andrew Cagney, Loris Caren, Theo Carr-Brion, Fernando
Carrilho, Larry Carter, Fabio Casamatta, Janet Casey, Romain Chantereau,
Emmanuel Chaput, Jean-Pierre Chevillard, Carl Eric Codere,
Jean-Philippe Combe, Paolo Cortelli, F. Couperin, Nicolas Courtel,
Miklos Cserzo, Tim Currie, Serafim Dahl, Martin G. C. Davies, Stefan A.
Deutscher, Jerry van Dijk, Thomas Dunbar, Andreas Eckleder, Stephan
Eickschen, Sven Engelhardt, Klaus Espenlaub, Toby Ewing, Chuck B.
Falconer, Joachim Falk, Irfan Fazel, Carel Fellinger, Christopher
Ferrall, David Fiddes, Alfredo Cesar Fontana, Kevin A. Foss, Marius
Gedminas, Philip George, Nicholas Geovanis, Jose Oliver Gil, Jing
Gloria, Roland Goretzki, Morten Gulbrandsen, Kocherlakota Harikrishna,
Joe Hartley, Hans Hauska, Jakob Heinemann, Arvid Herzenberg, Thorsten
Hindermann, Honda Hirotaka, Stephen Hurd, Mason Ip, Daniel Jacobowitz,
Andreas Jaeger, David James, Nathalie Jarosz, Sven Jauring, Niels
Kristian Bech Jensen, Emil Jerabek, Johanna Johnston, Achim Kalwa,
Christine Karow, Tim Kaulmann, Thomas Keller, Clark Kent, Victor
Khimenko, Russell King, Niels Ole Staub Kirkeby, Prof. Donald E. Knuth,
Tomasz Kowaltowski, Peter Ulrich Kruppa, Jochen Kuepper, Casper ter
Kuile, Oliver Kullmann, Krzysztof Kwapien, Randy Latimer, Bernard Leak,
Olivier Lecarme, Wren Lee, Martin Liddle, Kennith Linder, Stephen
Lindholm, Orlando Llanes, Miguel Lobo, Benedict Lofstedt, Steve Loft,
John Logsdon, Maurice Lombardi, Dmitry S. Luhtionov, Jesper Lund,
Martin Maechler, Claude Marinier, Michael McCarthy, Michael Meeks,
Clyde Meli, Axel Mellinger, Jeff Miller, John Miller, Russell Minnich,
Rudy Moddemeijer, Jason Moore, Scott A. Moore, Jeffrey Moskot, Pierre
Muller, Adam Naumowicz, Andreas Neumann, Christian Neumann, Adam Oldham,
Gerhard Olejniczak, Alexandre Oliva, John G. Ollason, Marius Onica, Ole
Osterby, Klaus Friis Ostergaard, Jean-Marc Ottorini, Michael Paap,
Matija Papec, Miguel A. Alonso Pardo, Laurent Parise, Andris Pavenis,
Robert R. Payne, Opie Pecheux, Jose M. Perez, Ronald Perrella, Bjorn
Persson, Per Persson, Michael Pfeiffer, Pierre Phaneuf, Pascal Pignard,
Tam Pikey, Nuno Pinhao, Larry Poorman, Stuart Pope, Yuri Prokushev,
Huge Rademaker, Shafiek Rasdien, Mike Reid, Leon Renkema, John L. Ries,
Phil Robertson, Clive Rodgers, Jim Roland, Guillaume Rousse, Marten Jan
de Ruiter, Sven Sahle, Carl-Johan Schenstrom, Hartmut Schmider, Thomas
D. Schneider, Dominique Schuppli, Egbert Seibertz, George Shapovalov,
Richard Sharman, Patrick Sharp, Joe da Silva, Arcadio Alivio Sincero,
Ian Sinclair, Tomas Srb, Anuradha Srinivasan, David Starner, Andrew
Stribblehill, Alan Sun, Veli Suorsa, Mark Taylor, Paul Tedaldi, Robin
S. Thompson, Ian Thurlbeck, Gerhard Tonn, Ivan Torshin, Bernhard
Tschirren, Luiz Vaz, Tom Verhoeff, Kresimir Veselic, Alejandro
Villarroel, Bohdan Vlasyuk, Marco van de Voort, Raymond Wang, Nic Webb,
Peter Weber, Francisco Stefano Wechsler, Christian Wendt, Benedikt
Wildenhain, Gareth Wilson, Marc van Woerkom, David Wood, Michael
Worsley, Takashi Yamanoue, George L. Yang, Salaam Yitbarek, Dafi Yondra,
Eli Zaretskii, Gerhard Zintel, Mariusz Zynel, the `BIP' at the
`University of Birmingham', UK, the `Institut fuer Festkoerperforschung
(IFF)' at the `Forschungszentrum Juelich', Germany, CARNet (Croatian
Academic and Research NETwork) and the Academy of Fine Arts at the
University of Zagreb, Croatia,

and everybody we might have forgotten to mention here.  Thanks to all
of you!

   GNU Pascal is based on GNU CC by Richard Stallman.  Several people
have contributed to GNU CC:

   * The idea of using RTL and some of the optimization ideas came from
     the program PO written at the University of Arizona by Jack
     Davidson and Christopher Fraser.  See "Register Allocation and
     Exhaustive Peephole Optimization", Software Practice and
     Experience 14 (9), Sept. 1984, 857-866.

   * Paul Rubin wrote most of the preprocessor.

   * Leonard Tower wrote parts of the parser, RTL generator, and RTL
     definitions, and of the Vax machine description.

   * Ted Lemon wrote parts of the RTL reader and printer.

   * Jim Wilson implemented loop strength reduction and some other loop
     optimizations.

   * Nobuyuki Hikichi of Software Research Associates, Tokyo,
     contributed the support for the Sony NEWS machine.

   * Charles LaBrec contributed the support for the Integrated Solutions
     68020 system.

   * Michael Tiemann of Cygnus Support wrote the support for inline
     functions and instruction scheduling.  Also the descriptions of the
     National Semiconductor 32000 series cpu, the SPARC cpu and part of
     the Motorola 88000 cpu.

   * Jan Stein of the Chalmers Computer Society provided support for
     Genix, as well as part of the 32000 machine description.

   * Randy Smith finished the Sun FPA support.

   * Robert Brown implemented the support for Encore 32000 systems.

   * David Kashtan of SRI adapted GNU CC to VMS.

   * Alex Crain provided changes for the 3b1.

   * Greg Satz and Chris Hanson assisted in making GNU CC work on HP-UX
     for the 9000 series 300.

   * William Schelter did most of the work on the Intel 80386 support.

   * Christopher Smith did the port for Convex machines.

   * Paul Petersen wrote the machine description for the Alliant FX/8.

   * Dario Dariol contributed the four varieties of sample programs that
     print a copy of their source.

   * Alain Lichnewsky ported GNU CC to the Mips cpu.

   * Devon Bowen, Dale Wiles and Kevin Zachmann ported GNU CC to the
     Tahoe.

   * Jonathan Stone wrote the machine description for the Pyramid
     computer.

   * Gary Miller ported GNU CC to Charles River Data Systems machines.

   * Richard Kenner of the New York University Ultracomputer Research
     Laboratory wrote the machine descriptions for the AMD 29000, the
     DEC Alpha, the IBM RT PC, and the IBM RS/6000 as well as the
     support for instruction attributes.  He also made changes to
     better support RISC processors including changes to common
     subexpression elimination, strength reduction, function calling
     sequence handling, and condition code support, in addition to
     generalizing the code for frame pointer elimination.

   * Richard Kenner and Michael Tiemann jointly developed reorg.c, the
     delay slot scheduler.

   * Mike Meissner and Tom Wood of Data General finished the port to the
     Motorola 88000.

   * Masanobu Yuhara of Fujitsu Laboratories implemented the machine
     description for the Tron architecture (specifically, the Gmicro).

   * James van Artsdalen wrote the code that makes efficient use of the
     Intel 80387 register stack.

   * Mike Meissner at the Open Software Foundation finished the port to
     the MIPS cpu, including adding ECOFF debug support, and worked on
     the Intel port for the Intel 80386 cpu.

   * Ron Guilmette implemented the `protoize' and `unprotoize' tools,
     the support for Dwarf symbolic debugging information, and much of
     the support for System V Release 4.  He has also worked heavily on
     the Intel 386 and 860 support.

   * Torbjorn Granlund implemented multiply- and divide-by-constant
     optimization, improved long long support, and improved leaf
     function register allocation.

   * Mike Stump implemented the support for Elxsi 64 bit CPU.

   * John Wehle added the machine description for the Western Electric
     32000 processor used in several 3b series machines (no relation to
     the National Semiconductor 32000 processor).



File: gpc.info,  Node: Resources,  Next: Copying,  Prev: Contributors,  Up: Top

Resources For Use With GPC.
***************************

   Many of the programs mentioned here, plus some more, can be found at
     `http://www.gnu-pascal.de/contrib/'

GNU Pascal Drawing
------------------

   On the web you can find our GNU Pascal drawing as a small PNG file,
with (`GnuPascal-small-framed.png' on GPC's WWW home page) and without
a frame (`GnuPascal-small.png' on GPC's WWW home page), as a large PNG
image (10 KB) (`GnuPascal.png' on GPC's WWW home page), as an EPS file
(45 KB) (`GnuPascal.eps' on GPC's WWW home page), and as a PDF file (18
KB) (`GnuPascal.pdf' on GPC's WWW home page).

   Due to patent problems (http://www.gnu.org/philosophy/gif.html) we
do not use GIF files. Fortunately the PNG format
(http://www.libpng.org), the successor of GIF, does not have this
problem - and introduces better compression and more advanced features
anyway.

   By the way, the color gradient (`gradient.png' on GPC's WWW home
page) that makes our page background is a PNG file of only 632 bytes.
It was generated by a Pascal program compiled with GPC and `pnmtopng'.
[Example (gradient.pas)]

PENG
----

   PENG is an integrated development environment (IDE) for GNU
Compilers and other purposes on any platform supported by GPC, written
by Frank Heckenbach. The home page of PENG is
     `http://fjf.gnu.de/peng/'.

RHIDE
-----

   RHIDE is an integrated development environment (IDE) for GNU
Compilers on DOS (DJGPP) or Linux, written by Robert Hoehne. The home
page of RHIDE is
     `http://www.tu-chemnitz.de/~sho/rho/rhide.html'.

GRX
---

   GRX is a graphics library for C and GNU Pascal, including a mostly
BP compatible `Graph' unit. It is available from
     `http://www.gnu.de/software/grx/'

   Although GRX originated on DJGPP, a DOS programming platform, it is
portable to Linux with SVGAlib, to all Unix-like systems running the
X11 window system, and to MS-Windows 9x/NT.

Internationalization
--------------------

   Units and tools for internationalization are available in
     `http://www.gnu-pascal.de/contrib/eike/'

Database units
--------------

   GNU Pascal units to access MySQL, GNU DBM and PostgreSQL databases
are available in
     `http://www.gnu-pascal.de/contrib/eike/'

GTK units
---------

   GNU Pascal units for the GTK+ and GTK+ GL libraries are available in
     `http://www.gnu-pascal.de/contrib/nicola/'

Svgalib unit
------------

   Nicola Girardi wrote a unit which you can use to interface Svgalib.
You can find it at `http://www.gnu-pascal.de/contrib/nicola/'.

SysUtils unit
-------------

   Prof. Abimbola A. Olowofoyeku ("The African Chief") wrote a
Delphi-compatible (though a few routines are still missing) `SysUtils'
unit. It has been tested under Cygwin, mingw, Linux (Mandrake 7.0), and
Solaris 7. It can be downloaded from
`http://www.gnu-pascal.de/contrib/chief/'.

Crystal, a mailing list archive program
---------------------------------------

   Crystal is a web based mailing list archive, written for GNU Pascal
and used for the archives of GPC's mailing lists (*note Mailing List
Archives::). The source code can be found at
`http://fjf.gnu.de/crystal/'.

ISO standards
-------------

   The Pascal standard specifications are available in PostScript
format at
     `http://ftp.digital.com/pub/Digital/Pascal/iso10206_a4.ps.gz'
     (ISO-7185 Pascal)

     `http://ftp.digital.com/pub/Digital/Pascal/iso10206.ps.gz'
     (ISO-10206 Extended Pascal)

   Alternative addresses are
     `ftp://ftp.europe.digital.com/pub/DEC/Pascal/'

     `ftp://ftp.digital.com/pub/DEC/Pascal/'

   There are also copies at
     `http://www.employees.org/~samiam/iso7185.ps'
     (ISO-7185 Pascal)

     `http://www.employees.org/~samiam/iso10206.ps'
     (ISO-10206 Extended Pascal)

   Note: These documents are a bit hard to navigate (e.g., in
ghostview) because they are missing the so called "document structuring
comments" (DSC). The GPC source distribution contains a little script
`ps2dsc' to add the DSC again and make the documents easier to
navigate. Note that for reasons of copyright, you are probably only
allowed to do this for your own use and not to distribute the modified
files.

   You can find an easy-to-read introduction to Extended Pascal by
Prospero Software at
     `http://www.prosperosoftware.com/epintro.html'

   Please note that Standard Pascal is *not* the same as Borland Pascal
nor a subset of it. See *Note Highlights:: for examples of Standard
Pascal features that are missing in Borland Pascal.

   The ANSI-ISO Pascal FAQ (132 KB)
(http://www.employees.org/~samiam/ansiiso.faq) by Scott A. Moore
(http://www.employees.org/~samiam/) discusses the differences between
both dialects in detail.

Protect your freedom!
---------------------

   Programming activities of small companies and individuals are
threatened by software patents. If you are a programmer, you are in
danger, too! Your employer or yourself might be sued by a large company
holding a patent on some _ideas_ you are using in your programs. (You
need not use foreign code in order to become vulnerable.)

   For more information look at
     `http://lpf.ai.mit.edu/'

