Re: Question for the folks who designed Ada95

[Corey Ashford <yeroca@rocketmail.com>]

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