[fpc-devel] z370 Cross Compilation, Pass 2 of ....
Based on information and belief, on Mon, 19 Aug 2013 10:37:43 +0200, Sven Barth pascaldra...@googlemail.com wrote to the Free Pascal list: I don't get what you're trying to say here. I mean I spent the better part of a year writing a cross-reference tool for Free Pascal since the compiler doesn't include one as they used to do (Mainframe and minicomputer Cobol, Fortran and Assembler all have built-in cross-reference as part of the compiler/assembler), then I had problems implementing a piece of it, so I realized that I'll come back to it at some time later, and right now I want to go back and try again with Free Pascal since I now know what I need to tackle. When I wasn't sure how to ask for what I knew I needed, I set this request aside to work on the cross-reference. I had to figure out what was going on and what I had to do. Analyzing what a big-endian compiler generates won't help you there. Possibly, but I have to start somewhere. 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. It does if the compiler generates object files directly (the way Pascal 8000 did on the 370, UCSD did, and Delphi does). If the compiler generates assembly language source files (the way OMSI Pascal did on the PDP-11 and the National Bureau of Standards Pascal Compiler did), then no, endianness probably won't matter. But I don't know from direct examination which FPC does, it's a huge application and I have no idea what all 100+ units and 264,000 lines of code do. I have to start somewhere and I have to take a guess. There are three possibilities. (I don't care what FPC does when it scans the program; that's all magic I probably don't have to worry about or deal with right now.) (1) The compiler, when it generates code, generates an intermediate output file processed by something else (Stanford Pascal, P4, P5, Java Compilers). (2) The compiler, when it generates code, generates an assembly language file (or possibly some other language) for the target that is passed to the Assembler (OMSI Pascal for the PDP-11). (3) The compiler, when it generates code, generates an actual object file and/or an executable (Pascal 8000, Turbo Pascal, Microsoft Pascal, Delphi). I know not which of these three Free Pascal does. 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. My spell checker says you spelled independent and preferably worng. :) Yeah, and I still have to figure out what compiler switches to set to enable the existing compiler to create a cross-compiler for that target that runs on Windows, and I'm asking for help on that point, because I figure someone might be able to tell me in 10 words which switches I need. The documentation is rather sparse on cross-compiling and the code is, well, to say the least, not very forthcoming. Adding a new platform to FPC is not cheesecake I'm fully aware of this, I'm not stupid and this is not the first compiler I've worked on, just the largest. I've written patches to six different Pascal compilers and I've written two compilers from scratch (not for Pascal), one was a Fortran IV to Visual Basic translator written in 7,000 lines of VB5, the other was a compiler I needed for a different purpose. I'm not someone who just fell off the turnip truck. I know there's (a lot of) work involved. I have to take a guess on where to start. Given an existing implementation, that I actually get it to work, I can then figure out what is being done, and from that, then I can figure out what files are being used and/or called, and what procedures/methods are invokes. And that's what I'm asking for help. What do I do to get one of the existing compilers that generates code for some other machine to run on Windows and when fed itself, have it generate an output file of the generated code of itself for that machine? Given that, I can then figure out what to look for. and you should know how the compiler's backend work. Just looking at the output of a target won't help you! It will a little. Seeing what is generated means I can look in the source code for where that is generated from, sort of the way the NSA, if it thinks you're calling a terrorist, it can search the billions of phone records it secretly seized to see who else you called! Given the generated output, I can (presumably) trace it back to whatever program file generated it and thus figure out what files were used. Going further, if necessary, I can insert procedure or unit traces on those files and see
[fpc-devel] FPC on z/System
I have written to The Lessons of history teach us - if they teach us anything - that no one learns the lessons that history teaches us. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: On a port of Free Pascal to the IBM 370
--- Begin Message ---
From: Paul Robinson
Sven Barth writes (edited for brevity):
It's not that I'm scared that you want to tackle this it's more that I've
seen that you based your How-To on assumptions
that are wrong or at least not good and wanted to help you in this regard.
That was part of the reason I started looking at this first, before formally
making an announcement. I wanted to see what kind of mess I was getting myself
into. This is not a trivial task and it's something I've wanted to do for
several years. I want to do this right, and it will take time. To quote from
some movie I can't remember, If it takes six months, it takes six months. If
it takes a year - or a year and a half - it takes that long.
Well, then let's get started with bringing you on track:
1. Also there were quite a few changes from 2.6.0 to 2.7.1 and thus it's
better to work with the most recent source.
I didn't know the sources were up to 2.7 already. I installed Tortoise SVN - I
was using Mercurial because that's what a different project is using, and I'm
an agnostic, so I'll use anyone's source code repository. I'm writing a
(fiction) book about life after death and I was using CVS for its releases I
think. So anyway, I used Tortoise SVN and retrieved the Compiler directory,
and (I just looked) PP doesn't mention what version it is, VERSION does, and it
says 2.6.0. I do want to keep a 2.6.0 branch to keep sources for the existing
compiler, I will find where the bleeding edge branch is and create a 2.7.1
version there.
2. I suggest you to use the Lazarus IDE to do compiler development
Once I found you can build console-mode apps using it I switched back to it.
Interesting with all the crapola to implement windows support, even console,
e.g. DOS WINDOW - applications are looking more and more like full Windows
ones. I've discovered that Lazarus has raised my standards in IDEs from the
dead (pun intentional!) It is an order of magnitude much easier to work with
than the Turbo Vision clone version. Since I found interest in including
cross-reference in the compiler to be less than lukewarm I decided to write an
external cross-reference program. One quick question which the manual doesn't
seem to answer, is whitespace allowed between { and $ in the case of {$INCLUDE
'X'}? I sometimes see it in some of the compiler sources and I'm not sure if
that's allowed or it is effectively 'diking out' the $ command. The manual
does not say one way or the other.
3. add unit i_i370 to the compiler unit and directory systems..
compiler unit .. OS .. not architecture. add a i_osvs1 to
that unit... first need the architecture support... corresponding CPU unit
... cputarg in the unit compiler. ...suggest you copy
the directory of an architecture... name that i370
As I've said, I'll take all the help I can get. Anything to make the work
easier is appreciated.
4. stumpled upon sysutils don't need to care ... yet. These are only
needed if you compile programs for the target platform ...
might want to stub System ... most important part .. real entry point
begin...end. in program NOT the real entry point,
this part is called PASCALMAIN and is called from within the real entry
point
This makes sense, when you run a compiled program usually you do not want to
start the program first, you want to start the run-time-library and have it,
after it's been initialized, to start the program.
That (PASCALMAIN) will have to change, the object file format for 370 machines
limits a CSECT to 8 characters, with the optional characters @ # and $. So I
might call it MAIN or possibly #MAIN. (On the PDP/11, most operating systems
(RT-11, RSTS/E, RSX) defined the main program in any language as .MAIN. )
So at the beginning you can mostly concentrate on your i370 directory with
adding some types here and there (like the assemblertype that you already
added).
might be best to first target Linux ... split into architecture support OS
support
I may-probably will - put it in at the same time but in stub form for the
reasons I stated above; I don't know Linux/370 and might not know why, if a
program doesn't work, why it doesn't. The first step is to at least generate
Hello World and have it actually execute on the target. Possibly insert
readln so I know it correctly reads and writes I/O. Then going on from
there. Plus - this is sort of a cheat - I have compiler sources that can tell
me how to implement some of the run-time library. Then I can go on and add
what Linux requires for this implementation vs. what it does on (I almost said
Windows!) I386 hardware or whatever has to be done.
Paul
The Lessons of history teach us - if they teach us anything - that no one
learns the lessons that history teaches us.
--- END MESSAGE---
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
[fpc-devel] Re: On a port of Free Pascal to the IBM 370
WITH message^Paul.Robinson DO BEGIN Mark Morgan LLoyd wrote: I've got reservations because of the EBCDIC issue. That's not a problem. You write a program on the 370, the machine does the internal conversion. Most people never notice the difference. The standard characters are the same in all versions of EBCDIC, the conversions for A-Z, a-z, 0-9, space and most symbols @!#$*()-+ etc. are pretty much cut and dried. I actually wrote an ASCII - -EBCDIC conversion to be able to view some text files from a mainframe PDS (their version of unix's tarball files) in order to understand what is going on. I'm sure Paul has his reasons that we all need to respect, but I don't think that using a 370 emulator (i.e. at least two architectures out of date) plus an obsolete operating system is the place to start. Again, I have to target what I know. A program written for the 370 will run on a 390. Having gotten the simpler version up and running, I can put other things in place and potentially add hooks later. If I have to learn the extensions for the 390 and how Linux/370 works, well, I guess I can probably add another 2 years on top of the conversion. I'd like potentially to see something running by Summer 2012, just in case Michel Nostradamus and the Aztecs were interpreted correctly and there'll be no tomorrow on December 22! (I'm going to be real upset if that happens, I just bought a five-year extension on my Magic Jack phone service before the price goes up.) I admit to having considered this as a long-term project, but what I don't have is a good understanding of the architecture's assembler-level programming. I've been updating the Wikibook (another one of Wikipedia's projects) on IBM 370-series assembler, just to remind myself of what was involved and to keep my skills sharp. Having gotten back into this I'm starting to remember things I'd forgotten. However I think I need to make the general point here that IBM Assembler is understood in the industry to encompass that which is needed to write application-level programs in CISC assembler plus macro support etc.), and that even somebody skilled in that particular black art might need to enter unfamiliar territory when it comes to the operations required by a compiler's code generation (e.g. commercial programming doesn't do large amounts of stack-relative addressing). They didn't tell us that at the time, but a lot of people did and didn't realize it. By convention, Register 13 is used by a called program as a save area to store the user's registers. If you're a subroutine (or if you prefer, you wrote a subroutine or wrote your program so that it would operate as one) the caller hands you R13 with an address of a 72-byte save area to store a spare word (used by Fortran and PL/I), plus all of the registers in the order 13-15 and 0-12 so you can return them as they were given to you and you don't have to worry about how you use them. So what some people did was use the register version of the OS/VS1 GETMAIN macro, which tells the operating system to return a block of storage space in register 1. Then they'd save the current value of register 13 at address 4 in this block, then put the block's address in R13. Just like doing a linked list. Now you have a place for any routines you might call to store your registers, plus, if you store your variables as offsets in register 13, you've created a stack to put your variables on and your program, since it uses no local writable memory, is fully reentrant and position independent. So you got it, you got a stack, reentrancy and PIC all for free and most of us who wrote code doing it that way never even knew it. Tomas Hajny wrote: Still, starting with the Linux for S/390 (or are S/390 and S/370 completely different animals?) Similar to the differences between Pentium and IAS-64, the 390 is a 64-bit version of the 370. probably a very good idea to avoid having to tackle both a different HW platform and a different OS at the same time (the Linux port to S/390 apparently uses ASCII according to what I found on Internet). Obviously, the OS may follow once the new HW platform is in working state. I may take a look at it, but I figured getting a Linux port was a substantial amount of work I didn't want to do right now; I have code I can use for the OS target I am using, I can know if it works or know why it doesn't. Not so for the 390 or for Linux. I can, conceivably include it as an option with it stubbed for the moment, then as I figure out how to implement the interface to it I can. Michael Schnell wrote: As for using Linux: I have no idea how this works in practice, so I can't comment on that. Which more-or-less makes two of us. I know that people here use Hercules inside linux to develop for zSeries, but then again running a linux inside that seems a bit like overkill I would disagree, it's
