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,FREEMAIL_FROM,
	INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,c7d533acec91ae16
X-Google-Attributes: gid103376,public
From: Corey Ashford <yeroca@rocketmail.com>
Subject: Re: Question for the folks who designed Ada95
Date: 1999/04/28
Message-ID: <3726AA42.C8171393@rocketmail.com>#1/1
X-Deja-AN: 471780163
Content-Transfer-Encoding: 7bit
References: <7g2qu4$ca4$1@usenet.rational.com> <7g4jqm$1rkg@news1.newsguy.com>
 <7g4mic$1sr0@news2.newsguy.com>
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
Organization: Rational Software
Mime-Version: 1.0
Newsgroups: comp.lang.ada
Date: 1999-04-28T00:00:00+00:00
List-Id: <comp.lang.ada>

Samuel Mize wrote:
[snip]
> Besides the points in my other post, I'd note that Ada generally
> assumes you're using a compiler that optimizes well, if optimization
> is an issue.  So we expect the compiler to manage things like deciding
> whether to shift or divide, and the programmer manage things like data
> structures, algorithms and high-level programming constructs.  If you
> have to hand-optimize a million-line program, you're doomed anyway.
> 
> When you *do* need to worry about it, for some small program or for a
> crucial section, you can generally find an optimal way to code things.
> But this isn't the first concern of the language, so the first approach
> you think of won't always be the right one.
> 
> If you have to worry about line-by-line efficiency, you really have to
> cuddle up to your compiler and learn a lot about it.  But that's true
> for any language.  It's easier in C to convince yourself that you're
> hand-optimizing something, but I've seen cases where doing so caused
> SLOWER execution times, because the higher-level version was more
> amenable to machine optimization.

Thanks for all your thoughts, Samuel.

A couple of comments:

1) I decided not to go with divides and multiplies because the amount of the
shift that I need in my code is variable, so the expression would have to
be of the form  x * (2 ** y), where y is the amount of the shift.  I'd bet
most compilers and optimizers aren't set up to recognize this case as a variable
shift.  In fact, I know Apex doesn't because I tried it at full optimization.
Currently the compiler ends up treating it as a generic exponentiation operation
and calls a runtime routine for exponentiating modular values.  Note that Apex
does a fine job with x * (2 ** K), where K is a static constant, optimizing this to
a shift.

2) The code I'm writing is very time critical and has to use shifts.  I can't
afford for the compiler to generate any other code.  Believe me.  It ain't
a million lines... it's pretty small really, but it has to be portable across
several architectures and ABI's (64-bit vs. 32-bit, etc.).

3) Doing conversions to Interfaces.Unsigned_32 (or the like) doesn't work.  The
code has to be able to run on both 64-bit and 32-bit machines, and I need to
use the largest modular type possible.  On a 64-bit machine, it would be
Unsigned_64, but Interfaces.Unsigned_64 doesn't exist in the Interfaces package
on a 32-bit machine, so I would get a compilation error there.

So, using a combination of "type largest_modular_type is mod system.max_binary_modulus;"
and the "pragma import(Intrinsic, ...);" nicely solved the problem, at least for
Apex.

Thanks again,

- Corey