Re: verdix kisses off Ada

[netnews!lab.ultra.nyu.edu!kenner@nyu.edu (Richard Kenner)]

In article <1993May24.220351.22467@fcom.cc.utah.edu> val@csulx.weber.edu writes
:
>I've heard that since C++ has added exceptions, GNU (not the GNAT team) is
>in the process of rewriting the C++ compiler backend to support this.  The
>work of the GNAT team may or may not be rolled back into the backend by
>GNU.  (I'd appreciate hearing about this from a well informed source.  Is
>the co-director of GNAT still listening?)

Robert Dewar asked me to respond to this.

There are now three languages that want to use the GCC backend and
also support exceptions: Modula-3, Ada, and C++.  For a number of
months we had both in-person and email discussions of the issues
involved in implementing a common mechanism for handling exceptions
between the three languages.  We also anticipate adding extensions to
GNU C to support exceptions.

Since our goal in every other part of GNAT design is to allow full
mixing of languages, we want to ensure that the design of the
exception mechanism also permits this.  We decided, for now, to avoid
the language issues of how one language will refer to another's
exceptions and the fact that there are semantic differences between
what an exception is in the languages, and instead ensure that our
low-level mechanism is general enough to allow cross-language
exception catching if we could make sense of it at the language level.
But you will certainly be able to propagate an Ada exception up
through functions written in some other GCC-supported language to
another Ada subprogram.

We also need to support the various language "cleanup" features in
blocks and subprograms that are unwound when an exception is handled.
Again, this needs to be language-independent.

In addition, we want a "zero-overhead" mechanism that depends on
tables of PC ranges instead of having executable code set up exception
handlers.  Note that I put "zero-overhead" in quotes because the
mechanism is not entirely free.  In some cases register allocation
will be adversely affected and on some machines you have to execute a
"barrier" instruction when changing exception boundaries.

Finally, remember that we want this mechanism to work on all
GCC-supported targets, of which there are currently 27.  So we need a
method that handles at least three languages on 27 machines.  We also
do not want to our exception mechanism to impose too much of a burden
people who port GCC to a new architecture.

The current state of the design is that we understand how to solve
almost all of the problems.  Robert has written a draft of a long note
describing the scheme in detail.  However, we had to put this effort
aside for a while due to more pressing issues.  We expect to have this
document ready in the early summer and I will then start the
modifications to the GCC backend to implement them.  These
modifications should be included in whatever version of GCC is
released sometime in the fall.

As to whether the "GNU project" or "GNAT project" is doing this work:
I wear both hats.  Starting in a few months I will be taking over GCC
maintenance and development from RMS and will be 50% funded by a
consortium of interested companies.  The other 50% of my funding will
come from GNAT.