[fpc-devel] Why is FPC so self-contained ?

Jonas Maebe jonas.maebe at elis.ugent.be
Tue Nov 4 10:17:43 CET 2008

On 04 Nov 2008, at 10:01, Michael Schnell wrote:

> I could imagine a system that only provides a Pascal-to-RTL-parser  
> and uses many of the GNU tools (preprocessor <optionally>,  
> optimizer, code generator, linker, make).

FPC-generated object files can already be integrated with the GNU  
linker and make. A preprocessor has no place anymore (optional or not)  
once you have parsed and generated some form of intermediate code.  
Running a C preprocessor on the initial Pascal code could create quite  
unexpected errors, since the tokens recognised by the C preprocessor  
have no special meaning in Pascal and can thus appear anywhere.

As for using the gcc code generators and optimisers: gcc's ability to  
use gimple as input is quite new (can it actually already do that?  
afaik it's still a work-in-progress as part of its whole program  
optimisation infrastructure). Before that, to use the rest of the gcc  
infrastructure you would have to integrate the gcc backend into your  
compiler (as gpc has done). That really is an enormous job and  
requires constant updating every time a new gcc version is released.

> Are there other than historical reasons that FPC is this "self- 
> contained" ? (I suppose compiling speed is an issue here, so a "GCC  
> compatible parser" might only be an additional tool provided by the  
> FPC team, but I'd really love to use this for my embedded projects.)

The main reasons are
1) all people working on FPC are primarily Pascal programmers, and  
hence prefer programming in Pascal
2) a number of FPC's core developers are very averse to external  
dependencies for various reasons


More information about the fpc-devel mailing list