If you maintain that those internal "wavefront" releases cannot
introduce a regression, might it be the case that ACT wastes time
by running full regression tests before a release ?  If so, then
you can dismiss all the alleged "added value" Robert spoke about
from their extensive test battery and just make your own changes
to the compiler.

In fact, if you are so upset about the way ACT behaves, you can set
up a competing GNAT development effort.  When the time comes, however,
for me to pay money to a vendor for GNAT, and I have my choice between
a vendor who tests and a vendor who doesn't, I have no question about
which way my decision would go.

I suspect there *are* situations that are murky, for
example surrounding the GCC work being done for Merced, but
at ACT we never have any restrictive requirements, since,
as noted above, these would clearly violate the GPL, and
you are right, to have such restrictions would make no
sense, which is why the GPL does not permit them.

Robert Dewar
Ada Core Technologies

  One or the other doesn't

But more to the point, the great majority of our ongoing
development effort relates to new features, new tools,
new packages, improved performance etc.

Here is a brief excerpt from the features file for the
forthcoming 3.12 releases. I will post the whole of this
when we freeze the 3.12 sources, which has not happened
yet.

  The compiler is now built with options -gnatpn instead of
  -gnata. This means that the front end of the compiler is
  considerably faster, up to 2-3 times faster in some
  cases. The cases where you will see the biggest speed up
  are in -gnatc compilations with no code generation, or if
  very large specs are with'ed from smaller units.

  If pragma Suppress is used in the gnat.adc file, this now
  properly
  suppresses exceptions in all files compiled in the
  presence of this
  gnat.adc file (Suppress pragmas in gnat.adc were
  previously ignored,
  which is in accordance with the RM, but certainly not
  what is wanted!)

  On Digital Unix 4.0D, the run time now takes advantage of
  the full
  range of priorities (0 .. 63).

  In -gnatc mode, an existing up to date ali file is no
  longer destroyed.
  In particular this means that the -gnatc -gnatt
  compilations used by
  ASIS do not destroy existing ali files.

  A new switch -gnaty activates style checking features in
  the compiler.
  These roughly correspond to the checking done by the
  special internal
  -gnatg flag, except that -gnaty allows extensive choice
  of which checks
  are to be performed, and also allows parametrization,
  e.g. of the indent
  level that is enforced.

  The handling of aggregates has been optimized in many
  cases, generating
  more efficient code and less memory usage.

  The binder now generates an Ada package as the main
  program by default
  instead of a C program. The generated files are called
  b~xxx.ads/adb,
  where xxx is the name of the main program. The -C switch
  for both
  gnatbind and gnatlink can be used to get the old behavior
  of generating
  the main program in C.

This is just a small excerpt (the full features file
entry for 3.12 is about 200 lines long and growing), but
this should give you a feel for what continued development
is about.

Indeed our support activities these days are far less
focussed on fixing bugs than helping people use Ada 95
and GNAT features successfully -- though of course the
bug fixing activity is an important component still!

Robert Dewar
Ada Core Technologies

Since we merge *from* Egcs to our internal tree, rather than
vice versa, the check-in policy at Cygnus is:  Nothing gets
into our internal tree unless it is in Egcs *or* specially
marked as being Cygnus only or "sanitized".  That should make
it obvious that the default is to check things into Egcs
first or at the same time.

For example, suppose that Cygnus did a Merced port for
Intel, then Intel could not give it to anyone else, e.g.
to develop a Linux for it, with non-disclosure restrictions
that would prevent them from distributing it.

One of the interesting points of the GPL is that it allows
ONE organization to do internal work in complete secrecy,
unhampered by GPL restrictions of any kind, but this
does not extend to two companies working together, because
every time they send a copy between them, it must be sent
in unrestricted manner.

I should say that I have discussed this point explicitly
with Richard Stallman, and he agrees with this assessment
of both the intent and effect of the GPL.

On the contrary, as with many other volunteer activities,
the critical thing is for the time of volunteers to be
supported adequately, and indeed ACT put substantial
resources into assisting with the continued maintenance
of GCC, something that benefited us, but also benefited
the larger GCC community.

A similar situation arises with Cygnus today, they invest
substantial resources to help with the maintenance of the
Cygnus tree, and those resources are enormously helpful to
the gcc community at large, not just to Cygnus.

That leads some people to harbour suspicions
that Cygnus really secretly controls the process and
somehow twists it to serve their own ends, but really this
is quite absurd, and does not correspond at all to the
reality of the situation.

To draw the inference you suggest here is equally absurd
(as well as being quite unfair to those involved!)

