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 - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
