TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Classic View

Use Proportional Font
Show Text Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Content-Transfer-Encoding: 7bit
Sender: "Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
From: Jeff Creem <[log in to unmask]>
Date: Mon, 18 Oct 1999 14:10:44 -0400
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Reply-To: Jeff Creem <[log in to unmask]>
Parts/Attachments: text/plain (38 lines)
> > My code looks much clearer if I use expressions like 2**4 instead of 16,
> > but
> > then there is the question of execution time also. I don't want the
> > calculation to take place over and over again, since the function is
> > called
> > quite often.
> >
>         [Borgia:]
>
>         You may want to try declaring the 2**4 expression as a constant,
> which guarantees a static value at compile time regardless of the
> implementation or level of optimization.  I hate code that relies on a
> particular optimizer anyway.
>


In this case I agree with you but in general I disagree with the
general feeling that you hate code that relies on a particular
optimizer. I have seen enough code that was written "hand Optimized" that
was probably slower and certainly less clear than the straightforward
code one typically produce.

For instance, at least under Ada 83 there was nothing that said that
a compiler had to pass an in parameter as a pointer even if it was large.

Also, I would not recommend falling back to address arithmatic just because
you get worried that the compiler does not support strength reduction
optmization.

But again, in this case, seems like the constant might be a better design
decision anyhow.

Jeff Creem

(P.S - For all of the versions of Rational compilers I have used (VADS and
Apex, 68000, MIPS PowerPC and
Solaris). Each of them would have optimized that code to a constant.

ATOM RSS1 RSS2