From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,30a9bb3017fa58dd
X-Google-Attributes: gid103376,public
X-Google-Thread: 1025b4,959627a08fbc77c5
X-Google-Attributes: gid1025b4,public
From: mrs@kithrup.com (Mike Stump)
Subject: Re: GNAT versions ( was :Ada compiler for PC?)
Date: 1999/05/07
Message-ID: <FBCAHD.Fqw@kithrup.com>#1/1
X-Deja-AN: 474993140
References: <7fndu7$im4$1@nnrp1.dejanews.com>
 <7gpsrd$qc7$1@nnrp1.dejanews.com> <FBAEH2.9C0@kithrup.com>
 <7gs0d5$lvh$1@nnrp1.deja.com>
Organization: Kithrup Enterprises, Ltd.
Newsgroups: comp.lang.ada,gnu.misc.discuss
Date: 1999-05-07T00:00:00+00:00
List-Id: <comp.lang.ada>

In article <7gs0d5$lvh$1@nnrp1.deja.com>,
Robert Dewar  <robert_dewar@my-dejanews.com> wrote:

>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'd be happy to answer any questions.

>I found no high level interface oriented description of the
>mechanism used for C++.

>I believe this could only have been achieved if we had started with a
>fully documented high level design.

You make it sound like it can't be achieved.  :-(

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);
    }
}

(thanks Per), you can just plug this in (or move it into the backend,
fix java to not include it), and just put in a call to emit_handlers.

That is the $0.05 tour.  :-) Now, admittedly, there are a few more
concepts to understand, like the cleanups in
TARGET_EXPR/expand_decl_cleanup _are_ run on an exception, for
example, but not that many more.