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

[Mr Paul Robinson]

--- 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---