Robert Dewar
Ada Core Technologies

While I find no wrong with that, it would be foolish to deny that the
willingness to invest a large amount of work in GCC *does* have a
large influence on what direction the compiler development is taking.

If a few larger vendors realized this somewhat more (Intel seems to
have waken up to it somewhat recently), this could only help GCC
development.  CPU manufacturers actually should have an even larger
interest as Cygnus in getting actively involved in GCC.  It lends
large value improvements to their products with minimal costs.

A similar situation occurs with GNAT. Since ACT makes
almost 100% of the changes to GNAT currently (we only
very rarely get patches submitted, almost all of which
have been immediately incorporated), ACT gets to make
the decisions on which features go in etc. This is of
course based primarily on the needs of our paying
customers.

(two of the the most notable volunteer contributions to
GNAT were the DOS port by Doug Rupp, and the OS/2 work
by Geert Bosch, and not only did we acquire this work,
but Doug and Geert now work full time for ACT/ACTE.)

If the GNAT/Linux project ends up encouraging more useful
contributions, particularly in the tools and binding area,
then it will begin to have a significant influence on the
direction of the GNAT development, and that is welcome all
round as far as I am concerned.

There are some other interesting developments such as
David Botton's work on COM interfacing on NT, and ACT
is definitely interested in working closely with anyone
doing useful development that is GNAT related.

Robert Dewar
Ada Core Technologies

The concerns about exceptions had nothing at all to do with GNAT. This
is simply a guess on Per's part, who as he says, does not know the
issues. The concern was on technical issues (such as thread safety,
which of course are language independent), and on the documentation
issues.

I think Per's continued implications that perhaps Richard was working
deliberately against Cygnus interests because ACT was a competitor are
pretty bogus on the face of it. ACT's interests have been very
specifically in Ada (consider the name of the company!) And as far as
we know Cygnus has had zero interest in Ada.

In practice, the issue was indeed to a considerable extent one of
too much work for any one person. ACT funded a lot of Richard Kenner's
time to work on gcc in practice, so that it could indeed be his day
job, but even so, there is a lot for one person to do, and furthermore,
it is pretty hard to please everyone in a situation like this.

But in general I would advise Per to investigate thoroughly the
circumstances of both EGCS at the start, and the exception issues,
before making guesses. Even with the disclaimers that he does not
know the issues, such guesses can be misleading.

Robert Dewar
Ada Core Technologies

I don't think any of this was related to GNAT.  My take is just a
simple conflict of styles.  It only delayed EH by 2-7 years.  My
choice, would have been to not delay it, and just get it working, then
working well, then well ported, then clean up the interfaces and
documentation.

I resisted doing it his way, and he resisted accepting it my way.

I don't yet understand the benefit of delaying EH, maybe in time I
might...

We are setting up to do the full regression run now, and should have
results soon. Certainly the 3.12 source base is the right one to
include in the next EGCS release.

design and document the interfaces
refine the interfaces till they are correct
then implement

I find the style of doing things backwards worrisome, though I
realize it is common enough, especially in the C community.

We certainly follow this procedure internally at ACT. If someone
thinks a new feature is useful, then first we have a general
discussion of the idea, then we design the feature (e.g. package
specs are produced and reviewed), then we do the implementation
of the bodies. I doubt this description of normal software
design procedures seems strange, at least I would expect it
was entirely familiar to the comp.lang.ada users reading this!

The trouble with doing things backwards is that you are realying
FAR too heavily on testing alone as the criterion for correctness.
Even if there were a comprehensive and systematic test suite,
including significant amounts of code, testing is never sufficient
on its own to ensure that your design is correct.

