Rugxulo wrote:
Since most of these languages are not widely used, I wouldn't consider them attractive targets for a converter.
Maybe not individually, but taken as a whole, all the Wirth-ian languages and their users can add up. And it seems many users use (or have used) more than one (except me, so far).
I don't understand your point here. A converter would target one language, not all of them combined somehow. So we'd have to decide on one of them and depend on its future. (BTW, Eike's suggestion of writing a collection of converters for different languages, is interesting in a theoretical sense, but practially, I don't see how it would help, rather than cause even more work.)
I'm not knocking your decision, it worked quite well! GPC is a nice product, nicer than most software. I don't personally believe software is throwaway, so I do think it should be reused or preserved (if possible).
Neither do I, and in fact I have programs that are decades old that I've ported between several languages and target systems (and might now have to port once more if GPC actually dies).
But the fact is that GPC needs a serious amount of maintenance right now and in the foreseeable future, and this work isn't going to do itself (until we develop a good AI ;-).
However, I do understand hindsight. Even RMS complains that choosing Mach for Hurd was meant to save them time but probably hurt in the long run. Yes, ironically, sometimes it is easier to rewrite from scratch. But you need experience, and that usually only comes from modifying a pre-existing project.
Yes, that's my point. Again, I don't blame Jukka, neither for choosing the gcc backend, nor for starting from the C frontend, though in hindsight both decisions are now causing us problems, and these problems are real.
Kevan Hashemi wrote:
Dear Frank,
Yes, it's possible, but it's IMHO not conformtable.
Okay, I think I understand the extent of the problems with re-writing the GPC C-code in Pascal, and I appreciate that there may not be enough development hours available.
I am going to make sure that I have a multi-platform Pascal compiler, even if I have to re-write the entire thing myself. I agree with Pascal Viandier: GPC is by far the best Pascal compiler I have ever used, and I have no intention of taking a step backwards to C++ or another Pascal compiler.
If we create a self-compiling compiler, do we need our own assembler written in Pascal as well? Or can we produce GCC-style objects and use any GCC linker and assember to produce our executable?
I think one could produce GCC-style assembler and use the GNU assembler and linker. But I'd strongly advise against that. Assembler code is, of course, CPU dependent, so you'd need a code generator for each target. What's more, the assembler doesn't optimize, so you'd need to do all the optimization yourself (which is a huge task, probably larger than the compiler itself, if you want good optimization of modern standards). So if you're going to output assembler code, I'd suggest LLVM (though I don't know it myself, AIUI it's machine independent, and LLVM tools can do optimization on it). Though I still think a high-level language is a better target (e.g., C++ because it provides objects, exceptions and templates already which you'd otherwise have to reimplement, which is extra work and probably wouldn't be compatible).
What is it in the GCC interface with Pascal that keeps changing?
The interface between the backend and the frontend. Not so much the changes in function parameters etc. (these are easy because the compiler catches them), but e.g. the expected data structures changed drastically, internal systems like memory management changed which both required larger changes in GPC, and the behaviour of the backend changed in subtle ways which is probably the reason for some of the non-trivial issues I've had with gcc-4 based GPC with my code. (Perhaps the backend just did more aggressive optimizations which the GPC frontend isn't prepared for, resulting in miscompiled code.)
Is it the object format?
The backend and frontend are linked together in the compiler excutable (gpc1, called by gpc). No files are exchanged between them, but data structures in memory (which, of course, allow more flexibility and therefore more incompatible changes, as we've seen).
The backend outputs assembler files, which the assembler translates to object files from which the linker produces executables and libraries.
You give one example to do with restricted language flags in your report. Perhaps you could give us some more examples.
If you're interested, I suggest you read the "Internals" chapter in GPC's documentation. However, I'm not sure these kinds of things are important WRT a rewrite since they would all be replaced by clean data structures, e.g., an abstract "declaration" object class, with derived classes for variable, routine etc. declarations, each having exactly those fields that it needs, with no need for general-purpose "language flags", or for runtime type checks which GCC/GPC often does, e.g. to ensure that a tree node is in fact, say, a type declaration when it should be one (whereas a rewritten compiler would, of course, just take a formal parameter of type "TTypeDeclaration" or whatever, thus ensuring type-correctness at compiler-build-time).
Rugxulo wrote:
... so much effort is required which there's noone there to do. :-(
In other words, bugs that you yourself can't fix? I don't have any huge complaints with GCC 3.4.4,
Me neither so far, but I do with gcc-4.x based GPC.
that's why I'm wondering why it deathly matters to have latest and greatest GCC support (besides the obligatory "it would be nice", e.g. Atom support or plugins in 4.5.0).
Some platforms (in particular Mac) regularly require newer backend versions because their support in older ones was too buggy or nonexistent.
Bugs found in gcc-3.x won't be fixed by the GCC developers, so we'd have to maintain that backend outselves in the long run (which I certainly wouldn't want to). Also, of course, newer developments (such as better optimization) in gcc-4 wouldn't be available to us then.
big runtimes and thus big .EXEs (so?),
Not a problem for most cases, sometimes a problem for embedded systems etc. and for people with a 1980s mindset ("oh shock, a few megabytes executable"). ;-)
It's more of when you write a very simple tool that takes 300 KiB. It just feels wrong, esp. from an "assembly" mindset or if you're spoiled by smartlinkers in other Pascal compilers. I'll admit, Frank, to be frank, ;-) in real life it doesn't matter in 99% of cases, but I do think libgpc.a could be modularized a bit better. (No, I haven't looked closely yet, my bad! And BTW, I strongly suspect GNU ld's --gc-sections doesn't work with COFF, blech.) I mean, no offense, but when a combined DOS 8086 (TP55) + Win32 .EXE (VP21) takes 24 KiB uncompressed .... ;-)
As I said. Sure, one could do something about it (smart linking in general), but, well, someone would have to do it. Like with many other issues -- I don't really lack ideas what could be improved in GPC in many ways, what we're lacking is developers who will actually do it.
I don't want to get too philosophical, but I think a reason for its decline was that in several ways it just was too strict. E.g., while I dislike "goto" as much as Dijkstra did, I'm not so much opposed to "Exit" (which some dismiss as a disguised goto, and ISO Pascal doesn't have).
"Exit" as in "break" out of loop? I don't even think TP had it until v6 or (more likely) v7. Also note that some languages (Oberon, Java) don't support goto at all !! And FPC only handles local gotos.
Yes. AFAIR, TP had it earlier. As for non-local gotos, I use them in very few places in my code, and these cases would be better served with exceptions (e.g., a la C++).
(In fact, it might have been better to leave I/O completely out of the language, like C did, and let library authors develop it
Didn't Modula-2 do that, much to many people's chagrin??
I don't know about Modula-2 (why didn't Modula-2 programmers just write a "standard" I/O library?), but I can hardly imagine the situation is worse that what we have in Pascal now -- two mostly incompatible models (standard and BP), both not powerful enough for many things.
Same with the lack of an official, and therefore standardized way, to interface with foreign-language libraries, a common necessity in real-world programs. (Sure, you can reinvent every wheel, i.e. reimplement every library in Pascal, but that's not productive.)
Ada has Interface (or whatever it's called). Doesn't matter anyways as there are so many competing formats (ELF, COFF, Mach-o) and linkers that work in varying degrees and different ABIs. (Agner's ObjConv potentially helps here, but I've never heavily used it.)
If it depends on the object format, it's not standardized IMHO. I mean something like GPC's "external name", together with guaranteed C-compatible types (as a minimum, so any C funtion declaration can be translated manually), or of course, as a maximum, a fully-automatic way to get foreign-language declarations (such as C++'s 'extern "C"', which is, of course, easy since C++ almost contains C as a subset).
So that's perhaps why BP was popular under Dos, because it was one fixed dialect (so diverging extensions, though massively present, and their long-time consequences, were not known to the majority of programmers),
Except it also extended itself several times! So code that works for TP55 (objects, units) won't work in TP3, nor code in TP6 (inline asm).
But it was backward-compatible between its versions.
Plus bugs and heavy 16-bitisms.
That's what I meant "were not known to the majority of programmers". The most famus bug (Delay runtime error 200) occurred on faster CPUs that didn't become popular until BP was mostly abandoned, and Dos programmers didn't care about 16-bitisms and worse (direct access to fixed memory addresses of Dos etc.). Portability was basically unheard of.
Doesn't mean lots of good stuff wasn't written in TP/BP (e.g. Chasm: The Rift), but most of that old code is pretty unmaintainable without the exact same compiler version (ahem, TPU incompatibilities).
I won't blame Borland for changes in binary intermediate files (TPU). GPC changed the GPI format several times as well, and as a free software supporter, I care more about source compatibility.
I/O was extended to be at least suitable for Dos (though it maps less well to other systems which were ignored by most Dos programmers)
Since TP didn't run on anything else (CP/M dropped after v3 and only two TPW releases), that's no surprise, esp. since they never fully supported ISO 7185 or 10206. It's hard to be portable when you ignore standards. And yet most compilers nowadays (even on "modern" OSes, heh) try to emulate BP-style, oddly enough.
You echo my point. Back in the Dos days, it was an advantage for BP because BP programmers obviously didn't need anything but Dos I/O (and generally didn't care much what existed elsewhere). Nowadays, it's a liability.
and supported modules (units) which allowed some other needed facilities (such as CRT) to be supplied. But all of this was too short-sighted:
Everything in computers is short-sighted. We're constantly being bit by it.
But some things more than others ...
We now have a mess of dialects;
No worse than all those silly Romance languages. ;-)
How good that English has only one, universally accepted dialect. :-)
Dos-style I/O is too limited on modern systems; even CRT (one of the least bad designed BP units IMHO) wasn't as lasting as its C roughly-counterpart curses).
C didn't have curses built-in anyways.
I didn't mean to imply this, neither is CRT built-in in the BP language.
In fact, it left a lot out, hence POSIX (which I guess has its own dialects, e.g. 2008). Nobody bothers with pure ANSI C anymore (sadly), which is more painful when using non-GCC compilers (like OpenWatcom).
I don't know about everybody, but I try to use only standard C/C++ features. Of course, I compile with gcc only, but I enable a lot of warnings, and fix what they complain about. Apart from that, assuming you're talking about free software projects, if you want them to work with other compilers and they don't (without good reason), do something about it. That's the point of free software -- find out what doesn't compile, change it, and send a patch to the developers. Just complaining "I want this and that" won't help. (As a gross example, consider that Linus Torvalds, in the early days of Linux, claimed it would never run on anything but x86 and never be modular. Today it is modular and runs on many platforms. How did this happen? Not because people complained to him and pleaded him to do it, but because some who actually had the need wrote the code. After it was written and in good quality it was integrated, and now it's part of the official kernel.)
Heck, I know I'm on unsympathetic ears here, but I often think even Linux is too much of a moving target sometimes.
Depends on what features you use. Most of my GPC programs compile unchanged on an old libc5(!) based system (from 1996) and modern systems, including graphics (X11 and most of OpenGL -- though I did the latter only in C++). Of course, GPC's autoconf for the run time system covers some small differences, but there have been relatively few incompatible changes in this regard (e.g. pty handling -- and I even get both forms of it working in parallel with some manual setup). I think the bigger issues are things like directory structure (file hierarchiy standard), but that's more issues for sysadmins (including personal users) than for programmers.
the current GPC users seem to be rather diverse (WRT dialects, platforms and features used etc.), which also doesn't bode well for a new project.
Like I said, your favorite dialect seems to be ISO 10206. (I saw you praising it in some old mail in list archive.)
Partly. It still carries the limited I/O system and doesn't provide low-level features (I'm not saying you should use them often, but sometimes you have to), or external library interfaces. So my favourite dialect is actually some subset of the GPC dialect ...
So you should probably just use that as a testbed for your C++ idea.
Well, no. As I said, I feel the lack of features like templates and automatic destructors, so if I was to work on something new, it should include those features.
Frank