Path: utzoo!attcan!uunet!ginosko!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!purdue!bu-cs!buengc!bph From: bph@buengc.BU.EDU (Blair P. Houghton) Newsgroups: comp.lang.c Subject: Re: swap(x,y) Message-ID: <4310@buengc.BU.EDU> Date: 22 Sep 89 03:23:17 GMT References: <8350@boring.cwi.nl> <14479@haddock.ima.isc.com> <1545@l.cc.purdue.edu> <10897@smoke.BRL.MIL> <604@rwthbs.UUCP> <4151@buengc.BU.EDU> <714@philmtl.philips.ca> Reply-To: bph@buengc.bu.edu (Blair P. Houghton) Followup-To: comp.lang.c Organization: Boston Univ. Col. of Eng. Lines: 55 In article <714@philmtl.philips.ca> ray@philmtl.philips.ca (Raymond Dunn) writes: >In article <4151@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes: >>Because if a machine can do it with a coupla gates and half a cycle, >>I'd like to do it with an operator. > >This sounds dangerously like the arguments made by Herman Rubin that 'C' >should provide facilities to access all the functionality of the machine >architecture in some direct way. What is this, the Nuremberg-defense rebuttal? ( :-) ) The issue I'd like to address is that there are some constructs that seem entirely obvious, but that are not a part of my favorite language. Some of them aren't there because there's no rational way to implement them in a compiler. A swap-operator, however, is not at all that way. Swapping a couple of variables is the utter basis of (almost) all sorting algorithms. Every one of them (except hashing) depends on the machine's ability to put things A and B into places B and A, respectively, and at least meta-simultaneously. (I can see Gwyn salivating in the background...maybe someone should throw him a pointer-sum...) I don't see a need for explicit register loading, PC munging, or even specific selection of the method of addressing objects. I think the concepts of 'near' and 'far' are too chummy with the hardware, to paraphrase some bigwig in the biz. >Since when was that the goal of *any* language other than assemblers? Swapping is a data operation, nor specifically a CPU-defined operation. I bet it doesn't even require the CPU, just a very smart MMU. There are (as we've seen) plenty of ways, whether straightforward or obfuscated-but-extra-efficient, to accomplish it. Selection of the optimal method should be up to the compiler, which shouldn't have to be in -O mode to get it right. C is almost silly to have omitted it. >Which particular architecture is the source of these language features? In this case, it's (allegedly) a Data General; a DG-6000, I think. Someone used it in an early example in this thread of discussion. He showed some C that the compiler had turned into a single-instruction using the swap-opcode. I thought, as soon as I saw that, "why does it take a special and expensive pile of optimization algorithms to recognize a swap, then replace it with this one instruction?" It shouldn't. You should just say ( a swap_op b ) and let fly. We could even use the @-character. It looks a little like it's twirling around, anyway. --Blair " 'a @ b' or fight!"