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=0.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,9da298537a16487e
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 1995-01-12 07:11:22 PST
Path: 
 nntp.gmd.de!Germany.EU.net!wizard.pn.com!satisfied.elf.com!news.mathworks.com!hookup!olivea!uunet!newsgate.watson.ibm.com!watnews.watson.ibm.com!ncohen
From: ncohen@watson.ibm.com (Norman H. Cohen)
Newsgroups: comp.lang.ada
Subject: Re: Run-time checking and speed
Date: 12 Jan 1995 15:11:22 GMT
Organization: IBM T.J. Watson Research Center
Distribution: world
Message-ID: <3f3gqq$kts@watnews1.watson.ibm.com>
References: <3ev16u$ojc@pong.lasc.lockheed.com>
Reply-To: ncohen@watson.ibm.com
NNTP-Posting-Host: rios8.watson.ibm.com
Date: 1995-01-12T15:11:22+00:00
List-Id: <comp.lang.ada>

In article <3ev16u$ojc@pong.lasc.lockheed.com>, tony@deepthought.Sgi.COM
(Tony Leavitt) writes: 

|> -- CASE 1
|> -- This case seems to need all of the full run-time checking since
|> -- the variables x and y can be unlimited when accessing the array.
|>
|> XY_array : array (integer range 1..100, integer range 1..100) of float ;
|>
|> for x in 1..100 loop
|>   for y in 1..100 loop
|>      XY_array(x,y) := calc_something  ;
|>    end loop ;
|> end loop ;

No, the loop bounds are given by compile-time constants, so any compiler
that leaves the run-time checks in (at least with optimization turned on)
is a junk compiler.  (By the way, on each iteration of the inner loop, x
and y are CONSTANTS, so there is no possibility of "calc_something"
changing their values by a side effect.  x and y are well defined to
range over 1 .. 100.)

|> -- CASE 2
|> -- This case it seems that no runtime checking is needed when
|> -- accessing the array since x and y are, by definition, within
|> -- the array bounds (assuming memory doesn't go bad while running).
|>
|> subtype arraybounds is integer range 1..100 ;
|>
|> XY_array : array (arraybounds, arraybounds) of float ;
|>
|> for x in arraybounds loop
|>   for y in arraybounds loop
|>      XY_array(x,y) := calc_something  ;
|>    end loop ;
|> end loop ;

This example is precisely equivalent to the previous one.  The subtype
declaration essentially makes the identifier "arraybounds" a shorthand
for the subtype indication "integer range 1 .. 100" (and the iteration
scheme "for x in 1 .. 100" is a shorthand for "for x in integer range
1 .. 100").

|> -- CASE 3
|> -- This seems similar to CASE 2
|>
|> XY_array : array (integer range 1..100, integer range 1..100) of float ;
|>
|> for x in XY_array'Range(1) loop
|>   for y in XY_array'Range(2) loop
|>      XY_array(x,y) := calc_something  ;
|>    end loop ;
|> end loop ;

Again equivalent.  Given the declaration of XY_array, XY_array'Range(1)
is essentially a shorthand for "1 .. 100".

General rule: Trust your optimizing compiler to eliminate the checks that
are obviously unnecessary (or get a new compiler if this trust turns out
to be misplaced).  The only ones you have to worry about are the ones
that are unobviously unnecessary, and even then only if you have observed
a performance problem and determined that the run-time check is a
signficant contributor to it.

Here's a more interesting example: 

   type Index_Subtype is Integer range 1 .. 100;
   A   : array (Index_Subtype, Index_Subtype) of Float;
   Row : Index_Subtype;
   ...
   for Column in A'Range(2) loop
      A(Row, Column) := calc_something;
   end loop;

The value of Row is guaranteed to be in range PROVIDED THAT Row HAS BEEN
ASSIGNED A VALUE.  Ada 83 rules allowed compilers to omit the index check
on Row, on the grounds that if Row was not initialized execution was
"erroneous" and any behavior was allowed to ensue.  It was controversial
whether a compiler SHOULD omit this check.  In Ada 95, the check can
still be eliminated if the compiler can determine that Row has been
assigned a value before the loop is reached.  In any event, a good
compiler will move the check out of the loop so that it is only done
once.

--
Norman H. Cohen    ncohen@watson.ibm.com