From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=BAYES_00,TO_NO_BRKTS_PCNT autolearn=no autolearn_force=no version=3.4.5-pre1 Date: 25 May 93 20:26:07 GMT From: netnews!lab.ultra.nyu.edu!kenner@nyu.edu (Richard Kenner) Subject: Re: verdix kisses off Ada Message-ID: <1ttvcv$qsv@calvin.NYU.EDU> List-Id: 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.