Re: [fpc-devel] Re: Porting FPC to IBM zArch
Am 19.08.2013 06:00, schrieb Paul Robinson:
I've been busy, I have other things I had to attend to, then I
realized I couldn't figure out what was going on without a decent
cross reference program, but nothing that's out there supports the
UNIT construct, nor do they know how to skip over {$DEFINE} {$IF}
{$ELSE}, and so I stopped to write one and I was busy with the work on
that. I'm having trouble there, so I set it aside.
I don't get what you're trying to say here.
Anyway, I came back and realized if I can get one of the Big Endian
ports working I can just figure out what files it uses and then edit
those to change the generated assembly language and/or the object
files if it makes object files the way the Pascal 8000 compiler for
the 370 from the Australian Atomic Energy Commission did back in the
late 1970s and early 1980s did.
Analyzing what a big-endian compiler generates won't help you there. You
need to look into the compiler's code and learn how it does generate
code for a specific platform. That has nothing to do with big endian or
little endian.
In FPC there is the frontend which generates a sort of abstract syntax
tree on which then the platform specific backend generates code. Thereby
the backend provides platform specific nodes for that abstract syntax
tree of which then the "generate_code" method is invoked. Platform
independant stuff is normally located in the ncg*.pas units and the
platform specific stuff is in the nXY*.pas unit of the corresponding CPU
directory where XY is a short form of the CPU, e.g. n68kadd.pas for the
m68k add/compare node. Best is you look how other CPUs are implemented
(prefereably the simpler ones like MIPS or m68k) and copy that more or
less for the new platform.
Adding a new platform to FPC is not cheesecake and you should know how
the compiler's backend work. Just looking at the output of a target
won't help you!
There are two things I'd like to find out to determine how it might be
possible to get Free Pascal ported to the s370 series.
First, I want to add some of the compiler flags I mention in the
description of my attempts on the WIKI to add the s370 and/or zSystem
architecture, how do I get those flags - they do not break the build -
added as hooks to the compiler sources so that eventually a {$DEFINE
S370} statement can be added to get the compiler to build itself for
the 370 (and possibly other defines depending on the machine and OS
target}? There will eventually need a new directory for the files that
the 370 and whatever OSs it uses supports, but, again, that's months
away. I have to start over, and I have to start somewhere.
First step is to get a cross compiler to s370/zSystem working so that
simple programs can be compiled which you can use to implement the RTL.
Only when enough of the RTL is implemented and the code generator works
good enough then you can try to cross compile the compiler, but not earlier.
So how would I get the constants and values added to include the s370
as a target for FPC? Would I submit them as a bug fix request as a
patch through bugs.freepascal.org on Mantis or something else? I want
to reserve a definition number for that processor, at least for now so
it has a fixed identifier so eventually it can have its own PPU files
and everything else in the toolchain.
Search the compiler's source for e.g. m68k to see how other platforms
are implemented.
Second, how do I create a cross-compiler that runs on Windows, for any
of the big-endian processors, so that I can see what it has to
generate code for the target machine? Given that, I can change the
code to either change the generated object file - if it does direct
object files - or the assembly language so it generates S370 assembly.
No. You should learn how the compiler generates code and then implement
a new code generator backend for s370, maybe based on a copy of another
platform. Playing around with the output won't help you.
I can then run the compiler through itself to create a cross-compiler
assembly for the 370. Then I can recompile the required modules, then
take the assemblies, assemble them with a 370 assembler, producing an
actual object module, then run the program against itself and the
compiler will at least compile itself. Having done that, I can then
create any necessary changes to implement anything needed to provide
the equivalent functionality and rebuild the toolchain so it is native
to the s370 and units to provide localized services can be created as
needed.
First step consists of cross compiled hello world programs to implement
and test the RTL. The compiler is much too complicated to get it running
at first.
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Porting FPC to IBM zArch
Am 19.08.2013 10:37, schrieb Sven Barth: > Adding a new platform to FPC is not cheesecake and you should know how > the compiler's backend work. Just looking at the output of a target > won't help you! A good start is aarch64: I tried to work in it as structured as possible to make it some draft for porting, so have a look at the history of fpc/compiler/aarch64 so you know how to start. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Porting FPC to IBM zArch
Florian Klämpfl wrote:
Am 19.08.2013 10:37, schrieb Sven Barth:
Adding a new platform to FPC is not cheesecake and you should know how
the compiler's backend work. Just looking at the output of a target
won't help you!
I'd hope that Paul isn't naive enough to make that mistake :-) On the
other hand, looking at how something like the MIPS compiler was put
together could probably be useful.
A good start is aarch64: I tried to work in it as structured as possible
to make it some draft for porting, so have a look at the history of
fpc/compiler/aarch64 so you know how to start.
Thanks for that, noted. Going back to some of Paul's points though: one
thing he's asking is how to get the fundamental hooks added to the
invariant part of FPC to allow the target-specific stuff to be put in
its own directory. What's best here: for developers to have their own
subversion (or equivalent) servers, or for a sandbox to be set up on the
public FPC SVN server?
Apropos Paul's comments of doing a good cross-reference and handling
compiler directives, I think the thing that is likely to give real
problems is the {$if defined() } form... I suppose that it would, at a
pinch, be possible to reconstitute the used source from assembler output
(-al -s options) but it's the worst kind of hack.
program testpreproc;
const a= 1;
var b: integer;
begin
{$if defined(a) }
b := 1
{$else }
b := 2
{$endif }
end.
# [5] var.b: integer;
# [7] begin
# [11] b := 2
# [13] end.
# [15]
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Porting FPC to IBM zArch
Mark Morgan Lloyd schrieb:
Apropos Paul's comments of doing a good cross-reference and handling
compiler directives, I think the thing that is likely to give real
problems is the {$if defined() } form...
I'm not sure whether $if defined() works with ordinary constants. The
$DEFINE and CONST identifiers most probably reside in different lists.
const a= 1;
var b: integer;
begin
{$if defined(a) }
This should work better:
{$if a=1 }
DoDi
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Porting FPC to IBM zArch
Hans-Peter Diettrich wrote:
Mark Morgan Lloyd schrieb:
Apropos Paul's comments of doing a good cross-reference and handling
compiler directives, I think the thing that is likely to give real
problems is the {$if defined() } form...
I'm not sure whether $if defined() works with ordinary constants. The
$DEFINE and CONST identifiers most probably reside in different lists.
const a= 1;
var b: integer;
begin
{$if defined(a) }
This should work better:
{$if a=1 }
I think you're right, but your correction doesn't detract from the point
that it is a slightly awkward "crossover case" where it is necessary to
do more than simply parse {$ (and, for most cases, (*$ ) lines. I can
only think of one other compiler implementation which did this sort of
thing, and that was TopSpeed/JPI.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Porting FPC to IBM zArch
Am 20.08.2013 13:52 schrieb "Hans-Peter Diettrich" :
>
> Mark Morgan Lloyd schrieb:
>
>
>> Apropos Paul's comments of doing a good cross-reference and handling
compiler directives, I think the thing that is likely to give real problems
is the {$if defined() } form...
>
>
> I'm not sure whether $if defined() works with ordinary constants. The
$DEFINE and CONST identifiers most probably reside in different lists.
"defined(identifier)" is only for identifiers which were added using
"$define", "-d..." or by the compiler itself. If you want to check for the
existence of a Pascal identifier use "declared(identifier)".
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
