[fpc-devel] On a port of Free Pascal to the IBM 370

[Mark Morgan Lloyd]

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]