Re: Why not gnat Ada in gcc?

[Laurent Guerby <guerby at acm dot org>]

I wrote:
> I don't think it is useful to argue on the source merging process right now.
Jeff wrote in reply:
> I would claim the opposite.  We need this to happen sooner, not later.
> The longer we wait, the more difficult our work becomes and the longer
> we have to deal with the problem of developers making changes, but 
> being unable to test that they haven't broken Ada. [...]

Hmmm, it looks like the issues you mention your last sentence are
solved by the mere inclusion of compilable GNAT sources in the CVS
repository (*), and I fail to see how this problem is affected by the
update policy once the sources are there. 

If a GCC developper is making a tree API change affecting Ada, either
he or she commits the Ada bits (in Gigi) that make the Ada compiler
happy and ACT will merge the changes in their own tree, or someone in
ACT followed the API change and will provide/suggest the needed bits.

(*) plus of course a test suite to help out non Ada developpers
working on the back-end or tree interface to see how they change
impact Ada, and to have Ada test cases for things in the back-end that
happens only from Ada code. That is why I proposed to work on getting
an Ada test suite up as a first step after inclusion of the
sources. This won't be an exciting new feature of GNAT (since ACT has
already lots of testing done, and big chunks of this is customer
proprietary code so it will never be public), but it will at least
make the Ada stuff GCC development process friendly.

Richard Kenner wrote:
> [...] I'm just pointing out that I think it's highly unlikely that putting
> it there will somehow bring lots of potential GNAT-modifiers out of
> the woodwork. [...]

In the short term of course no. The only thing is that with private
development sources and one source release per year, you're just
making sure that "potential GNAT-modifiers" stay "in their woodwork"
;-). 

Since people already working in the industry probably won't have time
to enter the front-end, I'm hoping students will do and this will take
a few years (I went this route ;-).

The compiler is not the only target for improvements, there's also the
runtime, which is a bit more accessible. For example, the tasking
stuff currently uses a POSIX thread adapter and works above that with
well known "semantic impedence mismatch" problems, however on
GNU/Linux the POSIX thread is already a layer above the clone system
call. Linus does not like that much the POSIX thread stuff ("broken by
design" ;-) but he recently introduced some bits in the kernel and a
challenge to the POSIX guyes to take advantage of it. May be the GNAT
tasking runtime could be adapted to use clone and a few other bits so
as to be more efficient and/or elegant on GNU/Linux. This is something
ACT has no big commercial incentive to do, but that would be helpful
to the GNU community. Small bits, the cos/sin/log/exp functions are
slower on GNAT/Linux than on GNAT/NT because the NT runtime has
inlined asm (from glibc!), and the GNU/Linux one doesn't. Etc...

There are lots of small improvements that ACT has no resource to do
that will probably happen reasonably early, the big stuff will
probably come much later (measured in years). I assume GCC/C
and GCC/C++ did not benefit from massive changes right after
the first source releases either.

> [...] I think what Laurent was trying to say was that it's best to
> not make that decision now, but instead to put the tree out there
> and *see* how many people make changes over a period of time and let
> that strongly influence the decision of what the best policy is.  I
> agree with that approaach. [...]

Good that we agree on this ;-).

-- 
Laurent Guerby <guerby@acm.org>