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".