[fpc-devel] Why is FPC so self-contained ?
mschnell at lumino.de
Tue Nov 4 10:01:59 CET 2008
Hi Compiler developers.
I do lots of software projects for PCs and for embedded devices.
While I do all PC projects (for Windows and Linux) in Object Pascal,
which is my favorite programming language as it offers the best
productivity and the lowest count on errors that show at runtime, I am
forced to use GCC for the embedded projects as the processors used here
(usually 68K, PIC and NIOS) are not supported by FPC.
Now I just took a somewhat deeper look at how the new 4.x versions of
GCC work and so the question comes up (again) why I can't use FPC for
the embedded software tasks.
GCC uses the "preprocessor" and the "parser" to create an intermediate
code (RTL: "Generic" or "Gimple"). This process is independent from the
target-architecture the code is to be compiled for. Now the RTL is
optimized and finally a target specific "code generator" produces the
object code which now is combined with other object code by the linker.
AFAIK FPC works quite similar, but while only the "parser" really knows
about the programming language, it comes with it's own preprocessor
(which is only used optionally), it's own code generator and it's own
linker. AFAIK, it even provides it's own "make" to compile multiple files.
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).
This would just provide another language for GCC and for hopefully allow
me to use FPC-Pascal for any processor architecture supported by GCC.
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.)
More information about the fpc-devel