--- 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
http://lists.freepascal.org/mailman/listinfo/fpc-devel
