[fpc-devel] Re. z370 Cross Compilation, Pass 2 of ....
jonas.maebe at elis.ugent.be
Sun Sep 1 16:12:12 CEST 2013
On 01 Sep 2013, at 15:49, Bernd Oppolzer wrote:
> Am 01.09.2013 12:26, schrieb Sven Barth:
>> 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)
> Thank you very much for that, that made things much clearer for me.
> So the compiler relies heavily on the external assembler and the syntax it supports,
> as long as you don't want to do changes to step 2 (that is, change the linear assembler
> representation, which IMO should not be done in the first step).
As Sven stated above, the linear assembler representation is completely independent of the external assembler and the syntax it supports.
> So here, I think, we have some problems or issues, because, as already pointed out,
> the z-Arch doesn't have PUSH and POP instructions, and I guess that the outcome
> of the linear assembler representation will not be very suitable to the things that the
> z-Arch instruction set provides, although in the meantime there are some 1500 instructions.
The compiler does not in any way rely on the presence of push and pop instructions.
> Understanding that, I would now like to have some description of the linear assembler
> representation that FPC generates, that is: it is of course not target-specific, but it does of
> course do some assumptions on the type of the underlying hardware. Maybe, for example,
> it assumes the existence of PUSH and POP instructions and some number of registers
> which can hold fixed point and floating point values and which are the target of the
> PUSH and POP instructions (and, of course, ASCII).
The JVM does not have any registers at all and is supported by the compiler.
> So my question is: is it possible to modify the outcome of step 2 (the linear
> assembler representation) depending on the target platform
The linear assembler representation is already 100% platform-specific (as Sven mentioned above). FPC does not have a platform-independent internal RTL (register transfer language) representation.
More information about the fpc-devel