[fpc-devel] FPC Branches
DrDiettrich1 at aol.com
Sun Jul 11 15:29:48 CEST 2010
I'm just curious, does there exist descriptions for the various SVN
branches (purpose, maintainer, state)?
Florian has offered me an new branch, for my parser etc. projects, but
he seems to be very busy right now. So I'll present a roadmap of my
activities, all around the parser and compiler:
1. New machine documentation
In an attempt to strip down a physical machine to the minimum
requirements, I've already created a no_cpu machine (based on M68K
units), and started to document the requirements. An early (FPC 2.4)
version of this project can be found in lazarus/examples/parser/, but it
(the new trunk version) should be moved into the FPC SVN - into
compiler/ or an add-on/contributions folder.
The stand-alone preprocessor code ($PreprocWrite, commandline option -m)
does not compile since a long time. I could it make work again, and
already supplied the according patch in Mantis.
I have a couple of ideas, how the compiler and parser could be made more
flexible, extensible and (possibly) more performant. In an first step I
try to become more familiar with the parser and the parser/compiler
framework. For that purpose I try to separate the syntactical and
semantical actions in the current pareser, by moving the semantical part
into subroutines. Later these subroutines can be moved into a dedicated
directory, or into include files, so that they can be exchanged like
currently machines can be exchanged, by adding their unit or include
directory to the searchpath. The functionality of the existing code is
*not* affected by this separation, but perhaps some improvements or
cleanup (of pending todo's) may find their way into the trunk as well.
This separation allows to reuse or extend the OPL parser/compiler in
further projects, *without* affecting the FPC code any more. A first
project may result in an (Lazarus) component, that allows to use the
*original* FPC OPL parser in other projects, as was the wish of several
Further projects could implement additional front-ends for FPC, for
other Wirthian languages (ISO-Pascal, Modula, Oberon...). These
front-ends only have to produce the same data structures as the OPL
parser does, so that the existing optimizers and machine code generators
can be used for the remaining stuff. My primary goal is the use of the
improved syntax of these languages, so that e.g. the choice of the
Modula syntax could stop the endless debates about the formatting of
begin-end blocks in source code. The use of the different semantics,
e.g. the garbage-collector in Oberon, or the implementation of the
according standard libraries, is beyond my intentions - but as long
according projects do not affect the existing FPC code, everybody can
start such projects freely :-)
The possibility of addional front-ends could turn FPC into an playground
for language designers of every kind, making FPC known to a much broader
I for my part see a chance to even implement a C front-end for FPC,
based on my ToPas code, see <http://sourceforge.net/projects/topas/>.
This way it would be possible to overcome the need for header
translations, for every target and after every new library release, and
also the immediate use of C code snippets or libraries in FPC projects
could become possible, without separate DLLs or other shared libraries.
Please let me know what you think about my ideas. I really would like to
see the beforementioned syntax/semantics separation in the trunk, once I
could implement it.
More information about the fpc-devel