Linus on "regparm"
Joe Buck
jbuck@synopsys.com
Tue Aug 25 19:31:00 GMT 1998
> Quoting Carlo Wood (carlo@runaway.xs4all.nl):
> >
> > Linus, please realize that there are only about 6 or so people capable
> > of working on egcs, which is really a damn complex piece of code :/.
There are a lot more than 6 people working on egcs (front ends, ports,
testing), but there are only about 6 people who understand reload well
enough to take on the problem, and these are busy people.
There are only about 6 people capable of working on given areas in
egcs, but in many cases these are different people (e.g. the C++ front
end experts do not overlap the back end experts).
It appears that reload is rather old and brittle code, which only
wizards are advised to enter. These things happen when you have a
project that has been going on since 1985 or so.
> So it seems to me that it would make sense,
> if anyone of these 6 gurus would provide a good description
> about the main issues/concepts in egcs (e.g. dependencies and
> implications in egcs). This would make development slower in
> the first place, but egcs could gain a lot more developers
> in the long run.
There's an issue of timing. Linux 2.1 is evidently using an unstable
feature of gcc (note that it's also unstable in gcc 2.7.x if I understand
correctly, meaning that there may be risks there as well). Now it
isn't the Linux developers' fault for doing this, they did not know
that the code is in bad shape. Perhaps it can be fixed, but that
would take a considerable while. The question then becomes, do you
delay the release of egcs 1.1 for months (pissing off one group of
people), or ship now and cause problems for the Linux kernel developers
(pissing off another group of people)?
One possible solution is #ifdef -- Linux can conditionally use an
alternate implementation that avoids #ifdef's (which is presumably
lower performance), and can keep the heat on the egcs developers
by publicizing that there is a performance penalty (assuming, of course,
that the penalty is significant). This can be removed when the
problem is fixed.
More information about the Gcc
mailing list