Please see below ... Joe.

-----Original Message----- From: Frank Heckenbach [SMTP:frank@g-n-u.de] Sent: Tuesday, February 12, 2002 7:16 PM To: gpc@gnu.de Subject: Re: gcc-3+

Russell Whitaker wrote:

...

found this at http://gcc.gnu.org/projects/

Miscellaneous ideas:

Chill should use garbage collection.

Convert the Chill front end to use garbage collection instead of obstacks, so that it can work again with current GCC.

Suspect this should apply to gpc as well.

Indeed. That's one of the main issues when moving GPC to gcc-3. Other issues are a numer of changed interfaces, though this will probably mostly be "mechanical" work.

[Joe da Silva] Well, the pragmatist in me says GCC-3 compatibility is more important than ideological misgivings about garbage collection. <G>

...

Any guess how much time and effort it would take to make the change?

According to a talk with Peter, it will be on the order of several days to a few weeks. If several people will work on it, it will be easier on everyone, of course. Are you interested in helping?

da Silva, Joe wrote:

...

IMHO, garbage collection is a kludge to fix memory leakage problems, which are a particularly common affliction with C, with it's particularly heavy reliance on pointers ... <BG>

Excuse me, but I think that's more of a prejudice here. What the compiler does internally relies heavily on tree structures. These require pointers in *any* language -- though some languages hide the fact. Pascal doesn't hide it, so the tree handling code and the resulting memory management problems would be exactly the same if GPC was written in Pascal.

Other typical usages of pointers in C, such as for strings, are relatively few in GCC/GPC, and are not the problem.

[Joe da Silva] My comments were general and relate to the excessive reliance of C on pointers, whereas Pascal often avoids them with safer alternatives, such as "var" parameters, etc. Of course, pointers are important and necessary in many situations (but I still consider garbage collection is a kludge for bad housekeeping - note also the <BG> ;-) My knowledge of the internal workings of GPC (compilers in general, actually) is next to zero, although I hope that one day this will improve. BTW, I do realize GPC is itself written in C, thereby taking advantage of the wide platform support of GCC (every cloud has a silver lining!;-). If this inter-dependence with GCC also means that garbage collection is a requirement, then "so be it" ...

The "obstacks" were something like a "half-hearted" garbage collector and cause(d) many problems, so it's good to get rid of them, anyway, even if gcc-3 would not require it.

Of course, there are other alternatives to GC, such as reference counting. But that's not without cost either: it requires traversing all structures to get rid of, which costs runtime and is even a little tricky in the presence of recursive structures. And it costs memory to store the reference counters while GC has no significant memory costs AFAIK (only runtime costs).

So, from the programmer's perspective, GC is probably the easiest to live with, and also at runtime, it might not be worse than the alternatives.

Or am I missing the perfect solution?

Frank

-- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html