Path: utzoo!utgpu!water!watmath!clyde!rutgers!ll-xn!husc6!cmcl2!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: X3J11 meeting notes Keywords: ANSI C standard Message-ID: <6852@brl-smoke.ARPA> Date: 16 Dec 87 21:12:56 GMT References: <6829@brl-smoke.ARPA> <406@mn-at1.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB)) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 63 In article <406@mn-at1.UUCP> alan@mn-at1.UUCP (0000-Alan Klietz) writes: >In article <6829@brl-smoke.ARPA> gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > >This is going to make writing an optimizing compiler more difficult. > >Previously, the compiler only needed to parse parentheses for determining >operation order and grouping in the initial expression tree. It could >later (in the expression optimization phase) rearrange the tree as necessary. > >Now, conforming C compilers will have to "remember" the parentheses by >encoding them into the expression tree. Optimizations across parenthesis >boundaries will be prohibited. In particular, the compiler will be >disallowed from rewriting many expressions to fit an idiomatic CPU instruction. > >Just ask a FORTRAN compiler writer about parenthesis restrictions in >his language. Then watch him moan and start to mumble evil incantations at >John Backus. > >This is a major change. Why is it being put in so late in >the review cycle? Unofficial responses, more or less in order: X3J11 has a lot of optimizing compiler implementors, who agreed to this change. They must not think it's a major problem. The only actual operational change is the removal of the Ritchie sentence that permitted rearrangement of adjacent mathematically commutative and associative operations. The parse tree you build is no different from before, just certain optimizations may have to be disabled. Parentheses still affect just the parsing. In fact, in many cases (for example, 2's complement machine with no integer overflow trapping), those sort of optimizations can still be performed. The key is that the result must be the same "as if" the strict virtual machine operations had been performed in the non-rearranged order. Constant folding, for example, often will not affect the result. Implementations that trap integer overflow are prohibited from causing it by rearrangement now; that actually helps the programmer obtain reliable behavior. We also removed formulas like "-E is equivalent to 0-E" since the IEEE floating-point people tell us that this is not necessarily so for their machines (I will spare you the incredible details). There have probably been more, and louder, complaints that C parentheses acted unlike Fortran's than any other single complaint the committee received. Finally, an ISO representative simply refused to sanction the proposed standard unless this was changed. Too many people (admittedly, many of them misunderstanding the issue) have been clamoring that they want "Fortran-like parentheses". After yet another round of discussion, the long-standing X3J11 committee resistance to changing this historical language feature was weakened sufficiently that the change was adopted. There are many major changes between the first and second (forthcoming) public review draft proposed standards. There actually is no "review cycle" currently in effect, but be advised that this change was asked for several times during the first formal public review, so if you like you can consider it made "by popular demand".