Re: Precalculation of parameters (was: Software landmines)

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

dennison@telepath.com wrote:

: In article <Ez0tp1.59L.0.-s@inmet.camb.inmet.com>,
:   stt@houdini.camb.inmet.com (Tucker Taft) wrote:
: > dennison@telepath.com wrote:
: >
: > : 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.                                      ^^^^^^^^^^^^^^^
:   ^^^^^^^^

: Ahhh. That was the part I was missing. So language was specifically added to
: the RM to prevent compilers from blindly parallelizing this. Out of
: curiosity, what was the reason this was done? I can't find anything about it
: in the Rationale.

All code within a single task is defined to be "sequential." This
is critical to being able to prove things about safe access to global
variables.  If the RM allowed parallel evaluation of parameter expressions,
all of the discussion in RM95 9.10 about sharing variables between tasks and
about "independent addressability" would have to apply to sharing variables 
and manipulating neighboring packed-array components between different 
parameter evaluations, which would dramatically increase the likelihood 
of erroneous execution per 9.10(11).

See RM95 9.10 for a discussion of these issues.  The critical paragraph
is 9.10(13), where any two actions that occur as part of the execution
of a single task are defined to be "sequential."  In some ways, that
*is* the definition of a "task."

: --
: T.E.D.

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