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

[heatwole@his.com (Kevin D. Heatwole)]

In article <gwinn-0512972303070001@dh5055063.res.ray.com>,
gwinn@res.ray.com (Joe Gwinn) wrote:

>We just ran into a real zinger with the Green Hills Ada95 compiler
>(Solaris host, 68060 target, VxWorks 5.2 target OS), although it appears
>that the issue may be common to all Ada95 compilers.  

Sounds like the Green Hills compiler might just be a little green.  :-)

I wouldn't generalize your experiences to all Ada95 compilers though.  Some
are much more mature.  For example, the problem with entering/leaving
scopes with exception handlers causing setjmp/longjmp-like calls to be
performed is probably more related to Green Hills probably reusing their C
code generator with the Intermetrics Ada95 front-end.  Since C doesn't have
exception handlers, they probably just threw in the calls to setjmp/longjmp
since it was easier than trying to get the C code generator to support a
more table driven implementation for exceptions (so use of
exceptions/handlers don't incur any time penalty unless an exception is
actually raised).

Many of the Ada frontends that have been glued to backends that were
originally designed to support the C language have similar problems early
on (until the backend can be modified to support Ada features more
efficiently).  For example, I believe that the GNAT compiler had problems
implementing some overflow checks efficiently on some targets since the
backend (which hadn't been modified yet for Ada) didn't support easily
detecting overflow and turning this into an exception.
So, GNAT suppresses these checks by default and makes you ask for them.

Also, range checks can be inefficient on some hardware when using a C
oriented backend for the Ada compiler.  It is easy to implement these
checks using "if" statements in the backend and raise constraint_error if
the check fails.  On hardware, such as the PowerPC (which I work on
exclusively), it is much more efficient to implement range checks using
"trap" instructions that can be almost free (unless the trap is taken, then
the runtime needs to propagate the exception).

As for inefficient handling of enumeration types because of a rep spec, the
compiler should not revert to a slower implementation if the rep spec
doesn't add holes in the range of underlying values.  This is probably just
a sign of an immature compiler and this problem should be fixable by the
vendor if the vendor is responsive to its users needs.  It is a fact that
users need to be vocal in providing feedback to compiler vendors to get
them to address issues that are affecting their ability to deliver code
that meets application requirements.  If your vendor isn't responsive in
addressing your problems and working with you to be successful, you should
probably take your business elsewhere.  Ada compilers are very complex
beasts and no compiler is going to handle every Ada construct perfectly
with respect to minimal execution time, but compilers generally improve
with time and successful use (provided the vendor is committed to evolving
the implementation).

For the record, I work for an Ada95 compiler vendor (OC Systems) and I
would hope our users would feel that we are responsive to their
concerns/needs and that we would respond by doing whatever is reasonable to
make the user successful.  This sometimes involves short term workarounds
and some flexibility by the user in being open to solutions (not all
features in Ada have efficient implementations or not all compilers can be
adapted to implement a feature in a different way without adversely
affecting other parts of the implementation).   But, I believe that other
Ada vendors have similar goals in providing high quality Ada implementions
(especially those vendors that derive a significant portion of their
revenue from Ada sales/support).  Note that I have had no experience with
Green Hills products and do not know whether Joe's experience is typical.

Anyway, don't paint all Ada95 implementation with the same brush and not
all vendors provide the same level of support.

Kevin Heatwole
OC Systems, Inc.