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

INFO-DIR-SECTION GNU programski alati
START-INFO-DIR-ENTRY
* GPC: (gpc).                     GNU Pascal prevodilac (compiler).
END-INFO-DIR-ENTRY
INFO-DIR-SECTION Pojedini alati
START-INFO-DIR-ENTRY
* GPC: (gpc)Pozivanje GPC-a.      GNU Pascal prevodilac (compiler).
END-INFO-DIR-ENTRY

   Ova datoteka dokumentira GPC prevodilac (engl. compiler).

   Copyright (c) 1998-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-hr.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-hr.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-hr.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-hr.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-hr.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-hr.info,  Node: Suradnici,  Next: Resursi,  Prev: Internals,  Up: Top

Autori i suradnici na GNU Pascal projektu.
******************************************

Jukka Virtanen
     izumio GNU Pascal u ožujku 1988, implementirao ISO-7185 i većinu
     ISO-10206 standarda, itd.

Dr. Peter Gerwinski (http://www.gerwinski.de/~peter/)
     dodao je Borland-Pascal korelirane i druge ekstenzije GNU Pascalu u
     ljeto 1995, prenio GPC na EMX platformu, radi na najvećem dijelu
     razvoja prevoditelja (engl. compiler) od 1996-e, napisao i održava
     WWW home page, održava GNU Pascal mailing listu, radi neke druge
     administrativne stvari itd.

Jan-Jaap van der Heijden
     prenio GPC na DJGPP platformu i na Microsoft Windows 95/NT, dodao
     ELF podršku u proljeće 1996, riješio mnogo problema konfiguracije
     i kompatibilnosti, kreirao GPC FAQ, itd.

Frank Heckenbach (http://fjf.gnu.de)
     ispočetka napisao i održava Run Time System od srpnja 1997,
     napisao je većinu standardnih jedinica (Unit) distribuiranih s
     GPC-om (uključujući jedinice za BP kompatibilnost), napisao velik
     broj test programa, održava GPC To-Do ("za napraviti") listu
     (*note To Do::) itd.

Prof. Abimbola A. Olowofoyeku ("The African Chief" - afrički poglavica) (http://www.bigfoot.com/~african_chief/)
     kreirao originalne verzije mnogih BP kompatibilnostnih jedinica u
     svibnju 1997, priložio kod drugim jedinicama i Run Time sistemu,
     pomogao prenošenju GPC-a i jedinica na Cygwin i mingw platforme,
     napisao izvjestan broj test programa, dodao Delphi-kompatibilnu
     `SysUtils' jedinicu (http://www.gnu-pascal.de/contrib/chief/), itd.

Nick Burrett
     ispravio neke bugove i počistio GPC u svibnju 1998, itd.

Matthias Klose
     integrirao je GPC u EGCS i Debian GNU/Linux u svibnju 1998,
     usavršio je proces instalacije, itd.

Dominik Freche
     poboljšao je i proširio GPC manual u kolovozu - rujnu 1999 i
     napisao je rutine za konverziju za Borland kompatibilne 6 bajtne
     brojeve s pomičnim zarezom (floating point numbers) u prosincu
     1999.

Alexey Volokhov
     poboljšao je performanse GPC-ove podrške za module/jedinice u
     lipnju 1997.

Bill Currie
     implementirao je dodatne Borland ekstenzije u GPC u srpnju 1997.

Eike Lange
     preveo je tekst GNU Pascal Coding Standards na njemački.

Mirsad Todorovac
     je preveo GPC dokumentaciju na hrvatski.

Russ Whitaker
     dopunio i održava GNU Pascal FAQ.  (*note FAQ::)

   Razvojni proces GNU Pascala ima mnoge koristi od nezavisnih
doprinosa (koji nisu dio GNU Pascal distribucije):

Anja Gerwinski
     postavila je stare arhive za GPC mailing listu, u rujnu 1999.

Berend de Boer
     napisao je mnogo korisne dokumentacije o Extended Pascalu u 1995.

Markus Gerwinski (http://www.gerwinski.de/~markus/)
     kreirao je crtež jednog Gnua s Blaise Pascal i pomogao dizajnu WWW
     home stranice u listopadu 1996.

Nicola Girardi
     priložio je GPC jedinicu
     (http://www.gnu-pascal.de/contrib/nicola/) za `svgalib' grafičku
     biblioteku funkcija (engl. library) za neke platforme u veljači
     2000.

Eike Lange
     priložio je jedinice (http://www.gnu-pascal.de/contrib/eike/) za
     pristup MySQL, GNU DBM i PostgreSQL bazama podataka u kolovozu
     2000, te jedinicu (sada dio GPC-a) i alate za internacionalizaciju
     od listopada do prosinca 2001.

Eike Lange i Nicola Girardi zajedno su doprinijeli skup
     Gtk jedinica (http://www.gnu-pascal.de/contrib/nicola/) od veljače
     do svibnja 2001.

Nicola Girardi
     napisao je standarde za kodiranje u GNU Pascalu na engleskom. Eike
     Lange ih je preveo na njemački.

Prof. Phil Nelson
     kreirao je sustav za prijavu bugova za GPC u listopadu 1996.

Robert Hoehne (http://www.tu-chemnitz.de/~sho/rho/)
     napisao je RHIDE (http://www.tu-chemnitz.de/~rho/rhide.html),
     integriranu razvojnu okolinu za GNU prevoditelje koja se vrti pod
     DOS-om (DJGPP) i Linuxom, te dodao podršku za GNU Pascal u jesen
     1996.

Sven Hilscher
     napisao (pretežno) BP kompatibilnu `Graph' jedinicu za nekoliko
     platformi u prosincu 1996, sada dio GRX biblioteke
     (http://www.gnu.de/software/grx/).

Dario Anzani ("Predator Zeta") (http://www.geocities.com/SiliconValley/Vista/6573)
     priložio dokumentaciju o korištenju asemblera u GNU Pascalu u
     svibnju 1997.  (*note Assembler::)

Lluis de Yzaguirre i Maura
     postavio HTML verziju arhive GNU Pascal mailing listu, *Note
     Arhive mailing listi::, u rujnu 1997.

Dieter Schmitz
     postavio mailing listu na njemačkom jeziku za GPC, *Note Mailing
     List::, u ožujku 2001.

`(-:---------:-)'
     Ovo mjesto je rezervirano za _Vaše_ ime. ;-) Molimo kontaktirajte
     nas na GPC mailing listi, *Note Mailing List::, ako imate nešto
     interesantno za nas.

   Zahvaljujemo svima koji nas podržavaju prijavljujući bugove,
doprinoseći svojim znanjem i dobrim idejama, donacijama razvojnih
alata, dajući nam priliku da testiramo GPC na velikom broju različitih
sistema. Naročito smo dužnici (abecednim redom, najprije pojedinci)
prema

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, `BIP' na `University of
Birmingham', Velika Britanija, `Institut fuer Festkoerperforschung
(IFF)' na `Forschungszentrum Juelich', Njemačka, CARNet (Hrvatska
akademska i istraživačka mreža) i Akademija likovnih umjetnosti na
Sveučilištu u Zagrebu, Hrvatska.

kao i svima koje smo možda zaboravili spomenuti ovdje.  Hvala svima
vama!

   GNU Pascal se bazira na GNU CC-u Richarda Stallmana.  Nekoliko od
ljudi koji su doprinijeli GNU CC-u:

   * Ideja korištenja RTL-a i neke od ideja optimizacije su došle iz
     programa PO napisanog na University of Arizona od Jacka Davidsona
     i Christophera Frasera.  Vidi "Register Allocation and Exhaustive
     Peephole Optimization", Software Practice and Experience 14 (9),
     Sept. 1984, 857-866.

   * Paul Rubin je napisao veći dio preprocesora.

   * Leonard Tower je napisao dijelove parsera, RTL generator, i RTL
     definicije, te Vax deskripcije.

   * Ted Lemon je napisao dijelove RTL čitača i pisača.

   * Jim Wilson je implementirao 'loop strength reduction' i neke druge
     optimizacije petlji.

   * Nobuyuki Hikichi iz Software Research Associates, Tokyo, pridonio
     je podršku za Sony NEWS machine.

   * Charles LaBrec doprinio je podršku za Integrated Solutions 68020
     sistem.

   * Michael Tiemann iz Cygnus Support napisao je podršku za inline
     (umetnute) funkcije i 'instruction scheduling'.  Također i
     deskripcije National Semiconductor 32000 serije procesora, SPARC
     procesora i dijelom Motorola 88000.

   * Jan Stein iz Chalmers Computer Society je pružio podršku za Genix,
     kao i dijelove 32000 machine deskripcija.

   * Randy Smith je dovršio Sun FPA podršku.

   * Robert Brown je implementirao podršku za Encore 32000 sisteme.

   * David Kashtan iz SRI je prilagodio GNU CC za VMS.

   * Alex Crain je dodao promjene za 3b1.

   * Greg Satz i Chris Hanson su pomogli da GNU CC radi na HP-UX za
     9000 series 300 platformu.

   * William Schelter je napravio glavni dio posla na podršci za Intel
     80386.

   * Christopher Smith je prenio prevodilac na Convex strojeve.

   * Paul Petersen je napisao machine deskripcije za Alliant FX/8.

   * Dario Dariol je doprinio četiri varijacije primjera programa koji
     ispisuju vlastiti izvorni kod.

   * Alain Lichnewsky je prenio GNU CC na Mips procesor.

   * Devon Bowen, Dale Wiles i Kevin Zachmann su prenijeli GNU CC na
     Tahoe.

   * Jonathan Stone je napisao machine deskripcije za Pyramid computer.

   * Gary Miller je prenio GNU CC na Charles River Data Systems
     strojeve.

   * Richard Kenner s New York University Ultracomputer Research
     Laboratory je napisao machine deskripcije za AMD 29000, za DEC
     Alphu, za IBM RT PC, te za IBM RS/6000 kao i podršku za
     instrukcijske atribute.  Također je načinio izmjene kako bi se
     bolje podržalo RISC procesore uključujući izmjene u 'common
     subexpression elimination' (eliminacija zajedničkih pod-izraza),
     'strength reduction', 'function calling sequence' rukovanju, i
     'condition code support', uz dodatke za generalizacije koda za
     'frame pointer elimination'.

   * Richard Kenner i Michael Tiemann združeno su razvili reorg.c,
     'delay slot scheduler'.

   * Mike Meissner i Tom Wood iz Data General završili su prijenos na
     Motorolu 88000.

   * Masanobu Yuhara iz Fujitsu Laboratories implementirao je machine
     deskripcije za Tron architecture (točnije za Gmicro).

   * James van Artsdalen napisao je kod koji efikasno upotrebljava
     Intel 80387 register stack (registarski slog).

   * Mike Meissner iz Open Software Foundation dovršio je prijenos na
     MIPS procesor, uključujući dodavanje ECOFF debug podrške, i radio
     je prijenos na Intel 80386 procesor.

   * Ron Guilmette implementirao je `protoize' i `unprotoize' alate,
     podršku za Dwarf simboličke debugging informacije, i većinu
     podrške za System V Release 4.  Također je radio naporno na Intel
     386 i 860 podršci.

   * Torbjorn Granlund je implementirao multiply- i divide-by-constant
     optimizacije, poboljšao long long podršku, i poboljšao 'leaf
     function register allocation'.

   * Mike Stump je implementirao podršku za Elxsi 64-bitni procesor.

   * John Wehle je dodao machine deskripcije za Western Electric 32000
     procesor korišten u nekoliko strojeva 3b serije (nema veze s
     National Semiconductor 32000 procesorom).



File: gpc-hr.info,  Node: Resursi,  Next: Copying,  Prev: Suradnici,  Up: Top

Resursi za korištenje s GPC-om
******************************

   Mnogi od programa spomenutih ovdje, plus neki dodatni, mogu se naći
na
     `http://www.gnu-pascal.de/contrib/'

GNU Pascal crtež
----------------

   Na webu možete naći naš GNU Pascal crtež kao mali PNG, sa
(`GnuPascal-small-framed.png' on GPC's WWW home page) i bez okvira
(`GnuPascal-small.png' on GPC's WWW home page), kao jedna velika PNG
slika (10 KB) (`GnuPascal.png' on GPC's WWW home page) i kao jedna EPS
datoteka (45 KB) (`GnuPascal.eps' on GPC's WWW home page).

   Zbog patentnih problema (http://www.gnu.org/philosophy/gif.html) ne
koristimo GIF datoteke. Srećom PNG format (http://www.libpng.org),
nasljednik GIF-a, nema ovaj problem - i ionako uvodi bolju kompresiju i
više naprednih mogućnosti.

   Inače, kolor gradijent (`gradient.png' on GPC's WWW home page) sa
pozadine naše web stranice je PNG datoteka od samo 632 bajtova.
Generirana je Pascal programom prevedenim s GPC-om i `pnmtopng'.
[Example (gradient.pas)]

PENG
----

   PENG je integrirana razvojna okolina (IDE) za GNU prevodioce i
ostale svrhe na svakoj platformi koju podržava GPC, koju je napisao
Frank Heckenbach. Matična stranica za PENG je
     `http://fjf.gnu.de/peng/'.

RHIDE
-----

   RHIDE je integrirana razvojna okolina (IDE) za GNU prevodioce na
DOS-u (DJGPP) ili Linuxu, napisao ju je Robert Hoehne.  Matična
stranica RHIDE je
     `http://www.tu-chemnitz.de/~sho/rho/rhide.html'.

GRX
---

   GRX je grafička biblioteka za C i GNU Pascal, koja uključuje i
uglavnom BP kompatibilnu `Graph' jedinicu (unit). Raspoloživa je na
     `http://www.gnu.de/software/grx/'

   Iako je GRX potekao sa DJGPP, DOS programske platforme, prenosiva je
na Linux s SVGAlib, na sve Unix-olike sisteme koji vrte X11 window
system, i na MS-Windows 9x/NT.

Internacionalizacija
--------------------

   Jedinice i alati za internacionalizaciju su na raspolaganju na
     `http://www.gnu-pascal.de/contrib/eike/'

Jedinice (units) za baze podataka
---------------------------------

   GNU Pascal jedinice (units) za pristup MySQL, GNU DBM i PostgreSQL
bazama podataka se mogu naći na
     `http://www.gnu-pascal.de/contrib/eike/'

GTK jedinice
------------

   GNU Pascal jedinice za GTK+ i GTK+ GL biblioteke se mogu naći na
     `http://www.gnu-pascal.de/contrib/nicola/'

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

   Nicola Girardi je napisao jedinicu (unit) koja se može koristiti kao
interface (sučelje) prema Svgalib. Možete ju pronaći na
`http://www.gnu-pascal.de/contrib/nicola/'.

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

   Prof. Abimola A. Olowofoyeku ("The African Chief") je napisao
Delphi-kompatibilnu (iako neke značajke još uvijek nedostaju)
`SysUtils' jedinicu. Bila je testirana pod Cygwin, mingw, Linux
(Mandrake 7.0) i Solaris 7 platformama. Može se naći na
`http://www.gnu-pascal.de/contrib/chief/'.

Crystal, program za vođenje arhive mailing listi
------------------------------------------------

   Crystal je arhiva za mailing liste bazirana na webu, napisana za GNU
Pascal i korištena za arhive GPC mailing listi (*note Arhive mailing
listi::). Izvorni kod može se naći na `http://fjf.gnu.de/crystal/'

ISO standardi
-------------

   Specifikacije Pascal standarda su raspoložive u PostScript formatu na
     `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)

   Alternativne adrese su
     `ftp://ftp.europe.digital.com/pub/DEC/Pascal/'

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

   Postoje također i kopije na
     `http://www.employees.org/~samiam/iso7185.ps'
     (ISO-7185 Pascal)

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

   PRIMJEDBA: Ovi dokumenti su ponešto teži za pregledavanje (npr.  u
ghostview-u), jer im nedostaju tzv. "document structuring comments"
(DSC). GPC distribucija izvornog koda sadrži malu skriptu `ps2dsc' koja
dodaje DSC ponovno i čini dokumente lakšim za pregledavanje i
navigaciju. Primijetite da zbog copyright problema ćete vjerojatno to
moći učiniti samo za sebe i nećete moći distribuirati modificirane
datoteke.

   Možete naći lak za čitanje uvod u Extended Pascal od Prospero
Software-a na
     `http://www.prosperosoftware.com/epintro.html'

   Molimo vas primijetite da Standard Pascal *nije* isto što i Borland
Pascal niti njegov podskup. Pogledati poglavlje *Note Naglasci:: za
primjere mogućnosti Standard Pascala koje nedostaju u Borland Pascalu.

   ANSI-ISO Pascal FAQ (132 KB)
(http://www.employees.org/~samiam/ansiiso.faq) od Scott A. Moore-a
(http://www.employees.org/~samiam/) objašnjava razlike između dva
dijalekta u detalje.

Zaštitite svoju slobodu!
------------------------

   Programerske aktivnosti malih kompanija i pojedinaca su ugrožene
software-skim patentima. Ako ste programer, vi ste u opasnosti,
također! Vaš poslodavac ili vi možete biti tuženi od strane velike
kompanije koja drži patent na neke _ideje_ koje vi koristite u svojim
programima. (Nije potrebno da koristite tuđi kod da biste postali
podložni tim tužbama.)

   Za daljnje informacije pogledajte
     `http://lpf.ai.mit.edu/'

