This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Why not gnat Ada in gcc?


> To: dewar@gnat.com, law@redhat.com
> Cc: gcc@gcc.gnu.org, kenner@vlsi1.ultra.nyu.edu, rms@gnu.org, rth@cygnus.com
> Date: Wed,  1 Nov 2000 22:31:12 -0500 (EST)
> From: dewar@gnat.com (Robert Dewar)

> Yes, but of course you cannot deal with daily instability for actual
> commercial development for large scale customers who depend on
> absolute stability.

There are solutions to this.  First, notice that exporting of work
from such a quality environment to a lesser quality environment
(ACT->FSF) is a no brainer.  Only the forward direction matters.  This
you can `time' anyway you want, depending upon any business reason you
need to.  Further, you can test the source before import, and only
after testing, use it as a base for the import.  Or, alternatively,
you can declare your source dirty (needing testing), run the import
into your environment, and then test and fix it, then after declare it
safe again.


I don't know why as many emails about this matter have flown by.  All
the technical problems, have technical solutions.  If your message
doesn't have a technical problem, or a technical solution to a
discussed problem, let's hold back on those emails.  After Ada is
integrated, and chugging away, then we can address the next round of
issues, like please update more often, please check in code to our
tree first, who is gonna play in my code, why aren't you testing our
tree...  We can't have those problems, until after we get part the
first one.

> Incidentally, one thing that I do NOT think is addressed well enough in
> the GCC development process is performance issues. As far as I can tell
> there is very little systematic performance testing,

First, you don't get to complain, if you haven't contributed a single
testcase that measures performance.  After you donate one, then you
can.  After you show us all how it's done, then we can follow your
lead.  I think it is trivial:

TIME a;
STARTTIME(a);
blabla
ENDTIME(a, importance_factor, "testcase subdescriptor");

...

and then you arrange for these bits to be exposed to the testcases.
ENDTIME does a:

	printf("PERF: %f %s %s\n",
		(endtime-starttime)*importance_factor, TESTCASENAME,
		testcase_subdescriptor);

You then have an analysis package that can do rmses of old-new from
the perf lines, and viola.  I've just not had a minute to donate the
infrastructure and a testcase.

If someone wants to pay for one, I think Mark has lots of free time
(Hi Mark).

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]