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
Jonas
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
