Quo vadis, GPC?
ih8mj at fjf.gnu.de
Sat Jul 31 06:34:14 CEST 2010
> > 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
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
> 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
> 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
> 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
> > ... 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
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
> >> 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
> > 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
> > 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
> 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
> > 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
> 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 Heckenbach, f.heckenbach at fh-soft.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8
More information about the Gpc