Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!decwrl!labrea!rutgers!orstcs!statware!scf
From: scf@statware.UUCP (Steve Fullerton)
Newsgroups: comp.lang.fortran
Subject: Re: function side effects (was: i++, i+=1, i=i+1)
Message-ID: <1058@statware.UUCP>
Date: 20 Sep 88 15:26:13 GMT
References: <3983@h.cc.purdue.edu> <3745@lanl.gov>
Reply-To: scf%statware.UUCP@cs.orst.edu (Steve Fullerton)
Organization: Statware, Corvallis, Oregon
Lines: 69

In article <3745@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>
>Now.  The real question is not 'when and where can Fortran functions have
>side effects and when can't they?'  The question should be: 'how can 
>Fortran be improved so that optimization can be done without making
>incorrect assumptions about function side effects?'  I still recommend
>that functions should be declared to have side effects if they do.
>That way the compiler would be free to apply optimizations to those
>that don't have side effects _and_ the compiler could actially detect
>the illegal (or unsafe) uses of functions which _do_ have side effects.
>In Fortran 8x style syntax:
>
>      side effect, external :: func1, func2
>
>      ...

The Fortran compiler for the HP9000 Series 800 machines has many compiler
optimization directives that allow the specification of side effects and
more.

$OPTIMIZE ASSUME_NO_PARAMETER_OVERLAPS  is no actual parameters passed to
      a procedure overlap each other.

$OPTIMIZE ASSUME_NO_SIDE_EFFECTS is the current procedure changes only
      local varaibles.  It does not change any variables in COMMON, nor does
      it change parameters.

$OPTIMIZE ASSUME_PARM_TYPES_MATCHED is all of the actual parameters passed
      were the type expected by this subroutine.

$OPTIMIZE ASSUME_NO_EXTERNAL_PARMS is none of the parameters passed to the
      current procedure are from an external space, that is, different from
      the user's own data space.  Parameters can come from another space if
      they come from operating system space or if they are in a space shared
      by other users.

$OPTIMIZE ASSUME_NO_SHARED_COMMON_PARMS is none of the parameters passed to
      the current procedure are from a shared common block.

These directives can be sprinkled throughout the code, which makes a mess
not to mention highly non-portable code; however, certain ones that you
always want in effect can be placed into a file which the compiler will
include at the beginning of each file. (+Q file).

They also have different optimization levels, level 1 (optimization within
each basic block), level 2 minimum (optimizes within each procedure with no
assumptions on interactions of procedures, all ASSUME settings OFF),
level 2 normal (optimizes within each procedure with ASSUME_NO_SIDE_EFFECTS
turned OFF, all others ON), level 2 maximum (all assumptions set to OFF).

The main problem I have encountered with optimization is that while users
want as much optimization as possible, the higher levels of optimization
absolutely require well tested code; e.g., no assumptions of local variables
being zero, etc.  Many programmers find that code that has always `worked'
now fails under a high level of optimization and the easiest thing to do is
to blame the optimizer.

Just my 2 cents worth---I have used a lot of different compilers, from
micro's to mainframes and the unfortunate fact of life is that I now write
code that I know will work when ported to all of these systems, rather than
following the standards or literature.  When a particular compiler has problems
with a certain coding construct, that construct is removed from my code for all
systems.  When porting new revisions of 130,000 line program every year to
several systems, it has to be this way.

-- 
Steve Fullerton                        Statware, Inc.
scf%statware.uucp@cs.orst.edu          260 SW Madison Ave, Suite 109
orstcs!statware!scf                    Corvallis, OR  97333
                                       503/753-5382