Quo vadis, GPC?

[Frank Heckenbach]

Jonas Maebe wrote:

> On 29 Jul 2010, at 11:05, Adriaan van Os wrote:
> 
> > Jonas Maebe wrote:
> >> If you put everything in a single compilation unit, then the  
> >> compiler can optimize more, but if the goal is speeding up  
> >> compilation then it will probably be counterproductive (possibly  
> >> unless you only care about compilation speed for -O0 and not at all  
> >> when using -O1 or higher).
> >
> > It depends where the compiler is spending its time, generating code  
> > or processing declarations, reading unit symbols, etcetera. For GPC  
> > on Mac OS X, the bottleneck is absolutely the latter.
> 
> I don't think the current GPC unit loading architecture is comparable  
> to how a C++ backend would work. And as I said, it is very much  
> depends on the size of the compilation unit: larger compilation units  
> generally take more or less linearly more time to parse, but the  
> optimization time generally rises much more steeply (especially with  
> newer compilers that perform more inter-procedural analyses).

I think so. Also, putting everything in one source file means that
everything has to be recompiled with every change anywhere.

What's taking so long currently, Adriaan, is probably the GPI
imports. That's independent of the target, i.e. a Pascal to C++
converter would have to do it just the same, so its complexity is
independent of how the output is structured. As I said, this is a
separate issue which would be easier to tackle if the compiler was
written in a high-level language (such as C++ or Pascal with
templates). It's easier to find and experiment with efficient data
structures (e.g., hash tables, trees) when they're readily available
than when you have to manually implement them each and every time
like in C (for the current GPC) and also in Pascal so far.

BTW, is it the actual Mac OS X interfaces that are so huge, or your
wrappers? I remember you had a long list of string functions for
string types of various kinds and lengths. Using templates, they'd
shrink drastically.

Frank

-- 
Frank Heckenbach, f.heckenbach at fh-soft.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE  D101 CD02 4C9D 0FE0 E5E8