Quo vadis, GPC?
Adriaan van Os
gpc at microbizz.nl
Wed Jul 28 12:10:44 CEST 2010
Frank Heckenbach wrote:
> since GPC development has mostly stalled, I've thought about if and
> how its development could be continued. Here are my current thoughts
> about it. Since the text is quite long, I put it on the web:
> As I write there, I don't see much future in the current way of
> developing GPC, but also alternative development models will not be
> a task for a single person. In other words, without some new
> contributors, there is probably no chance for GPC development to
> I don't really know how many of you currently use GPC, and to what
> extent and in which ways, e.g., do you use it just to maintain some
> legacy code, or are you actively writing new applications?
> So in order to tell whether continuing GPC development is
> worthwhile, I'd like to know who of you would actually care about
> major new features in GPC (as opposed to just preserving the status
> quo), and who would be interested not only in using GPC, but also
> supporting its continued development, either by actively
> contributing to it, or -- perhaps in the case of companies that use
> GPC -- by paying for continued development.
The devil is in the details. For me, a compiler is a professional tool and the quality of the tool
is more important than new features. A handful of weak points may become serious deployment obstacles.
Current GPC problems:
1. wrong line numbers in debug code
2. wrong and/or incomplete debug-symbol info, notably for 64-bit code
3. order-2 performance of unit symbol loading
4. order-2 performance of operator overloading symbols
5. stalled GCC back-end development/integration (a show stopper when the target OS requires a
I am not complaining or opposing new features. I am saying that a future path for GPC must tackle
these and similar problems. Questions must be answered. Does (5) imply moving away from the
low-level GCC back-end ? What are the alternatives ?
1. producing C/C++/Objective-C. What about the debugging experience ? What about GDB maintenance ?
What about targeting the LLVM debugger ?
2. producing LLVM assembly <http://llvm.org/docs/LangRef.html>
3. LLVM integration <http://llvm.org/docs/tutorial/> (also a moving target with a moving C++ API)
4. adding ISO and GPC language modes for FPC. This would be an opprtunity to redesign (parts of)
the FPC parser (for example to get rid of nasty code implemented as side-effect of type-checking
and operator/function overloading)
Anyway, I can help if the compiler is written in Pascal.
Adriaan van Os
More information about the Gpc