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.


Jonas

_______________________________________________
fpc-devel maillist  -  [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply via email to