Sven Barth wrote:
You wrote that you use the source code of FPC 2.6.0 and copied the "compiler" and "rtl" directories to some other "workplace". I suggest you to use a SVN checkout of the development version (you can find the links here: http://www.freepascal.org/develop.var (at "Connect to Source Repository with SVN")), because than you can more easily revert back something. 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.
Also there are things in trunk that aren't in released versions, for example when I started looking at MIPS I didn't appreciate that somebody (Florian?) had already backported much of David Zhang's (?) implementation.
I suggest you to use the Lazarus IDE to do compiler development (you might use the text mode IDE ("fp") as well, but I myself only use Lazarus for that). You can then copy one of the project files (*.lpi) in the compiler directory (e.g. ppi386.lpi) and paste it as "ppi370.lpi". You can then open this project in Lazarus and adjust the defines (in tab "Other" replace "-dI386" with "-dI370") and output directory (exchange "i386/units" with "i370/units") in the project settings. Afterwards you should be able to compile the compiler using (Ctrl+)F9 (ok, you won't at first, because you yet need to adjust the source for i370)
I definitely found Lazarus indispensable once I started stepping through part-working code to find out where it was going wrong, I was able to run MIPS and PPC side-by-side on a PC.
I noticed that you wanted to add a unit "i_i370" to the "compiler" unit and to the directory "systems". This is wrong. The units listed in the "compiler" unit are the target operating systems (e.g. Windows, Linux, DOS), not the underlying architecture. Thus you'd only add a "i_osvs1" (if I remember the name correctly) to that unit and directory, but you don't need to do this know as you first need to implement the architecture support. This architecture support is located in the corresponding CPU unit (e.g. ARM, PowerPC, i386, x86_64 (the latter two share the x86 directory as well)) and is included by using the "cputarg" in the unit "compiler". This unit is located in the corresponding CPU directory. Thus I'd suggest you to copy the directory of an architecture (e.g. MIPS as this is a smaller and younger one) and name that "i370" (now the unit output path I mentioned in "2" will make sense ;) ).
Perhaps now would be a good time for a core developer to add appropriate definitions to trunk, so that anybody working on the IBM port only needs to modify files in a directory off ./compiler.
MIPS is OK, but there are some defines etc. that need to be sorted out. I've done a bit of work on this but I think it needs somebody with more experience to sort out my fixes and commit them.
I myself can't help with porting FPC to a new architecture, as I haven't done that yet (only to a new operating system target). But AFAIK Mark Morgan Lloyd worked on the MIPS target and of course there are compiler developers who implemented new architectures.
Bearing in mind that what I was looking at was code that had already been working in version 1 of the compiler, which had been massaged into some sort of shape for v2. I can claim very little credit, it was entirely "grunt work". More relevant might be Jonas's recent work targeting the JVM, but I suspect that the "classic" IBM mainframe architecture is probably nearer MIPS or 68K than to JVM or a modern RISC.
Historical note: I worked for a mainframe manufacturer in the early 80s after getting my first degree, so while I'm not intimate with the S/360...zSeries range I think I've got a bit of relevant experience. The important thing to appreciate is that at least some mainframe applications were written in assembler up until the late 70s, so "IBM Assembler" or "Burroughs Medium System Assembler" maps fairly trivially on a line-by-line basis to high-level languages such as COBOL. I think that about the last system designed to look like that was the VAX, even CISC microprocessors have a far more primitive repertoire of operations and data types.
HEARTFELT PLEA: If Paul (or anybody else) starts making significant progress on this, I think that the community very badly needs a blow-by-blow account for future reference. Paul's notes in the wiki are very much to be applauded.
-- 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
