On 01.09.2013 15:49, Bernd Oppolzer wrote:
Most points were already answered by Jonas, so I'll only tackle the
remaining ones:
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 ...
There is currently no way to write this linear assembler representation
as is. Only through the assembler writers they can be written.
The entries of that linear presentation are mostly located inside the
aasmtai.pas and $CPUTARGET/aasmcpu.pas units (each tai is one entry
inside the linear list) with one of the more important ones being taicpu
as this is the one which encapsulates the platform specific CPU
instructions.
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).
The point is still that one should choose Linux as a first target OS for
that new platform and thus the assembler must be supported there as
well. As GNU as is normally always there where there is a Linux this
would mean that for the first steps of the implementation no new
assembler writer needs to be implemented (though this isn't necessarily
rocket science). If HLASM supports assembling code for Linux you can of
course implement that as first.
My suggestion is however to only implement as few things as possible as
the first step which means "only" implementing the code generator and no
new RTL, no assembler writer and no linker interface. Later on once
Linux works good enough (not everything needs to be implemented for
this!) additional assembler writers or target OSes can be added. You are
working inside an unfamiliar environment (the compiler's code) and thus
you should it make yourself as easy as possible. Otherwise you might
experience frustration when doing this port...
Regards,
Sven
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
