Re: Beware: Rep spec on an enumeration type causes code explosion

[stt@houdini.camb.inmet.com (Tucker Taft)]

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