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: http://fjf.gnu.de/gpc-future.html
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 continue.
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 http://www2.gnu-pascal.de/crystal/gpc/en/mail12897.html 5. stalled GCC back-end development/integration (a show stopper when the target OS requires a recent GCC)
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.
Regards,
Adriaan van Os