[fpc-devel] Re. z370 Cross Compilation, Pass 2 of ....
bernd.oppolzer at t-online.de
Sun Sep 1 15:49:09 CEST 2013
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
as long as you don't want to do changes to step 2 (that is, change the
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
the z-Arch doesn't have PUSH and POP instructions, and I guess that the
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
Understanding that, I would now like to have some description of the
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
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
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
by relative offsets to the value of the "stack pointer". Simulating the
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
assembler representation) depending on the target platform - which is
in my opinion for performance reasons - or: should we stick with the
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
z Assembler Macros or a more intelligent assembler writer function which
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
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.
> fpc-devel maillist - fpc-devel at lists.freepascal.org
More information about the fpc-devel