Re: Precalculation of parameters (was: Software landmines)

[stt@houdini.camb.inmet.com (Tucker Taft)]

dennison@telepath.com wrote:

: In article <Eyz7Co.J4t.0.-s@inmet.camb.inmet.com>,
:   stt@houdini.camb.inmet.com (Tucker Taft) wrote:

: > By the way, the original point that a "smart" compiler can parallelize:
: >
: >    Op(Get_A(..), Get_B(..), Get_C(..))
: >
: > more easily than the "sequential" form involving named constants is a
: > bit bogus.  To parallelize, the compiler needs to prove that Get_A,
: > Get_B, and Get_C don't interfere with one another.  Given that, there
: > is no reason that the "sequential" form couldn't be parallelized as well.

: But if the language specifically states that the order of evaluation of
: parameters is undefined, then it doesn't have to prove they don't interfere.
: It can just assume they shouldn't. 

Running two computations in parallel is very different
from running them in an "arbitrary" (but still sequential) order.  
Suppose each function adds one to the global variable "Count".  You 
get the same result independent of which order the functions are 
evaluated, but you don't get the same result if you run them in parallel,
and the machine instructions involved in adding one to the
global are interleaved arbitrarily.

: ... I don't know if that's the way Ada is
: defined, but I believe that was the claim that was being made.

: Is that actually the rule?

RM95 6.4(10) permits evaluation of parameters in an "arbitrary"
order.   RM95 1.1.4(18) defines "arbitrary" order, indicating
that it must be an order that is equivalent to some sequential
ordering.  If you have the annotated RM, it explicitly mentions
the example given above in AARM 1.1.4(18.d).

: --
: T.E.D.

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA