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