Several times in the last year people have contacted me about the increasing compliance of FPC with ISO 7185. Its my pleasure now to say that I have tried it, and FPC is very close to being ISO 7185 compliant.
After GPC fell silent, FPC was the only open source full compiler out there. Now, about 20 years after the inception of FPC, it has gained compliance with ISO 7185. I don't know if this was because they picked up developers from the defunct GPC project, or because they simply decided it was a good idea to pick up the group of users from GPC who wanted ISO 7185 compatability, or a combination of both. But bravo, good show FPC !
So why did FPC succeed when GPC did not? GPC was built as an add on front end to the GCC compiler. Using the GCC backend meant that getting a high quality code generator was basically free. Fortran was implemented that way, as was ADA. It also meant that whatever machine GCC could generate code for, so could GPC.
The disadvantages of doing that are twofold:
The front end must be written in C (for all practical purposes).
The front end must follow all changes in the back end (GCC).
It was the latter that killed GPC. The constant need to keep up with the changes in GCC did the project in.
As a side note, in about 1995 I considered also building a compiler as a front end to GCC. I didn't do it because GCC does not have a formal intermediate language (as P5 does). That not only forces the front end to be written in C, but coupled the front end and back end together far too much for my liking.
FPC is different. Written in its own language, FPC is able to target multiple support systems (even a fully self contained compiler needs assemblers, linkers and executable generators in the back end). Thus, FPC will be far less likely to be affected by changes in the downstream toolset.
So what seemed like a dead end also for Pascal-P5 has cleared up. We have path forward in FPC as a host compiler. I look forward to getting all three environments back up using FPC, Windows, Linux and Mac OS X with Pascal-P5.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I did a test using FPC to compile P5, and the result was that "it mostly worked". The main source compiled, but the treatment of the header files was strange and would have required me to make special source adaptions to FPC. That was enough to put a hold on it.
I have been told that the next compiler features a fix to this, but even as the year comes to a close, I have not seen a new version of FPC that has the fix.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Several times in the last year people have contacted me about the increasing compliance of FPC with ISO 7185. Its my pleasure now to say that I have tried it, and FPC is very close to being ISO 7185 compliant.
After GPC fell silent, FPC was the only open source full compiler out there. Now, about 20 years after the inception of FPC, it has gained compliance with ISO 7185. I don't know if this was because they picked up developers from the defunct GPC project, or because they simply decided it was a good idea to pick up the group of users from GPC who wanted ISO 7185 compatability, or a combination of both. But bravo, good show FPC !
So why did FPC succeed when GPC did not? GPC was built as an add on front end to the GCC compiler. Using the GCC backend meant that getting a high quality code generator was basically free. Fortran was implemented that way, as was ADA. It also meant that whatever machine GCC could generate code for, so could GPC.
The disadvantages of doing that are twofold:
It was the latter that killed GPC. The constant need to keep up with the changes in GCC did the project in.
As a side note, in about 1995 I considered also building a compiler as a front end to GCC. I didn't do it because GCC does not have a formal intermediate language (as P5 does). That not only forces the front end to be written in C, but coupled the front end and back end together far too much for my liking.
FPC is different. Written in its own language, FPC is able to target multiple support systems (even a fully self contained compiler needs assemblers, linkers and executable generators in the back end). Thus, FPC will be far less likely to be affected by changes in the downstream toolset.
So what seemed like a dead end also for Pascal-P5 has cleared up. We have path forward in FPC as a host compiler. I look forward to getting all three environments back up using FPC, Windows, Linux and Mac OS X with Pascal-P5.
Follow up
I did a test using FPC to compile P5, and the result was that "it mostly worked". The main source compiled, but the treatment of the header files was strange and would have required me to make special source adaptions to FPC. That was enough to put a hold on it.
I have been told that the next compiler features a fix to this, but even as the year comes to a close, I have not seen a new version of FPC that has the fix.
I'd like to mention that, ACK[1] can also be used to bootstrap P5 (some small tweaks is on the way[2]).
[1] https://github.com/davidgiven/ack
[2] https://github.com/davidgiven/ack/issues/37
Nice, sorry I didn't see this earlier. Its an interesting project!
Annnnndddddd FPC works now, at version 3.0.4. I'll be commiting the new configurations today.
A few failures with FPC running standard tests. I'm sure that will get resolved.