[fpc-devel] Re. z370 Cross Compilation, Pass 2 of ....

[Sven Barth]

On 01.09.2013 05:19, Bernd Oppolzer wrote:
> And then: I have some doubts about the linkage between FPC and the GNU
> tools,
> like as and ld. Why is it easier to port FPC to a Linux based system?
> If the compiler translates into an abstract intermediate language first
> and then into an abstract assembly language maybe - for an abstract machine
> like the P-machine - then the nature of the assembler and linker used
> should be irrelevant. Maybe there is some misunderstanding on my - or
> our - part;
> I have the Wirth compilers in mind, and there is a clear separation between
> the machine independent parts - phase 1 - which generates P-code and
> the machine dependent parts - phase 2 and runtime. Even if there is no such
> separation in FPC, it should IMO be possible to develop and test the code
> generation separately.

If someone wants to port the compiler to a new target processor it is 
advisable to look whether there exists an OS that is already supported 
by FPC, because then "only" the code generator and the CPU specific 
parts of the RTL need to be implemented while the remaining RTL can be 
reused which simplifies the first steps of the port. Otherwise you'd 
need to implement the code generator and a more or less complete RTL.
So as Linux seems to be available at least for some variants of the CPU 
I would strongly suggest to target Linux first and other OSes later.

Also the compile process of FPC is roughly this:
- for each used unit:
     - parse the unit and generate a node tree for each 
procedure/function/method (basically platform independant)
     - generate a CPU specific linear assembler representation of each 
node tree (this representation is independant of the specific assembler 
used)
     - if an external assembler (e.g. GNU as) is used: convert the 
assembler lists to assembler files
     - call the assembler (internal assemblers work on the assembler 
lists directly) to generate the object file
- for external linkers (e.g. GNU ld): write a linkscript to instrument 
the external linker
- call the linker (internal linkers work directly on the in memory 
information the compiler has gathered)

For a new port it is advisable to not implement internal assemblers and 
linkers, because that means more work, but to use existing tools for the 
given platform. And here like for the RTL assembler/linker interfaces 
for the GNU assembler and linker already exist which simplify a port. 
Later on additional assembler/linker interfaces for other 
assemblers/linkers can be added or even an internal assembler and/or 
linker can be written.

Regards,
Sven