I must say I am a little puzzled by Mike's reluctance to document
things. If EH was really delayed 7 years because of this (I think
that's a bit of an exaggeration :-) it is a pity ...

As to whether one should bend the rules and allow things to be
implemented without documentation, and instead hope for documentation
to appear later, it's hard to say. Sometimes you DO have to make
this compromise, but it often does not work out well. The trouble
is that many people who have this code-now, document-later approach
have a lot of trouble coming through with the documentation later.

For me personally, writing well documented code is a pleasure, sort
of like writing a text book that students like to read. If code is
accessible and easy to understand, and good documentation is part
of the reason, then that is a pleasing achievment in itself. I get
the impression that a lot of programmers don't share this view, and
find documentation a nuisance -- too bad.

P.S. I still find the documentation of the exception handling stuff
in GCC inadequate. This may be just lack of skill on my part in
reading C code of this kind (clearly there is an expectation that
you figure out some of the details of the specification by looking
at the details of the coding, which I find uncomfortable.

One unfortunate consequence is that the GNAT exception handling has
been developed entirely independently, and I suspect that there
could be more merging, though I am not sure of this, because to have
an exception handling mechanism usable by both C++ and Ada 95, a
perfectly reasonable goal, would require careful examination of
the specifications *before* starting to implement.

Anyway, I do agree with Mike on one important point, the exception
handling requirements for GNAT had nothing at all to do with the
development of EH handling in GCC!

This experience shaped and drove my implementation, the implementation
that now exists in gcc.

I would anticipate that it did the same for the Ada implementation.
If true, they are closely related.

:-)  Yes, I know you already knew that.  I say it, just to nag a little,
in hopes that Ada will embrace the functionality that is now there and
extend it.

I did the design and implementation of the exception handling in
Ada, so I am pretty familiar with what was and was not done. Yes
there were early discussions about trying to deal with commonality
between the languages, but unfortunately these did not result in
a common facility. I tried to understand what had been done for
C++ but failed. Others here at ACT are still trying to do more
merging here, but it is not easy. I found no high level interface
oriented description of the mechanism used for C++. Perhaps I
simply did not look hard enough, or just did not know how to read
the code correctly. I find the back end of GCC rather difficult
to navigate (and indeed in a recent email Per Bothner (hope I
remembered the spelling right) claimed that the entire gcc compiler
was ill-documented so why single out the exception handling). I
find that position FAR too pessimistic, and indeed in general the
gcc backend is documented a lot better than many proprietary
compilers with which I am familiar, but in this particular case,
we have not yet achieved the ideal of merging the exception handling
of C++ and Ada. I believe this could only have been achieved if we
had started with a fully documented high level design.

Again, this may simply be a different way of working, here at ACT,
we really aren't very good at roaming around code and figuring out
what is going on, we depend on a very structured design approach, so
there is undoubtedly a bit of a culture clash :-) :-)

(IMNSHO that is the main problem with the current egcs EH - too much
executable bloat)

It would be great if the best points of both could be merged.

As far as unwinding goes, on DEC Unix, we use the standard DEC Unix
library calls for unwinding, and on SGI, we use the standard SGI
routines. On the x86, we do prolog interpretation, which is very
messy but is highly space efficient. On Solaris, we plan to use the
standard gcc mechanism, but have not figured it out yet.

Now, back to the first part...  There are roughly three routines to
call, one starts a region, one ends it, and the last to emit the
region handlers.  My hope was it would be easy to understand/use.

/* Start an exception handling region.  All instructions emitted after
   this point are considered to be part of the region until
   expand_eh_region_end () is invoked.  */

extern void expand_eh_region_start              PROTO((void));

/* End an exception handling region.  The information about the region
   is found on the top of ehstack.

   HANDLER is either the cleanup for the exception region, or if we're
   marking the end of a try block, HANDLER is integer_zero_node.

   HANDLER will be transformed to rtl when expand_leftover_cleanups ()
   is invoked.  */

extern void expand_eh_region_end                PROTO((tree));

/* Called from expand_exception_blocks and expand_end_catch_block to
   expand and pending handlers.  */

extern void expand_leftover_cleanups            PROTO((void));

The first two are meant to be fairly easy to use, maybe you can
explain what you found hard to use about them, and I can clarify.

The last is somewhat magical, and really should be buried deeper into
the backend.  Maybe if we can move the exception specifications into
the backend, the reason for not having it in the backend can be
removed.  But, if one reads what java does:

void
emit_handlers ()
{
  if (catch_clauses)
    {
      rtx funcend = gen_label_rtx ();
      emit_jump (funcend);

      emit_insns (catch_clauses);
      expand_leftover_cleanups ();

      emit_label (funcend);
    }

design and document the interfaces
refine the interfaces till they are accepted by peers
implement (this may infere a few changes in the interfaces)
document the interfaces "as built".

--

For example, for one project I did for Honeywell, a full real time
executive, with thread support, synchronization primitives, integral
debugger etc, was done by FIRST writing the user reference manual
documenting the API in completely detail, THEN writing the executive
(some 50,000 lines of assembly code). very few changes were required
to the manual, almost all stylistic copy-editing stuff (they hired
an English PhD to look over the manual and I had to let her make
a *few* changes to avoid her completely destroying important technical
stuff :-)

But in any case our discussion here is over detail. Either approach
is very far from the "implement first, document alter if at all"
method :-)

Robert Dewar