Obfuscated SWAP: not portable!

[Tim Olson]

In article <4700044 at m.cs.uiuc.edu> kenny at m.cs.uiuc.edu writes:
| 
| OK, to begin with, we all seem to be agreed that there's only one
| possible way to parse this expression, given the right-to-left
| associativity of ^=:
| 
|     ^=          <- A
|    /  \
|   x    ^=       <- B
|       /  \
|      y    ^=    <- C
|          /  \
|         x    y

Right.

| Now, if I read the Standard right, there is also only one possible
| order of evaluation.  C must be evaluated first, then B, and then A.
| This is constrained because evaluating B requires the result of C, and
| evaluating A requires the result of B.  Order of evaluation therefore
| also has nothing to do with the problem.

I think your confusion lies in what is meant by "evaluation".
Evaluation consists of fetching the operands, performing the
operation, and storing the result.  You are correct that the ^=
operators must be performed in the order C,B,A, due to the
associativity rule, but the operands may be fetched in any order.
Consider code generated for a "load-store" architecture (one that only
accesses memory via loads & stores, and performs operations on
registers); the code sequences below are all valid:

load	r0, x		       load	r0, x	
load	r1, y		       load	r1, y	
xor	r0, r0, r1	       load	r2, x	
store	r0, x		       load	r3, y	
load	r1, y		       xor	r2, r2, r3
xor	r1, r1, r0	       xor	r1, r1, r2
store	r1, y		       xor	r0, r0, r1
load	r0, x		       store	r2, x
xor	r0, r0, r1	       store	r1, y
store	r0, x		       store	r0, x

this results in		       this results in
     x' = y			    x' = x^y
     y' = x			    y' = x^y
	-- Tim Olson
	Advanced Micro Devices
	(tim at amd.com)