[fpc-devel] FPC Branches

[Hans-Peter Diettrich]

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.

2. Preprocessor
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.

3. Parser
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 
FPC/Lazarus users.

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 
audience...

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.

DoDi