Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!uunet!overload!dillon
From: dillon@overload.Berkeley.CA.US (Matthew Dillon)
Newsgroups: comp.sys.amiga.programmer
Subject: Re:  Compiler code (was a flame fest) (now a lesser flame fest)
Message-ID: <dillon.6881@overload.Berkeley.CA.US>
Date: 23 Apr 91 21:15:50 GMT
Article-I.D.: overload.dillon.6881
References: <1991Apr18.212939.3461@kessner.denver.co.us> <1991Apr19.032052.26387@engin.umich.edu> <91112.093750GHGAQZ4@cc1.kuleuven.ac.be> <1991Apr23.020319.7216@engin.umich.edu>
Organization: Not an Organization
Lines: 59

In article <1991Apr23.020319.7216@engin.umich.edu> milamber@caen.engin.umich.edu (Daryl Cantrell) writes:
>In article <91112.093750GHGAQZ4@cc1.kuleuven.ac.be> GHGAQZ4@cc1.kuleuven.ac.be writes:
>>>  Nope.  ++ and -- are unary operators of the highest precedence.  The only
>>>..
>
>  You missed my point.  I was saying that ++ and -- are unary operators which
>will be evaluated before the multiplication.  You've pointed out the argument
>this stems from, which is that there's no way to know which side of the mult-
>iplication is evaluated (You're compiler does the left first..).

    evaluation order != operator execution order.  Here is an example:

	b = a++ + a++;

    (one possible method the C compiler might generate)

    (1) calculate t1 = a + 1
    (2) calculate t2 = a + 1
    (3) calculate t3 = t1 + t2
    (4) calculate b = t3
    (5) calculate a = t1
    (6) calculate a = t2

    Here is another example:

	d = a * b + c;

    (one possible method the C compiler might generate)

    (1) calculate t1 = c
    (2) calculate t2 = b
    (3) calculate t3 = a
    (4) calculate t4 = t2 * t3
    (5) calculate t5 = t4 + t1
    (6) calculate d = t5

    As you can see, operator precedence and execution of operators does in
    NO WAY match the evaluation of expressions that those operators act on.

    In otherwords, side effects such as ++a and a++ will be calculated
    properly if used singly in an expression, but NO guarentees are given
    on how they are calculated if used multiply in an expression.  Even
    without optimization turned on.

						-Matt

>--
>+---------------------------------------+----------------------------+
>|   // Daryl S. Cantrell		 |   These opinions are       |
>| |\\\ milamber@caen.engin.umich.edu	 |    shared by all of	  //  |
>| |//	Evolution's over.  We won.       |        Humanity.     \X/   |
>+---------------------------------------+----------------------------+

--

    Matthew Dillon	    dillon@Overload.Berkeley.CA.US
    891 Regal Rd.	    uunet.uu.net!overload!dillon
    Berkeley, Ca. 94708
    USA