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: stt@houdini.camb.inmet.com (Tucker Taft) Subject: Re: Beware: Rep spec on an enumeration type causes code explosion Date: 1997/12/06 Message-ID: #1/1 X-Deja-AN: 295746011 Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: houdini.camb.inmet.com References: Organization: Intermetrics, Inc. Newsgroups: comp.lang.ada Date: 1997-12-06T00:00:00+00:00 List-Id: Joe Gwinn (gwinn@res.ray.com) wrote: : ... : Exception handlers. We were declaring a number of exception handlers at : the beginning of each and every module, so every time the module was : entered, the context had to be saved, and every time the module was : exited, the context was popped off the exception stack and discarded, : regardless of if an exception was ever raised. This was easily solved; : now, only tasks declare exception handlers, not modules. I believe Green Hills is beginning to work on an implementation of exceptions that uses a PC-indexed table rather than setjmp/longjmp. However, as Robert points out, using such a table is significantly more machine-dependent, and generally requires coordination with the linker and more complex out-of-line algorithms in the run-time. As far as enumeration types, as others have pointed out, the Ada 95 standard requires that the internal codes for enumeration types are contiguous and start at zero, so you are not in any danger if you leave out your "confirming" representation clauses. It would be nice if our front end recognized "confirming" enumeration representation clauses, but as usual, there are many possible "optimizations" and this one never made it to the top of the list. One might argue that this is not really an optimization, but it does require special code to recognize, and so represents yet another "special case" that you have to decide the priority of recognizing. : ... : Memory Management. The Ada Runtime System makes extensive calls to the C : functions malloc() and free(), a cause for worry. It might be interesting to identify where this is really happening. Were these from calls in your source code to "new" and instances of Unchecked_Deallocation, or were they "implicit"? We have versions of our runtime which only use the heap "implicitly" for task control blocks (and these are recycled explicitly rather than using free) and for task stacks (and again, these are recycled rather than using free). So the only calls on "free" should be in response to an explicit call on an instance of unchecked-deallocation. Furthermore, we also have our own implementation of malloc/free which uses "quick fit" rather than the traditional C "first fit." This may be the algorithm : ... : Joe Gwinn -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA