Ok, so occasionally I am wildly wrong. Ok so it is once a week. Or daily.
LINUX
I got the Linux 64 bit version of GPC running on Ubuntu 14.04, which is pretty much the latest version. I did it by brute force. A couple of environment variables needed to be added to tell it where to find library files.
That was only phase one. In phase two, I found out rapidly that the 64 bit gpc compiler actually does the correct thing and defines integer as 64 bit. This to me was quite a surprise. I was on the GPC mailing list in those days, and there was an argument concerning if integer was to be 32 bits in the 64 bit version, so as to allow backward compatability with older programs (much like C uses long long for 64 bit instead of common integer). I argued strongly that the whole idea of Pascal types is that they are NOT size dependent, but rather change with the machine implementation. At the time I was under the impression that this argument was not succeeding.
In any case, GPC does the right thing. Now, as proof to "be careful what you ask for", this, of course, breaks P5 fundamentally. In two places, the representation of addresses in the virtual machine, and in regular integers (used everywhere), the conversion to and from the bytes in the store array are wrong.
Now I could have fixed this by having the get and put routines for integers and pointers simply convert to and from 64 bit types, but that (to me) is the wrong answer. The whole reason P5 keeps its integer and address formats matching the machine type of the host is to encourage efficiency. Trying to, say, standardize implementation around 32 bits goes down the road of emulation and away from efficiency, with very little to show for it.
So to make a short story longer, this set off a push to adapt P5 to 64 bits, and be able to change from 64 bit mode to 32 bit mode easily (and automatically). In fact, there are now three major changes to the structure of the system to meet the following goals:
Make Pascal-P5 32 bit/64 bit adaptable.
Bring the last directory reorganization back up on Linux (because I have not run it there for a while).
Make the project (more) compliant with standard GNU release project methodologies.
I'm not quite there yet, but considerable progress was made. The 64 bit version does simple programs (hello world and others), and the system is shaking out. I am also back checking it via Windows/32 bit.
So what about Linux 32 bit,or windows 64 bit?
That's a good question. Warming up a 32 bit version of Linux on a separate disc is doable. I briefly tried setting up a 32 bit environment on my 64 bit Ubuntu, but that was a no-go. Library issues again. Perhaps the ultimate issue is that running 32 bits on 64 bit linux is a lot of work just to make a crippled result -- 32 bits on a native 64 bit platform. So why bother?
For 64 bits on a 64 bit Windows, that should be a reasonable prospect. However, there aren't any ready made packages for GPC on 64 bit windows, so we are back to having to spend a lot of work on it.
As far as compiling GPC from source, the answer is that I tried it, it resulted in a lot of errors, and thus a lot of work would be required. I recognize that this is the ultimate answer, but also realize that I can spend my time fiddling with GPC, a dead software implementation, or a live and ongoing P5.
MAC OS X
Armed with my new found success with Linux, I went back to trying this out on a Mac OS X box (the latest, 10.9.4). I like the idea of a troika of implementations (troika being Russian for "three guys sharing vodka" or the like).
What I would is that I could get an install by going back to OS X 10.4. And now, of course, it is throwing up various library errors.
More to follow on this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, so occasionally I am wildly wrong. Ok so it is once a week. Or daily.
LINUX
I got the Linux 64 bit version of GPC running on Ubuntu 14.04, which is pretty much the latest version. I did it by brute force. A couple of environment variables needed to be added to tell it where to find library files.
That was only phase one. In phase two, I found out rapidly that the 64 bit gpc compiler actually does the correct thing and defines integer as 64 bit. This to me was quite a surprise. I was on the GPC mailing list in those days, and there was an argument concerning if integer was to be 32 bits in the 64 bit version, so as to allow backward compatability with older programs (much like C uses long long for 64 bit instead of common integer). I argued strongly that the whole idea of Pascal types is that they are NOT size dependent, but rather change with the machine implementation. At the time I was under the impression that this argument was not succeeding.
In any case, GPC does the right thing. Now, as proof to "be careful what you ask for", this, of course, breaks P5 fundamentally. In two places, the representation of addresses in the virtual machine, and in regular integers (used everywhere), the conversion to and from the bytes in the store array are wrong.
Now I could have fixed this by having the get and put routines for integers and pointers simply convert to and from 64 bit types, but that (to me) is the wrong answer. The whole reason P5 keeps its integer and address formats matching the machine type of the host is to encourage efficiency. Trying to, say, standardize implementation around 32 bits goes down the road of emulation and away from efficiency, with very little to show for it.
So to make a short story longer, this set off a push to adapt P5 to 64 bits, and be able to change from 64 bit mode to 32 bit mode easily (and automatically). In fact, there are now three major changes to the structure of the system to meet the following goals:
Make Pascal-P5 32 bit/64 bit adaptable.
Bring the last directory reorganization back up on Linux (because I have not run it there for a while).
Make the project (more) compliant with standard GNU release project methodologies.
I'm not quite there yet, but considerable progress was made. The 64 bit version does simple programs (hello world and others), and the system is shaking out. I am also back checking it via Windows/32 bit.
So what about Linux 32 bit,or windows 64 bit?
That's a good question. Warming up a 32 bit version of Linux on a separate disc is doable. I briefly tried setting up a 32 bit environment on my 64 bit Ubuntu, but that was a no-go. Library issues again. Perhaps the ultimate issue is that running 32 bits on 64 bit linux is a lot of work just to make a crippled result -- 32 bits on a native 64 bit platform. So why bother?
For 64 bits on a 64 bit Windows, that should be a reasonable prospect. However, there aren't any ready made packages for GPC on 64 bit windows, so we are back to having to spend a lot of work on it.
As far as compiling GPC from source, the answer is that I tried it, it resulted in a lot of errors, and thus a lot of work would be required. I recognize that this is the ultimate answer, but also realize that I can spend my time fiddling with GPC, a dead software implementation, or a live and ongoing P5.
MAC OS X
Armed with my new found success with Linux, I went back to trying this out on a Mac OS X box (the latest, 10.9.4). I like the idea of a troika of implementations (troika being Russian for "three guys sharing vodka" or the like).
What I would is that I could get an install by going back to OS X 10.4. And now, of course, it is throwing up various library errors.
More to follow on this.