Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!amdahl!amdcad!cayman!tim From: tim@cayman.amd.com (Tim Olson) Newsgroups: comp.lang.c Subject: Re: Obfuscated SWAP: not portable! Summary: order of evaluation involves fetch, operate, write Message-ID: <27216@amdcad.AMD.COM> Date: 12 Sep 89 14:59:01 GMT References: <149@cpsolv.UUCP> <4700044@m.cs.uiuc.edu> Sender: news@amdcad.AMD.COM Reply-To: tim@amd.com (Tim Olson) Organization: Advanced Micro Devices, Austin, TX Lines: 48 Expires: Sender: Followup-To: In article <4700044@m.cs.uiuc.edu> kenny@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@amd.com)