J3/97-222r1 Date: August 15, 1997 To: J3 From: /Interval_1 Subject: Assignment Operators Sparked by the work on intervals, we propose adding a new assignment operator (:=), changing the default meaning of the existing assignment operator (=), and providing a mechanism for specifying the old semantics for =. These changes to be part of the base standard (part I), therefore we request a new work item be created. Over the next several meetings, we can expect to settle on semantics, syntax and edits in the usual fashion. However, to simplify the process, we shall start with the syntax proposed in 97-199 for the time being. Requirement The Fortran Standard prohibits interline optimization (interpretation 1, follows). With these additions to the Standard, the example transformations from that interpretation, as written will be Standard conforming; when written with := they will not be Standard conforming. As written, with the addition of the "magic switch" they will not be Standard conforming. Justification Fortran is intended as a language for high performance computation. Any processor used for high performance work is expected by users (and vendors) to routinely do interline optimization. The Standard's prohibiting such transformations relegates the Standard to formally applying to only uninteresting situations (that is effectively no optimization). By introducing new notation, we permit users to say precisely what they mean (thus allowing processors latitude where acceptable, and providing specific results where the user requires it). By changing the default to conform to common usage, we accommodate existing practice. By providing an escape hatch to return to pre-F2K semantics, we preserve compatibility. While no longer tied to interval arithmetic per se, the advantages of this scheme for intervals are even greater for intervals than for REAL kinds. Previous papers one may wish to keep in mind when pondering this topic are: 97-158 and 97-198. The informal term "macro" was intended to make the concept more clear; during committee debate it is clear that it did not. At this point we suggest "mathematical assignment" and "value assignment" as working names. NUMBER: 000001 TITLE: Optimization of Fortran programs DEFECT TYPE: Interpretation STATUS: Published QUESTION: Given a fragment such as 10 SUM = A + B 20 D = SUM + C does the standard allow the processor the freedom to replace this two statement fragment with any of the following single statements: 100 D = (A + B) + C 110 D = A + (B + C) 120 D = (A + C) + B 130 D = (B + A) + C 140 D = C + (B + A) ANSWER: The Fortran standard grants to processors an unlimited freedom to reorganize and modify programs, provided only that the execution "fulfills the interpretations herein" (1.4). In sections 7.1.7.1, 7.1.7.3, and elsewhere, specific additional freedoms are granted processors in expression evaluation. Generally speaking, all of these freedoms support what is called "optimization", the altering of the program in some way that is thought to improve a specific property, often performance, of the program. In this particular case SUM, in statement 20, is not an expression, but a reference to the result of a previous assignment. The additional freedoms granted for expression evaluation do not apply. Thus only those processors that can make the replacement and still "fulfill the interpretations herein" are permitted to do so. For these processors the answer is yes, for all other processors the answer is no. The "interpretation herein" is that SUM is a primary (7.1.1.1) of the expression "SUM + C" and the reference to SUM requires its value (Section 6, first paragraph). The determination of SUM's value was specified by assignment statement 10. The result of that assignment, with its possible conversions of "A + B" to the type and type parameters of SUM, is the value of SUM. This is the interpretation that must be fulfilled by conforming processors. A common optimization for this fragment is to replace it by statements such as 100, 130, etc. where the calculation of A + B appears in parenthesis. This replacement corresponds to the calculation of A + B in a temporary location (i.e., a register) and then accessing that temporary location instead of storing the result in SUM and then accessing that stored value. Discussion The C language has a concept of "sequence points". Loosely speaking, a sequence point is a barrier to optimization. The ":=" is intended to provide selective barrier. So SUM = A + B SUM2:= D+E D2 = SUM + C In this context, := would not inhibit transforms involving A,B, SUM, etc. However, if SUM2:=SUM+E, the computation of SUM shall complete before the assignment into the memory location corresponding to SUM2. It is also intended that := requires an actual storage to memory (somewhat akin to volatile in C), this can be helpful in careful coding on a machine with extended precision registers (of course, some users might very much like a way to state positively that they want SUM to be stored in such registers in preference to other variables. This proposal does not offer a hook for them per se). Some potential straw votes: Limit := to numeric types only (minimizes edits/hazards, but arguably inconsistent). Y|n|U 1-11-5 Apply to intrinsic types only? Y|n|u not taken (moot) Names "mathematical and value" assignment, symbolic and value, value and "plain" assignment 3-5-3-6 New mathematical = "could" be defined rather differently than 7.5/7.5.1 currently works. For example, it need not be the point at which a variable actually becomes defined or redefined. Would J3 prefer that ":=" be as close to "=" as possible, or maximally permissive? (lazy vs. not) 10-1-3 We could handle the default switch via: Required processor dependent, compile "line option"/switch 14 Introduce c$Pragma | c$dir or similar syntax 2 Hijack USE statement, e.g. USE pre-F2k-assignment 0 Undecided 1 Should we work on providing a way to specifically request *extra* precision for a specific variable (alas, that might be another late arriving work item; probably a qualifier on the variable itself) subgroup doesn't recommend this. 0-17-0 (noted that kind= for such a type could be provided already) Interline optimization to be worked on at all 12-0-5