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