Objective Modula-2 wrote:
At our Modula-2 project we have received lots of interest from students at universities where Modula-2 is still being taught. Some are new graduates who have been involved in compiler implementations of Modula-2 or Oberon subsets either as part of their course-work or in their graduation projects.
It seems GPC has a good following in adademia and there should still be universities who teach Pascal.
From what I see and read recently (more like, in the last 10 years
or longer), apparently not so many.
So my recommendation would be to actively seek out those universities, talk to the professors who run the courses and try to win them over as "recruiters". They could suggest GPC related course-work. They could tell their compiler construction classes that a new generation of maintainers is needed for GPC. To me it seems that this is the most likely way to find new maintainers for your project.
To be honest, I think this might have been a good idea some 10-15 years ago. Now it may be too late.
I also would like to comment on the notion that the GPC front-end is stuck with C as an implementation language simply because GCC is C based.
The GNU Modula-2 GCC front end is written in Modula-2. There is still some C involved at the bootrap stage (via p2c) but by and large GM2 is a Modula-2 code base. Check out the GM2 repository and take a look. The code is well documented and if you run into difficulties doing the same for GPC I am sure Gaius Mulley (the GM2 developer) will be happy to give you some guidance.
One advantage GM2 (and disadvantage GPC) has had is WRT support of different major backend versions and their large changes.
You might say we should have dumped the old versions and go all in with the new ones as soon as possible, but remember we didn't write GPC in an empty space with unlimited resources for philanthropic reasons. We had actual programs that we needed to compile and maintain (since BP wasn't up to the task anymore), with gcc 2.7.x or 2.8.x current at that time. When gcc-3 came out, it took some time before GPC support with it was really stable (not just somehow usable), and during this time we still needed support for gcc-2. (Actually it was two major steps, since gcc-2.95 and egcs already introduced big changes from 2.8.x and gcc-3 made more.) Then, in the transition to gcc-4 we cannot (note the present tense) dump gcc-3 which for me currently is the only way to compile most of my programs. If we had started with gcc-4 as GM2 did (AFAICT), we wouldn't have had many of these problems (but we also wouldn't have had a working compiler for many years).
It will be interesting to see how GM2 does when gcc-7.x comes out. This isn't meant sarcastically -- I wish them well; perhaps disruptive changes in the backend will have settled somewhat by then, or perhaps they have developers who can affort to break the compiler during the ports without the constant need for a current (frontend) version available.
Kevan Hashemi wrote:
Adriaan van Os wrote:
Doing that is a very difficult and never-ending task, because the back-end will keep changing. It is more time-ineffcient to go another way, e.g. to rewrite the compiler to produce intermediate C++ or (what I would prefer) intermediate LLVM assembly code.
If what OM2 says about GCC is true, then I think it's clear that the GCC team will do their best to make it hard for us to keep up with their changes, and therefore you are right: it's not worth bothering with.
They don't even need to make it hard for us on purpose. It's hard enough already (probably too hard, given available developer time).
Grant Jacobs wrote:
- A work-around solution for *my* personal use would to have a
development line against one or two "frozen" OS(es) that can be virtualised easily on the current platforms (e.g. selected versions of Linux + gcc + the other tools needed).
If it's not clear, what I am thinking of is running (say) a version of Linux as a virtual machine on (in my case) Mac OS X and working with GPC from within that. (Ideally the GPC project would host the core VM images.)
As I said, on Linux (specifically Debian, but I suppose similar with other distributions), the situation is currently as follows:
- gcc-3.x is not part of current distributions anymore.
- gcc-3.x binaries (including GPC) from older distributions can still be installed without dependency problems.
- When this fails someday, it can probably still be compiled from older sources.
- When this fails, it's possible to run several OS versions side by side. (FTM, I currently run several different distributions, including, as I mentioned in another mail, even a libc5 based system from 1996, in chroot environments, which means, basically, the same kernel, and even the same X11 desktop, but otherwise completely serapate programs, libraries etc. This works surprisingly well, and I suppose it will in the future.)
- When this fails someday, virtual machines or emulators are probably the last ressort.
So it's actually quite some time until the existing GPC will really cease to be usable in one of these ways. (The Y2038 problem might hit earlier. ;-) But of course, it will get less and less comfortable, especially if you intend to distribute programs.
Objective Modula-2 wrote:
It is correct that the existing code will remain available but without maintenance, GNU Pascal would eventually cease to work with the latest GCC distribution.
Actually, it doesn't even work yet with the latest GCC. It works with a somewhat older GCC (4.1), but buggy, as I described. It works well with gcc-3.x, which is so old it's been removed from major Linux distributions (though it can still be be installed manually, see above), doesn't work well on Mac OS X (AFAIK), and may have other issues.
As for retargeting GNU Pascal, I personally would consider that a new project.
Waldek suggested the same in private correspondence, which already made me skeptical of the approach before I sent my first mail. The situation doesn't seem right for starting new projects.
First, some clarification. Some posters appear to be confused about what LLVM is. For example, I saw one commenter writing "I am not interested in programming in ... LLVM". The LLVM compiler infrastructure is not a programming language you would write programs in.
Yes, and since similar confusion arose about my C++ converter proposal, let me restate this: Any possible converter (whether to C++, Ada or LLVM, which seem to be the major 3 candidates now) would be part of the build process, so one would program in Pascal. (As I said, a half-automatic converter for a permanent transition would be a much simpler task, which I might do if GPC dies.)
Frank