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,c0f035b936128b6c X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,c0f035b936128b6c X-Google-Attributes: gid1014db,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Ada95 to ANSI_C converter Date: 1997/04/04 Message-ID: #1/1 X-Deja-AN: 230825777 References: <5hbrah$ctt$1@gail.ripco.com> Organization: New York University Newsgroups: comp.lang.ada,comp.lang.c Date: 1997-04-04T00:00:00+00:00 List-Id: Jon says <> Well there is efficiency and efficiency, Bob Duff was cerrtainly not saying that the ICC compiler avoided inefficiencies in catching overflows, just that they tried to be efficient in handling overflow, rather different issues. If Bob DID mean to imply that ICC avoided all efficiency penalties in handling overflows in C generated code, that's just plain wrong! So, let's not obscure the semantics here. Generating C invoves fundamental inefficiencies in a number of areas, including catching overflows. That's the important point to register here. Yes, you can try to catch overflow efficiently, but you cannot avoid fundamental inefficiencies in the result. As I say, we know this area VERY well, because we are beginning to play more of these efficiency tricks in catching overflow in GNAT -- that will indeed improve efficiency, but it will NOT avoid all inefficiencies. The bottom line here is that there is a significant efficiency penalty in generating C, and it cannot be eliminated, no matter how clever you are!