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

[Bernd Oppolzer]

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).

And: the assembler is not called once, but for every unit.

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.

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 z-Arch Hardware, 
in contrast, normally
does not access parameters - for example - by issuing individual PUSH or 
POP instructions,
but - for example - if there are ten parameters requiring - say - 64 
bytes of storage,
it increments the "stack pointer" only once (by 64) and accesses the 
parameters
by relative offsets to the value of the "stack pointer". Simulating the 
individual
PUSHs and POPs by Assembler macros would by possible, but it would be a
waste of time.

So my question is: is it possible to modify the outcome of step 2 (the 
linear
assembler representation) depending on the target platform - which is 
desirable
in my opinion for performance reasons - or: should we stick with the 
outcome
of step 2 - which contains probably PUSH and POP instructions in gas 
syntax etc -
and simply try to convert them in the one or other way to z-Arch 
instructions -
z Assembler Macros or a more intelligent assembler writer function which 
converts
gas syntax to z Assembler syntax - and accept the performance degradation
in the first place?

BTW: is it possible to print the linear assembler representation - the 
outcome of step 2 -
which in my understanding is NOT target-specific - and compare it - for 
example - to
the assembler code generated for MIPS? I believe that from that mapping 
there could
indeed be learned something ...


>
> 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.

I, too, would try to rely on existing assemblers and linkers,
but I have the feeling that HLASM (or free Assemblers supporting
the z-Arch vocabulary) is a better choice than gas. I believe that
there are some people out there waiting for FPC being available
on z-Arch, and they are not all Unix-aware, but they read and
understand the classical z-machinery well and would like it,
if FPC was available there, without additional prerequisites
(from their point of view).

Of course, providing an internal assembler/linker is too much
work and even not necessary, in my opinion.

>
> Regards,
> Sven
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>