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

[Marco van de Voort]

In our previous episode, Michael Schnell said:
> 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.

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

Because you haven't ported FPC to those architectures yet.

> 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

(... in a between coffees first order design sketch... Better check that
this also really the case in practice)

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

> Are there other than historical reasons that FPC is this 
> "self-contained" ? 

It started out on Dos, not Unix, and the early gcc's were pretty unusable.
At least I heard Florian say that once (and I can imagine)

Actually, using gcc on windows is still ackward to this day. Keep in mind
that you would have to maintain your own ecosystem of all those tools on
Windows.

Moreover, gcc is a moving target that goes through a major restructure every
few years. Keeping up is a chore. (see the many discussions on the GPC list
about moving to newer versions).

While the basic concept parser->IL->binary code remains the same, the border
conditions don't. Moreover, adding an additional architecture to such
fpc-gcc hybrid might still be a lot work, because of specific things in that
architecture that need to be fixed, worked around etc.

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

If I had to point a finger, then the handling and supportability is the main
reason. If I want to use a compiler, I want to use simply a compiler, not a
construction kit with twenty tools ranging from a generator to query my
system to a linker.