Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!uw-june!pardo
From: pardo@june.cs.washington.edu (David Keppel)
Newsgroups: comp.lang.c
Subject: Re: comma operator
Message-ID: <4037@june.cs.washington.edu>
Date: 21 Jan 88 19:53:37 GMT
References: <3819@sigi.Colorado.EDU> <8599@ism780c.UUCP> <1866@bsu-cs.UUCP> <4006@june.cs.washington.edu> <3586@sdcc6.ucsd.EDU> <4018@june.cs.washington.edu> <2427@bloom-beacon.MIT.EDU>
Reply-To: pardo@uw-june.UUCP (David Keppel)
Organization: U of Washington, Computer Science, Seattle
Lines: 71

----

John F. Carr (jfc@athena.mit.edu) writes:
>In article <4018@june.cs.washington (pardo@cs.washtinton.edu) writes:
>>[ how could the comma operator cause slower code? ]
>>
>>  The comma operator guarantees an order of evaluation on two statements
>>  that the compiler might otherwise rearrange to produce better code.
>>
>>     	    ++x, ++y;  	    if (x % n) { ... }
>>
>>  If the comma was replaced by a semicolon, the compiler could rewrite it as
>>
>>     	    ++y;     	    if (++x % n) { ... }
>>
>>  Which would be faster on many machines.
>
>I thought that "," and ";" both guaranteed order of evaluation.
>I have not heard anything to the contrary.
>[...]
>have always assumed that ;'s determined the order of evaluation
>but that an optimizing compiler could reorder any statements as long
>as the results are identical with the results of the written order.

To which harvard!wjh12!genrad!jpn@beaver (John P. Nelson) adds:
: If the compiler is allowed to rewrite it when a semicolon is used,
: then it is ALSO allowed to rewrite it when a COMMA is used.  Semicolons
: are "sequence points" just like commas.  The difference is only that the
: comma is a sequence point that is PART of an expression, the semicolon is
: a sequence point that also delimits statements.
:
: Remember that a sequence point is a place where the program must act
: AS IF the code is compiled exactly as written.  In your example, the
: compiler is free to reorder the increment of x, because (unless x is
: declared as "volatile") there is no way for the program to reference
: the value of x before the expression in the "if" statement.  On the
: other hand, if it was:
:
:	++x, y = x + 2;
:
: THEN the sequence point at the comma becomes significant:  The compiler
: CANNOT delay incrementing x until after the semicolon.  See?

K&R says that the order of evaluation is guaranteed.  Guaranteed _could_
be in terms of sequence points.  Somebody who does a lot of systmes work
might say:

    int	*ctrl_p = DISK_CTRL_REGISTER;
    int	*out_p = DISK_OUT_REGISTER;

    *ctrl_p = SETUP, *out_p = GO;

which _relies_ on the evaluation order being guaranteed in a
stronger way than is provided by sequence points.  If I were selling
a compiler I would write it so that code like the above wouldn't
break (C is a systems programming language, eh?), but unfortunately
this "turns off" some optimizations.  This isn't an issue until

(a) somebody needs the last few cycles of performance out of some code and
(b) they use  s1,s2;  where  s1;s2;  would do.

This doesn't say that all compilers are written this way.  Only that you
can't rely on all compilers being written the other (sequence point
guarantee) way.  As I said before, you only need to worry about this if
you need to squeeze the last few cycles out of something.

Anybody with ANSI or who writes C compilers like to comment on this?
Please send e-mail, I'll summarize.

    ;-D on  (Give me a pointer and I'll derefernce the world)  Pardo
    pardo@cs.washington.edu	ucbvax!uw-beaver!uw-june!pardo