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>
Joe.
-----Original Message----- From: Russell Whitaker [SMTP:russ@ashlandhome.net] Sent: Tuesday, February 12, 2002 4:37 PM To: gpc@gnu.de Subject: gcc-3+
Hi 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. Any guess how much time and effort it would take to make the change?
Russ
da Silva, Joe writes:
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>
... remembering that gpc _is_ written in C ;) gcc-3+ uses garbage collection internally instead of obstacks.
-----Original Message----- From: Russell Whitaker [SMTP:russ@ashlandhome.net] Sent: Tuesday, February 12, 2002 4:37 PM To: gpc@gnu.de Subject: gcc-3+
Hi 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. Any guess how much time and effort it would take to make the change?
Russ
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.
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.
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
On 12 Feb 2002 at 9:16, Frank Heckenbach wrote:
[....]
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?
If Peter can provide a list of tasks that need doing, we can then assign the tasks to volunteers, according to; [a] their knowledge of C [b] their knowledge of the compiler
My knowledge of either is quite rudimentary, but I am willing to help. At least, I might be able to do some "mechanical" tasks. These are probably the most tedious, and it is a waste of Peter's and Frank's expertise for them to have to spend significant time on mechanical tasks (e.g., those that can be done by anybody).
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Email: African_Chief@bigfoot.com http://www.bigfoot.com/~african_chief/
Prof. A Olowofoyeku (The African Chief) wrote:
On 12 Feb 2002 at 9:16, Frank Heckenbach wrote:
[....]
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?
If Peter can provide a list of tasks that need doing, we can then assign the tasks to volunteers, according to; [a] their knowledge of C [b] their knowledge of the compiler
My knowledge of either is quite rudimentary, but I am willing to help. At least, I might be able to do some "mechanical" tasks. These are probably the most tedious, and it is a waste of Peter's and Frank's expertise for them to have to spend significant time on mechanical tasks (e.g., those that can be done by anybody).
Apparently I slightly misunderstood Peter last time. He has already done most of the mechanical tasks, to the point where it would compile, but not work with egcs-2.97, while the more difficult tasks are left to do. :-(
Now, there might be some differences from 2.97 to 3.0 (I don't know how big). So this would be one task, testing if GPC compiles with gcc-3.0 at all and if not, make it to. Some or all of it has already been done:
Both Matthias and Russ have sent me versions of the backend diffs for 3.0. They are in the diffs directory. One obvious thing would be to compare their versions, and if they differ in more than the diff format, to sort out the differences.
They've also sent me versions of Makefile.in and Make-lang.in, but since we've stopped using different makefiles for different backend versions (this was unmaintainable), these are not included. I could probably dig out their versions from the mails, or they could find them themselves. Anyway, what needs to be done is to find the actual changes and do them via some make variables (as is done now for the differences between gcc-2.8.1 and 2.95.x, look for `gcc-2.8.1-ONLY' in the makefiles). Some corresponding code in config-lang.in should set them (as is done now for the older versions). That's a job for someone who knows makefiles and shell scripts, probably Matthias and Russ are best suited since they've already worked on the makefiles.
Then try to compile the whole stuff and fix any problems. Likely problems are slightly changed interfaces (an added parameter or `const') which must be reflected in the invocations. In many cases, this has already been done, often using `#ifdefs', so you'll find some examples in the code. (Look for `EGCS97' -- BTW, it may or may not be worth renaming this to GCC3_0 -- when everything's completed, these ifdefs can vanish, aynway.)
Maybe there will be undefined references at link time. These are probably functions the backend expects to be provided by the frontend. In some cases they can be dummies (cf. the other language frontends). If some of them need real work, that's probably a task for Peter, however.
Perhaps there are some references to the obstack stuff (which vanishes in 3.0) left in GPC. Though Peter think he's ifdef'ed out all of them, if some are left, just do the same with them. (Of course, never change the behaviour WRT non-"EGCS97" unless you're sure what you're doing.)
When everything compiles, that's a first step, but it will not work. There are already "work-arounds" for existing differences that enable it to compile only, but will require more work (again, done by Peter) to function.
Another task affects the garbage collector. It somehow requires all "roots" of the trees to be registered (so it knows what to keep). I don't know details yet, but basically all global variables of type `tree' (or structures containing such fields) must be handled specially. A help would be to look through all source files (i.e., parse.y and *.c except parse.c), collect them in one place (I suppose in util.c is a good place) and perhaps mark them (i.e., not every single one, just the beginning and ending of the block) with a special comment, to make it easier for Peter to find and handle them all. Some of them are `static' (which in C means visible only in one source file). This must be changed if they must be moved to another source file, and they must be declared in the header (util.h). (This does not have to be done ifdef'ed -- in fact, testing that GPC still works with gcc-2.8.1/2.95 afterwards can give an indication that no mistakes were made.)
Most of the rest seem to be harder tasks that only Peter really has the knowledge to do (though perhaps I can do a few of them, but I'm not sure). We agreed that he will do this as the next major thing in GPC (when he has the time for major GPC work), i.e. before qualified identifiers and other things.
Frank
PS: If you want to do one of the tasks *now*, please wait for the next RC (hopefully soon). I've done some major changes in the last several weeks (hopefully the last major ones before 2.1), and changes to the "old" sources would most likely cause conflicts now.
-
da Silva, Joe -
Frank Heckenbach -
Matthias Klose -
Prof. A Olowofoyeku (The African Chief)