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

[Michael Schnell]

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

-Michael