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.