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,ca9eef4d5e2078ea X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Beware: Rep spec on an enumeration type causes code explosion Date: 1997/12/06 Message-ID: #1/1 X-Deja-AN: 295718325 References: X-Complaints-To: usenet@news.nyu.edu X-Trace: news.nyu.edu 881402931 9370 (None) 128.122.140.58 Organization: New York University Newsgroups: comp.lang.ada Date: 1997-12-06T00:00:00+00:00 List-Id: Joe Gwinn said <> Just so it is clear, this is by no means a necessary consequence of the Ada language (and indeed the situation with exceptions is essentially identical in C++). The issue is how exceptions are implemented. It is indeed much easier to handle exceptions by doing context saves on entry to an exception frame, and then popping them off. Particularly in tasking environments (where the current task context must be accessed to determine where to store the context), and on RISC machines (where saving the context can mean saving dozens of registers), this can be a very expensive approach. With GNAT, we even discovered that Sun, for no good reason at all, was doing a system call as part of setjmp! In the case of GNAT, we used to use the system setjmp/longjmp for this purpose, but, particularly because of the idiotically inefficient design of setjmp in Solaris, we replaced this with our own builtin setjmp that is much more efficient, but that is still only relative. Really what is intended and expected by the Ada design is a "zero cost" approach where the declaration of exception handlers costs nothing, and you pay a price only when an exception is raised. This is done by building appropriate data tables, so that the exception handler can figure out how to restore the context without having wasted time saving it. Such zero cost exception handling approaches are not science fiction, rather they are pretty standard in the Ada world. I assume that the new Aonix Object Ada has zero cost EH (the reason I assume this is that the runtime is based on the old Alsys technology, and I helped write the zero cost exception handling for this old technology :-) I certainly know that Verdix Ada 83 technology uses a zero cost approach. The difficulty with the zero cost approach is that it tends to be highly machine dependent, and that is one of the reasons that it is been difficult to do in the GNAT environment, which is so committed to machine independent approaches. Nevertheless we regard switching to a zero cost exception scheme in GNAT to be our highest priority technical improvement to the system, and indeed it happens to be exactly what I am working on right now (I am answering this while waiting for a new version to build that incorporates some of the necessary changes). This will first be built for the SGI version (that's because SGI is funding some of the technical work for this modification), but will be propagated to other versions soon after. The bottom line here is that this is something you need to beat up on your vendor about! Some of our customers have complained loudly at this problem in GNAT, and as usual, the technical direction of GNAT, like any other commercial compiler, is quite sensitive to user needs :-) :-) We know at least one customer who would like to switch from Verdix (Rational) technology, but this one inefficiency is holding them up (that's an SGI customer, and hopefully the problem will be resolved very shortly, and they will be able to do the switch they would like to). If you have a style of programming which requires very large numbers of exception handlers, then this is one of the aspects of compiler performance that you need to carefuly evaluate. It is most certainly an issue that you need to be aware of when using a language like Ad or C++ that supports exceptions. Robert Dewar Ada Core Technologies