I wanted to actually test that the Free Pascal compiler - as originally written - would compile on my machine.  (Note for comp.compilers readers, the Free Pascal compiler is self-hosting, it is written in its own language, unlike, say, the GNU Pascal Compiler which is a front-end for the GNU Compiler Collection (the C++ compiler) and the GNU Pascal Compiler is written in C..

Compiling using the DOS IDE, I brought up the file PP.PAS, declared it as the primary file, for compiler switches, I entered into the IDE the following:

Win32  I386  cpu32bitaddr

Each time it did not find a Pascal Unit I cheated, looked for the file and copied it into the 'compiler' directory rather than try to set the directories in the IDE because I was having trouble or doing something wrong and it didn't find the files.  So then, once it stopped complaining, I had it do a 'build' to do a complete scratch build of the compiler.  This is on a Windows XP Professional 32-Bit OS on a 64-bit machine - Dell Optiplex 760 - 2.2 GHZ processor, 3 GB of ram and more than 1.4 terabytes of free disk space.  This machine was bought as refurbished about 18 months ago for about $200 and had the extra disk and memory added later, adding about another $200 to its price (I got a good deal on a 2tb drive for $89; prices went up nearly 100% about 6 months later.).

This was the result, I've copied off the results box shown by the FPIDE:

One warning:
   aasmtai.pas(396,11) Warning: Constructor should be public

Main file: C:\..\compiler\pp.pas
Done.
Target: Win32 for i386
Line number:    225     Total lines:      261804 Used memory: 417612K    Allocated memory:  25792K Total errors:     0     Compile time:       13.9s

        Compile successful: Press any key

From the directories it creates 203 PPUs (the internal object library file used by Free Pascal to store Units).   The compiler itself is 11,727,679 bytes.

I deleted all ppu files and the exe file and re-ran build, and this time it took exactly 14 seconds.  Typing its name at the DOS prompt causes it to list all of the options and quit, indicating it is operational.

In short, it compiled a program containing a total of about 262,000 lines of Pascal code in 14 seconds, which comes out to a compilation rate of around 1.12 million lines of code per minute.   So basically I, just like anyone else, for about the same amount as an ordinary person's salary for a week, can own a machine that runs basically at what was mainframe speed levels a few years ago.

The Lessons of history teach us - if they teach us anything - that no one learns the lessons that history teaches us.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2.0.17 (MingW32)

mQENBE2PI1ABCACnhOuOx+PjaiDMquIKQ+0lIw2WSDYKa+4F90WkpZtFYC+S2pF2 MYfD7OxZzcQL85VS3SuJjzZFpwbBqMPgEe3PaHlihy4Jw0zUqb/t5LbPwXpDNkYr XL5pzI6VH66zd2RDetojW3/eYqTFWy7Wf/gV+yO4egvifS1MdxrwYMb3k7Qvf73E v+BFiKkhBXLxHpClED3aeQevxjZkT+dMBFEcTANnb3WYm89j7yGb+vWFflP8bM88 Ys/eZKzbmwf8sL7XHHwzgq/y0Nqa7p5hPHgekgGE0f2bYL3VNFz5+4etaA6iImAQ ha2Dm4SWWpPJSAsdQhwJuWcEV+cDjTvtKRa5ABEBAAG0JVBhdWwgUm9iaW5zb24g PHBhdWxAcGF1bC1yb2JpbnNvbi51cz6JATgEEwECACIFAk2PI1ACGwMGCwkIBwMC BhUIAgkKCwQWAgMBAh4BAheAAAoJEIiQHns+nAjaQn8H/2kfwoPYjWUUiJu+doTp to4ebxUDyZdYhXn8vxu4E6k20EK3rJWKYNAYYBIBt3ylvMAUwkoZcMTm+/Nzzyhy SRqehG6+IS1l1Lv3Df+eJ1j0YU6nnLcc33u3Dn5rQkDyY1KHsBm5VEaQBv8S6kAZ 0wmrq2oOK/OBTa3pcR6DT+lpsNhIIwFlmYpHsbCCelfbWzg2EufLAQBiqwkRTjWm tJ1kJyrvTJIVeIFakfpeqdrKojxomQUMWEqsGZGJiNBNCslcQjNIwyqzbqmfMHaq 3s+83hPl8c2pFWDphj3bnsrBXcB4GqDsPSFXvDDc0neRybX6K2Mq7/qYIwQdIYnq wC65AQ0ETY8jUAEIANHrZpUNN6McKYV7tcyRjwY4N81TgGd3iY96smiEkJYye32E qYzJtVS1LLdcHIF1C4c72NpGPfBG+LUNHC5zuZLwJ/3ovVMD6KjHaypy+wwQgmHA 2JLkxTcsnX7tA9Kb0J7oXIdDMZLx40chs+W0cvvVYYqB/mLfCwsy4KGKl3n6FWND 47kSBLK5b/82hm44QA/p7K8z2xTLQx9G/Rt0AXD9Sdz2UfiZTnp/LHwOig07xc0O q6t936Br/98u0qAmK5ZK8HR3AVpSz8BCYlxRbAUdsk7stCwyM+YDxGlts2c0UJIk iZ3wCXUk/mRIluegkKslYGNwf4eciBEAPDugaoUAEQEAAYkBHwQYAQIACQUCTY8j UAIbDAAKCRCIkB57PpwI2nTuB/4qwOZF8y4ma8xdvT8SW2PsQ3j4nSHpJ2frV8li hpU1JwoN56i0ghAVg50VJJ/Ge0VUDdvzBTlt+eQZfJsvEuIFG2UFvjTGjvXpQ5Ie bRL3mXBGBnUrOoiw6Z2k5L1mUrIP+p50iLxzFsN8wR982M6z3a0ED7ogaoiVC0va 4wSeuxAnq4fk407hNFj7e2IkvTzoWcGT/3ORQh7e6EmUw5EMDu4n0O3IduPFkTw0 pgsaaZOsshOCOdF85+/foiagBpwsKahgisW4N0Jb+eAeIRgs1WWsM2Ojwfyupe/J v0pnpOpGjXYyMAen2Z+WCVY9H5GNaK0D9aB7nguQP31uVJp9
=vT1t
-----END PGP PUBLIC KEY BLOCK-----

The following command is sufficient to build a compiler for the i386 platform (from inside cmd.exe):

fpc -FUlib -otestpp.exe -FE. -Fusystems -Fui386 -Fux86 -Fii386 -di386 pp.pas

"-FUlib" specifies that all *.o and *.ppu files are generated in directory "lib" (which you need to create first)
"-otestpp.exe" specifies that the resulting executable should be named "testpp.exe"
"-FE." tells the compiler that the resulting executable should be created in teh current directory
"-FuXXX" are the directories which contain other used units "-FiXXX" specifies directories which contain include files "-di368" will generate a compiler for "i386". Other possibilities can be seen in the comments of pp.pas

If you have already compiled the compiler using the Makefile ("make all" in the top level directory of the FPC source or "make cycle" in the directory of the compiler) then you can use the "manually" created compiler to compile itself again using the following command:

testpp.exe -n -Fu{YOURSOURCEDIRECTORY}\rtl\units\i386-win32 -B -FUlib "-otestpp2.exe" "-FE." -Fusystems -Fui386 -Fux86 -Fii386 -di386 -vinw pp.pas

"-n" tells the compiler not to use its default configuration file The parameter containing {YOURSOURCEDIRECTORY} is the directory where the Makefile (see above) compiled the RTL (RunTime Library) to (we need that now that we don't use the default configuration). "-B" tells the compiler to recompile all units.
We also use a different name, as "testpp.exe" can not be overriden while it's running.
"-vinw" tells the compiler to display general information (like "Compiling blabla.pas"), notes and warnings (this is normally also included in the default configuration).

Regards,
Sven

Paul,

Why not ask the fpc developers (via fpc-devel) for access to the fpc svn for your new code. This'll have advantage that it'll be easier for the fpc gurus to advise on any changes needed for the new target, and of course it'll make it available to everyone else too. As you probably know fpc has been ported to many different architectures from the original linux & win32 i386, big/little endian, 32/64 bits alpha/sparc etc - tho' not such a different architecture as yours maybe ! - so they know quite a bit about the best way to do it.

John

John Lee wrote

Why not ask the fpc developers (via fpc-devel) for access to the fpc svn for your new code.

That's not a bad idea, I'll probably do that, I wanted to get an idea of what's involved first before going to a lot of trouble.  I wanted to see if I was capable first, I have some disabilities that might cause problems. 

I do have one little question, I have Mercurial installed, I can also install SVN, and in fact I had it on another machine, and I'm just curious, as to why they use SVN over Mercurial, is it just that that was what was available at the time and it works satisfactorily enough for the project's purposes, that it's better than Mercurial, or that it's just one of those Coke vs. Pepsi comparisons, they're (CVS vs. SVN vs. Mercurial) just different ways of doing the job like different word processors (or, (say it softly) different programming languages!)?

I sometimes wonder if programmers at the Rite Aid or Walgreens drug store chains use CVS.  (CVS is a competing drug-store chain in the US as well as the name of a source-code repository system.)  Oh well, it was a better joke when I thought of it.

I note that my message about adding two new features to the compiler didn't show up here, I suspect that since I didn't re-subscribe to this list until later, it took it as potential spam so I'll re-submit it.  I'll probably also write one up for my IBM 370 port later. 

On the pages on the Free Pascal Wiki I'm writing on my attempts to port the Free Pascal Compiler over to the IBM 370 series machine (known now as zSystem), with the initial target being an IBM 370 on OS/VS1, I note the number of many differences, considering that the machine is an upgrade of a design developed in the late 1970s.  (Some of these aren't listed there, I'm just remembering some of them.)
* It's Big Endian (I believe the PDP-11 minicomputer is also.)  Personally as far as visualizing data I prefer Big Endian over Little Endian, but as long as the processor works accurately it doesn't really matter.
* There are 16 registers of 32 bits but in general practice only about 10 of them are available.
* The most you can access at any one point from a register is 4K, whether that's a branch in code, or a piece of data.  If you're going to access more than 4K, you need to set aside more registers.  If you have very large procedures (or a very large main program), or you need to work with very large data structures you may have to break it up into smaller ones, or, most likely, I'll put in some switches to tell the compiler basically to make all branches into potential "long jump-style" ones, where each branch is done similar to a procedure call instead of a "local" branch.
* Only 32-bit operations are available.
* Only tables are available, in-line constants are generally not (this is not exactly true, but is close)
* It's internal character set is EBCDIC, not ASCII.  Also, the character set is not continuous along the alphabet, e.g. doing a test on ['a'..'z'] or ['A'..'Z'] will fail because it will pick up other non-alphabetic characters.

A lot of these restrictions are lifted on the zSystem which is a 64-bit machine, but right now I don't have access to one or the means to test on it (I first have to get the compiler to generate on what I can work with.  So as the saying goes, let's get to "crawl" first before we try to walk or run!)

Since the machine I have to emulate for targeting the compiler toward is the 370 architecture (as opposed to the zSystem) using the OS/VS1 non-interactive (batch) operating system, I'll target the less capable machine/OS, and have (again) more options for things like targeting 64-bit processing, for other operating systems than OS/VS1, etc.

Paul

 Sven Barth wrote

We also use a different name, as "testpp.exe" can not be overriden while it's running.

Sometimes I'm stupid!  I can't believe I forgot that.  (Oh yes, I can believe it; I've made stupido mistakes before.)  But the original run was just a test, and basically I was blown away by a compiler that is "fast enough" to compile itself in 14 seconds, despite the fact that it's compiling a huge, rich application of more than a quarter of a million lines.

I mean, I have a nice machine - a 64-bit uniprocessor with 3gig of memory and 2tb of disk space is not exactly limping along - but it's not "bleeding edge."   Although I think about the fact that at my school circa 1978 we ran an IBM 360 clone mainframe - a Univac 90/60 - which had 500K of memory and 100 meg of disk space for a city college that had probably 5000 students, 300 of which were probably in IT, and did pretty well, kind of amazes me to think how far we've come in a little over 30 years. 

And the only Pascal compilers back then were Standard Pascal.  Mark/Release (meaning the programmer has to manage memory and garbage collection themselves), in fact one of the reference manuals said that using dispose might cause problems or wasn't implemented, I can't remember which), sequential files only, no units, objects, classes or anything else we've developed for increasing what high-level languages can do now.

Now I get it! You're the one who wrote the zSeries How-To on the Wiki... we need to talk! Because according to your according to your How-To you might be heading into the wrong direction and I want to correct that before you've done too much work.

I do have one little question, I have Mercurial installed, I can also install SVN, and in fact I had it on another machine, and I'm just curious, as to why they use SVN over Mercurial, is it just that that was what was available at the time and it works satisfactorily enough for the project's purposes, that it's better than Mercurial, or that it's just one of those Coke vs. Pepsi comparisons, they're (CVS vs. SVN vs. Mercurial) just different ways of doing the job like different word processors (or, (say it softly) different programming languages!)?

You can search the mailing list archive (fpc-devel or fpc-pascal, I don't know) for that, there where already some discussions about that.

There is AFAIK a Mercurial mirror though (and a Git mirror as well), but the main source is the Subversion repository (I myself used git-svn while I worked on some compiler features).

I sometimes wonder if programmers at the Rite Aid or Walgreens drug store chains use CVS. (CVS is a competing drug-store chain in the US as well as the name of a source-code repository system.) Oh well, it was a better joke when I thought of it.

FPC switched from CVS to SVN a few years ago.

I will try to write back regarding your port tomorrow, because today I haven't got anymore time for lengthy explanations (work related reasons).

Regards,
Sven

Paul Robinson wrote

I sometimes wonder if programmers at the Rite Aid or Walgreens drug store chains use CVS. (CVS is a competing drug-store chain in the US as well as the name of a source-code repository system.) Oh well, it was a better joke when I thought of it.

I'd remind you that several other manufacturers (including Burroughs and ICL) used the IBM 029 card punch, even if they typically put their own logo on it.

On the pages on the Free Pascal Wiki I'm writing on my attempts to port the Free Pascal Compiler over to the IBM 370 series machine (known now as zSystem),

That seems an eminently good idea, since it's about the only major architecture (with the arguable exception of the Itanic) that FPC doesn't target.

with the initial target being an IBM 370 on OS/VS1,

Why not start with Linux? it's a bit more accessible for the rest of us, and you'll be able to refer to existing RTL source.

* It's Big Endian (I believe the PDP-11 minicomputer is also.)

As are SPARC and PPC, both of which FPC supports.

* The most you can access at any one point from a register is 4K, whether that's a branch in code, or a piece of data. [...] Only tables are available, in-line constants are generally not (this is not exactly true, but is close)

I'd suggest reviewing the "Porting GCC to the IBM S/390 Platform" paper that I've cited on http://wiki.lazarus.freepascal.org/ZSeries, and selecting a base system that does allow inline constants. I think it's pretty unlikely that anything's left in (commercial) operation that's older than this, and the Hercules emulator (see for example http://wiki.lazarus.freepascal.org/Qemu_and_other_emulators#Debian_zSeries_Guest_using_Hercules) obviously supports the newer facilities.

* It's internal character set is EBCDIC, not ASCII. Also, the character set is not continuous along the alphabet, e.g. doing a test on ['a'..'z'] or ['A'..'Z'] will fail because it will pick up other non-alphabetic characters.

Again, I'd suggest starting off targeting hardware and OS that's happy with ASCII.

Sven Barth wrote

I will try to write back regarding your port tomorrow, because today I haven't got anymore time for lengthy explanations (work related reasons).

I'd be interested in any off-list discussion. I'm not promising to be able to do very much to help due to other commitments, but am slowly trying to get to grips with the way the compiler and RTL are put together and my experience with the Hercules emulator could possibly be useful.