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: heatwole@his.com (Kevin D. Heatwole) Subject: Re: Beware: Rep spec on an enumeration type causes code explosion Date: 1997/12/06 Message-ID: #1/1 X-Deja-AN: 295876744 References: Organization: Heller Information Services, Inc. Newsgroups: comp.lang.ada Date: 1997-12-06T00:00:00+00:00 List-Id: In article , 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.