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