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

[Sven Barth]

On 01.09.2013 20:21, Bernd Oppolzer wrote:
> As I understand it now, we have several levels of the compiler:
>
> a) scanning and parsing the source code, which leads to a "tree
> representation"
> of the units, which IMO is a kind of in-storage-representation of the
> source code
> (and tables etc.), without much dependencies of the target, if any. I
> don't think,
> that informations about available registers etc. of the target machine
> are necessary
> at this level.

Correct. There are only very few exceptions, e.g. on m68k-amiga you can 
use the "location" keyword to specify a register location for a 
parameter or the result value (whereby of course you need to know which 
registers are available).

> b) the "tree representation" is translated into a "linear assembly
> list", which is
> target specific; from previous posts it sounds as if there are generic
> methods
> which help with this, and those methods of course need information about
> the
> target platform - but there is no "intermediate language" at this stage
> like
> in the P-Code case. (I know of other compilers, namely the IBM commercial
> ones, which translate in this stage for an abstract target machine which
> has
> an arbitrary number of registers, and the later "real" code generator
> puts it
> down to the real number, for example 16, and the missing registers are
> simulated in storage). This needs to be examined more.

It looks like this: all nodes are classes that descend from the tnode 
class. E.g. for adding two values (ordinals or floats) there is the 
taddnode which descends from tbinarynode which in turn descends from 
tnode. This taddnode does the general type checking and often also 
determines whether the result will be passed in a register, as memory 
reference or whatever. Then there is the tcgaddnode which descends from 
taddnode and is either able to provide a platform independant 
implementation (not the case for taddnode) which uses the general 
interface of the code generator or at least provides a few platform 
specific helpers and splits the implementation up a bit (in this case 
tcgaddnode provides methods "second_addfloat", "second_cmpfloat", 
"second_addordinal", etc. which can be implemented by the platform 
specific node which is (in case of ARM) called tarmaddnode and is a 
descendant of tcgaddnode.
This node usually uses the platform specific taicpu to generate the 
abstract assembler instructions.

This seems a bit abstract at first, but with time you get a feeling for 
it...

> c) the "linear assembly list" is written to files, more or less without
> changes

Whereby the specified assembler writer is used.

> d) the files are assembled using an external assembler (in our case);
> it must be callable from the FPC compiler. There exists an interface for
> gas;
> interfaces to other assemblers have to be built.

gas is only one example. There are interfaces for a few other assemblers 
as well (mostly on i386, but e.g. on ppc-macos (Classic Mac OS) we use 
the Apple specific assembler tool)

> e) in the same way an external linker is used to link the units together.

Correct.

Regards,
Sven